Use case Data residency

The memory is the thing residency law is about

Everything else in an agent stack is transient. The memory is the part that persists, crosses borders, and has to be deletable on request — which makes it the part the law is actually addressing.

01 What breaks

Derived memory is where erasure quietly fails

Deleting a row is easy. The difficulty is everything that was computed from it and no longer looks like it.

01

A deletion request meets an embedding

The source record is removed. The vector derived from it, the summary that quoted it and the belief inferred from it are all still there, still retrievable, and no longer recognisably that person's data.

02

Consolidation crosses the border before anyone asks

Storage is regional; the model call that summarises it frequently is not. The moment a memory is enriched by an endpoint in another jurisdiction, its residency is a property of the network path rather than of the database.

03

“Where is it stored” is the wrong question

Residency obligations attach to processing as much as to storage. A regional bucket read by a global inference endpoint satisfies the diagram and not the requirement.

02 What it’s made of

Mostly persistent. 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 · Persistent memory

Preferences and corrections survive the session and the handoff

The durable, person-level record is the object the obligations attach to. Because it is explicit rather than emergent, it is also the thing that can be located, scoped and removed on request.

  • A person's memory is one addressable thing, not a residue.
  • A correction replaces what it corrected.
  • What was derived from a memory is traceable to it.
Valid time

When consent applied

Permissions change. What was lawful to process is a question about a date, not about the current setting.

Shared memory

One record per region

Agents in a region read the same memory rather than each holding a copy that has to be deleted separately.

Decision context

Only what this request needs

Assembling less means processing less, which is the disposition regulators reward.

That is four of the five. The fifth — episodic memory, where action, reasoning and outcome stay attached — leads for customer support, clinical operations and IT service management instead. Same engine, different mixture.

03 What feeds it

Regional deployment, regional connectors

Connectors are self-hostable, so a source in one region can be synced by a worker in that region rather than by a managed service elsewhere.

01 Wire the sources

Vendor connectors ship as extras on the connector package.

Install
pip install 'cortexdb-connectors[slack,notion]'

02 Write into a scope that has a jurisdiction

The scope is what makes a person's memory addressable — which is what makes it locatable, and removable, later.

Store an experience
curl -X POST http://localhost:3141/v1/experience \
  -H 'Content-Type: application/json' \
  -d '{
    "scope": "ws:eu/customer-5502",
    "modality": "observation",
    "content": {
      "kind": "text",
      "text": "Customer requested German-language correspondence and asked that call recordings not be retained beyond the statutory minimum."
    },
    "context": { "observed_at": "2026-08-27T09:14:00Z" },
    "idempotency_key": "crm:customer-5502:pref-0021"
  }'

03 Recall inside the region

The instance the client points at is the instance that holds the data. There is no second hop to a service that assembles the pack somewhere else.

Recall it
from cortexdb.v1 import V1Client

client = V1Client(api_url="http://localhost:3141", actor="agent:eu-support")

pack = client.recall(
    scope="ws:eu/customer-5502",
    query=customer_message,
    view="holistic",
    include=["facts", "beliefs", "episodes"],
    budgets={"max_tokens": 800},
)

reply = llm.respond(customer_message, 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

The container is the residency boundary

One container, deployed in the region, with embedding and generation pointed at an endpoint in the same region. Residency becomes a property of where you ran it rather than a claim about a vendor's architecture.

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 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 Government & defenceshared 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