The moment you have two agents, memory becomes a federation problem. Here is the schema-level decision tree.
A single-agent system's memory is a private store the agent reads and writes for one user. Add a second agent and you've signed up for a federation problem: who owns the memory, who can read it, what happens when agent B writes something for user X that agent A retrieves while serving user Y. The schema decisions you make at launch determine which leaks are possible later.
This guide covers the per-agent vs shared decision, cross-tenant scoping, the leak modes that show up after launch, and a comparative look at memory architectures running in production today. Chapter 9 of A2A in Production is the long version.
Independent of ownership, every memory record has scopes that must be decided:
Every memory write needs to encode these dimensions; every memory read needs to enforce them. The most common production bug is encoding less than the dimensions that actually matter, then discovering the missing dimension when something leaks.
Agent A writes a memory for user X (customer A); the memory record encodes user but not tenant; agent B retrieves it while serving user Y (customer B). Customer B's user sees data from customer A.
Fix: tenant is always a scope dimension, separately from user. A user lookup that doesn't include the tenant predicate is a bug.
The customer-support agent's notes ("user complained loudly about pricing") get pulled into the sales agent's context, which now treats the user as a hot lead. Agent boundaries are not honored.
Fix: per-agent scoping is the default; cross-agent sharing is explicit and audited.
Agent A summarizes a conversation into a memory record. Agent B reads A's summary and writes its own summary into the same store. Agent C reads B's summary, distorted from the original. The telephone game in storage form.
Fix: provenance as a first-class field on every memory record. Agent C should be able to see the chain "A wrote based on conversation X; B summarized A's note; the original is over here."
User requests deletion under GDPR. Memory in agent A's store gets deleted. The summary agent B made into a different store doesn't. The "deleted" data is still findable.
Fix: per-user deletion requires walking every federated store. Build the walker before you need it.
Each of these is in production today and takes a different stance on the federation question:
Each one solves a slightly different shape of the problem. The choice is downstream of how much federation you actually need: if it's "one agent, one user, one conversation," any of these work; if it's "five agents across two tenants with explicit cross-tenant sharing in some workflows," only the most opinionated will fit and you'll be writing scoping logic on top.
Every memory record, regardless of store:
None of these can be added later. The retroactive migration that adds tenant to records that never had it is the migration that produces bugs.
A2A in Production Chapter 9 covers all four ownership shapes in depth, the scoping dimensions with worked schema examples, the comparative deep dive on the memory architectures in production (with the federation question front and center for each), and the deletion-and-audit patterns that survive a GDPR request.
A2A in Production
The book on multi-agent systems and agent orchestration. Twelve chapters drafted; readable end to end as of v1.0.0-early.2. PDF + EPUB. Free updates through v1.0 and beyond. $39 (early access), secure checkout.
Read more & buy $39 →Published by Yaw Labs.