A single agent with a single user has an easy memory problem. Everything it remembers belongs to that one relationship, so any memory is fair game at any time. You can be sloppy and get away with it.
Add a second user, agent, or customer and that simplicity is gone — and most teams do not notice until something leaks. The classic failure is a support bot. You build it for one customer, it works, you roll it out to a hundred. Now the bot recalls "the account owner prefers we escalate billing issues directly to their CFO" — except it recalls that while talking to a different customer, because all those memories landed in one undifferentiated pile and the recall query grabbed whatever was semantically nearest. That is not a hallucination. The agent remembered something true. It remembered it for the wrong person.
This is a scoping problem, and it is the same problem every multi-tenant system has had to solve for decades. The answer is isolation by default. In agent memory, the mechanism for that isolation is a container.
What a container actually is
A container is a labeled boundary around a set of memories. Think of it as a folder, except the important part is not organization — it is access. When an agent writes a memory, it goes into one or more containers. When the agent recalls, the query runs against a specific set of containers and nothing else. Memories outside those containers are invisible. Not deprioritized, not ranked low — invisible.
If you have built software for businesses, you know this pattern under another name. It is multi-tenancy: many customers share one application and one infrastructure while their data stays separate. As WorkOS puts it, "Resource Isolation in multi-tenant systems refers to the mechanisms and techniques used to ensure that the computational, storage, and network resources assigned to one tenant are isolated from those of other tenants" (WorkOS: Tenant isolation in multi-tenant systems). Container scoping is tenant isolation applied to memory. The container is the tenant boundary.
A quick vocabulary note, since these words get thrown around loosely. Scope is the set of memories an operation is allowed to touch. Container is the named thing that defines a scope. Isolation is the property you get when scopes do not bleed into each other.
The two ways multi-agent memory goes wrong
There are two failure modes, and they pull in opposite directions.
The first is leakage — a memory surfacing in a scope it should never reach. The support bot recalling one customer's CFO preference for another customer is leakage. So is a coding agent on Project A suggesting an API key pattern it learned from Project B's private repo. Leakage is the dangerous one: it is a privacy and trust failure, not just a quality bug. If your platform serves businesses, cross-customer data bleed is the kind of incident that ends contracts and triggers compliance reviews.
The second is noise — too many irrelevant memories in scope, so recall quality degrades even though nothing technically leaked. A single agent that dumps every project's lessons into one pile will, asked a narrow question, pull back a muddle. Nothing crossed a tenant boundary, but the signal-to-noise ratio collapsed.
Both are scoping problems. Leakage is a scope too wide in the wrong direction; noise is a scope too wide in every direction. Containers fix both by making "what can this query see" an explicit, deliberate decision instead of an accident of what happened to be stored.
The scope hierarchy: per-user, per-org, per-agent, per-session
There is no single correct way to slice scopes; the right cut depends on who needs to share memory with whom. Four levels cover almost everything.
Per-user. One human, their preferences and history. "Prefers terse answers." "Lives in the Pacific timezone." These should follow the user across whatever agents serve them, but never reach another user.
Per-org. Shared across everyone in a company or account. "This account is on the enterprise plan." "Our refund policy allows 30 days." Org-scoped memory is the home for facts every agent serving that customer should know, but that must not leak to other customers. This is the boundary the support-bot example violated — the CFO-escalation rule was org-scoped knowledge for one org, treated as global.
Per-agent. Specific to one agent's role. A billing agent and a scheduling agent serving the same org may want different memory. The lesson "the payment webhook fires twice on upgrades" belongs to the billing agent; the scheduling agent does not need it cluttering its recall.
Per-session. Scratch memory for one conversation or task run, discarded after — working state you do not want polluting long-term memory.
These nest. A single recall might legitimately need this user, within this org, for this agent's role. The art is choosing the narrowest scope that still contains everything the query needs — the memory analog of a principle Anthropic articulates for context generally: find "the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome" (Anthropic: Effective context engineering for AI agents). Over-wide scopes are the memory equivalent of stuffing the context window. Anthropic also warns of "context rot" — "as the number of tokens in the context window increases, the model's ability to accurately recall information from that context decreases" (same source). Pull in three orgs' worth of memory and you do not just risk a leak; you make the agent worse at its job.
Why this matters even when nothing leaks: multi-agent architectures
Container scoping is not only a defense against bad outcomes. It is also what makes good multi-agent designs work.
The dominant pattern for hard tasks right now is orchestrator-worker. Anthropic's own Research system "uses a multi-agent architecture with an orchestrator-worker pattern, where a lead agent coordinates the process while delegating to specialized subagents" (Anthropic: How we built our multi-agent research system). The reason this beats one big agent is isolation: "Subagents facilitate compression by operating in parallel with their own context windows, exploring different aspects" (same source), and each one "provides separation of concerns—distinct tools, prompts, and exploration trajectories" (same source). Simon Willison, reviewing the system, put the payoff plainly: "Each sub-task has its own separate context, allowing much larger volumes of content to be processed as part of the research task" (Simon Willison: Anthropic — How we built our multi-agent research system).
That separation is about context, the live window. The same logic applies to memory, the persistent store. If five subagents share one undifferentiated memory pool, you have reintroduced exactly the interference that giving them separate contexts was meant to remove. Per-agent containers extend the architecture's separation of concerns into long-term memory: each worker remembers what it learned without trampling its siblings, and the orchestrator can hold a wider scope without every worker inheriting that breadth.
Patterns for keeping it clean
A few rules carry most of the weight.
Isolate by default; share by exception. The safe default is the narrowest scope. Sharing across scopes should be something you turn on deliberately, never the fallback. A new memory with no specified container should land somewhere private, not somewhere global.
Make cross-scope access explicit and logged. Sometimes an agent genuinely needs to read across boundaries — a support lead reviewing patterns across accounts, say. Fine. But that query should name the scopes it spans and leave an audit trail. The dangerous version of cross-scope access is the implicit one, where the system quietly widens scope because someone forgot to filter. If crossing a boundary is always an explicit, recorded act, leakage stops being silent.
Name containers so collisions cannot happen. This is mundane, and it is where real incidents start. Scope by a bare name like frontend or api and two unrelated projects will eventually collide under the same label. Use namespaced identifiers — acme-corp/billing, org_12345/scheduling — so the boundary is unambiguous. A scope is only as good as the uniqueness of the thing that names it.
Share data, not directives. When you do share across a scope, be careful what you share. A neutral fact ("the account is on the enterprise plan") is usually safe to widen. A behavioral directive ("always escalate to the CFO") almost never is — it was true for one relationship and becomes a liability everywhere else. Bias cross-scope sharing toward stable, factual memory and away from anything that changes how the agent acts.
Where AgentPrizm fits
AgentPrizm treats the container as the core scoping primitive. Every memory belongs to one or more containers, and recall filters by container — so a query against acme-corp/support cannot return a memory that lives only in globex/support. Because a memory can belong to multiple containers, you can express the hierarchy above directly: a fact can sit in both a per-user and a per-org container when it needs both scopes, while a per-agent lesson stays in exactly one.
Recall is hybrid — semantic similarity plus keyword matching — and the container filter and memory type are applied on top, so relevance and isolation are enforced together rather than traded off. The six memory types — fact, lesson, directive, preference, contact, bookmark — also make the "share data, not directives" rule actionable, because a directive is a distinct type you can choose to keep tightly scoped. And forgetting is audited by default, the same discipline as logging cross-scope access: when behavior changes, you can see which memory drove it and when it entered or left a scope.
For the developer-facing detail — container semantics, recall filters, and the six types — see the docs. For limits and plans, see pricing.
The takeaway
Memory without scopes is fine for one agent serving one user. Past that, scope is not a nice-to-have — it is the difference between a memory layer and a data-bleed incident. Containers give you the boundary; isolation-by-default keeps it honest; explicit, logged cross-scope queries let you share when you mean to and never by accident. Get the scoping right and multi-agent memory is an asset. Get it wrong and every memory you store is a liability waiting for the wrong session to surface it.