Skip to main content
Agent Memory separates memories at three levels. Knowing which level does what tells you where you get a hard wall and where a naming convention is enough. The organization is the boundary that keeps customers apart, and you get it for free. Namespaces and profiles are how you organise within your own data.

​
Organization — the tenancy boundary

Every identifier the service composes internally begins with your organization — banks are named org:<organization>:<namespace> — and the organization comes from your API key, not from anything in the request path. One profile’s memories are never returned for another, and there is no request shape that reaches across into another organization. Nothing to configure; it is always on.

​
Namespace — a hard wall within your org

A namespace is an isolated memory store for one application or environment — not a tenancy boundary, and not a memory layer. It does exactly one thing: it is an isolation boundary at the storage layer, one memory store per namespace. An operator can reach every memory across every profile in a namespace, and cannot reach across into another. Reach for a namespace when you need a hard boundary rather than a tidy one — staging kept separate from production, or two applications whose memories must never meet.
Agent Memory is in beta, and today there is one namespace: default. It exists for every organization, it isolates, and it carries namespace settings. There is no way to create, rename, list, or delete another one yet — additional namespaces are the planned way to get a second hard boundary.

​
What default gives you

default exists for every organization with nothing to provision: the first request that addresses it builds it — reads included, so a brand-new organization gets an empty list rather than a 404. Profiles are the same, created on first write. The entire setup for Agent Memory is authenticate and write. A request against a namespace other than default returns 404 on reads and writes alike — writing never brings it into being.

​
Profile — separation by convention

Because profile_id is a free-form string with no imposed pattern, you can separate applications, environments, or user and team layers inside default with a naming convention — nothing to provision:
This is a tidy boundary, not a hard one: nothing stops a wrong profile id from reading across within the same namespace. When the wall needs to be enforced rather than conventional, that is what a namespace is for.
A request addresses exactly one namespace, so layered memory — user, then team, then organization — means one recall per layer and merging the results yourself. That is an argument for layering with profile ids rather than namespaces.