Use case Government & defence

Shared across the mission, not across the boundary

Agents working one programme need a common memory. The whole difficulty is that “common” has to stop precisely where clearance, compartment and jurisdiction say it stops.

01 What breaks

Sharing and compartmenting are the same problem

Solve one by ignoring the other and you get either a fleet that cannot cooperate or a memory that cannot be accredited.

Per-agent stores make compartmenting look easy and cooperation impossible

Give every agent its own memory and nothing crosses a boundary it should not. Nothing crosses the boundaries it should either, so each agent re-derives what the one beside it already established.

One shared store makes cooperation easy and accreditation impossible

Pool everything and the fleet works well right up to the review that asks which agent could read what. If the answer is “all of it”, the system does not deploy.

Aggregation changes classification and nothing notices

Individually releasable facts combine into something that is not. A memory that assembles context automatically is exactly the mechanism by which that happens silently.

02 What it’s made of

Mostly shared memory. Then three others.

Every application built on CortexDB is a different mixture of the same five memory jobs. That mixture is what makes this a different piece of software from the one next to it, even though the infrastructure underneath is identical.

Dominant · Shared memory

One memory, many agents — scoped, not pooled

Scopes are the mechanism. Agents read and write a common record, and what any one of them can reach is decided by the scope it holds rather than by which store it was pointed at.

No per-agent silos to reconcile.
Scoped: shared is not the same as leaked.
Handoffs carry context, not a summary.

Episodic memory

What was already attempted

Action, reasoning and outcome retained, so a rotation does not repeat the work of the one before it.

Valid time

What the standing guidance was

Direction changes. A past action is assessed against what was in force when it was taken.

Decision context

What this task is permitted to see

Selection weighs scope and validity, so relevance never overrides authorisation.

That is four of the five. The fifth — persistent memory, where an individual's preferences and corrections survive — leads for assistant and commerce agents instead. Same engine, different mixture.

03 What feeds it

Whatever the programme already runs on

Connectors are self-hostable, so an environment with no route to a vendor can still pull from the tools inside it.

01 Wire the sources

Vendor connectors ship as extras on the connector package.

Install

pip install 'cortexdb-connectors[slack,jira]'

02 Write into the scope, not into the agent

The scope is the compartment. An agent without it cannot reach the memory regardless of how relevant the memory is.

Store an experience

curl -X POST http://localhost:3141/v1/experience \
  -H 'Content-Type: application/json' \
  -d '{
    "scope": "ws:prog/atlas/analysis",
    "modality": "observation",
    "content": {
      "kind": "text",
      "text": "Sensor tasking for the eastern corridor was reprioritised after the 14 August review; the earlier tasking order no longer applies to this programme."
    },
    "context": { "observed_at": "2026-08-27T09:14:00Z" },
    "idempotency_key": "prog:atlas:tasking-rev-09"
  }'

03 Recall within the compartment

The actor and the scope together decide what can be assembled. A pack cannot contain material the requesting agent is not entitled to.

Recall it

from cortexdb.v1 import V1Client

# a different agent on the same scope
client = V1Client(api_url="http://localhost:3141", actor="agent:analysis-02")

pack = client.recall(
    scope="ws:prog/atlas/analysis",
    query=task_brief,
    view="holistic",
    include=["facts", "beliefs", "episodes"],
    budgets={"max_tokens": 1000},
)

reply = llm.respond(task_brief, context=pack["context_block"])

pip install cortexdbai or npm i cortexdbai — both ship the same client. Full endpoint reference in the docs.

04 Where it runs

Air-gapped, and with nothing calling home

A single container, no outbound telemetry, and model calls that can be pointed at an in-enclave endpoint. Nothing in the deployment requires a route to the internet, which is the only form of this argument that survives an accreditation review.

CortexDB is a single container. It runs on your own hardware, inside your VPC, or air-gapped — with the embedding and generation calls pointed at a local model if nothing may leave at all.

Run it

docker run -d --name cortexdb -p 3141:3141 -v cortexdb-data:/data cortexdb/cortexdb:latest

Deployment options, model routing and the enterprise notes are on the download page.

05 The rest

The same infrastructure, a different mixture

Each of these leads with a different memory job, pulls from a different set of sources, and needs a different call. All of them, by job.

Assistant agentspersistent memory Commerce agentspersistent memory AdTechpersistent memory Games & multiplayerpersistent memory Data residencypersistent memory Employee supportvalid time Contract & legal opsvalid time Financial opsvalid time Capital marketsvalid time Healthcarevalid time Customer supportepisodic memory Clinical operationsepisodic memory IT service managementepisodic memory Financial servicesepisodic memory Sales agentsshared memory Customer successshared memory Research agentsdecision context Coding agentsdecision context Voice AIdecision context Observabilitydecision context

Bring the workflow that gets it wrong.

Not the demo. The one that answered from the wrong version, or asked a question it had already been told the answer to.

Talk to us Download