Multi-agent systems are appealing because they mirror how human teams work. One agent specializes in research, another in drafting, another in execution, and they pass work between them. The architecture is elegant. The risk is that every pass is also a transfer of context, and context is exactly the thing you spent so much effort governing at retrieval. A hand-off can quietly undo all of it.
Picture a research agent that is allowed to read sensitive financial records to produce a summary. It hands that summary, along with its working context, to a drafting agent whose job is to write a customer-facing note. The drafting agent was never meant to touch raw financials. But if the hand-off carries the research agent's context wholesale, the drafting agent now reasons over data far outside its purpose, and the customer-facing note it produces might reflect things it should never have known. No rule was visibly broken. The data simply flowed across a boundary nobody was watching.
Why hand-offs are uncontrolled by default
The reason this happens is that most agent frameworks treat the hand-off as a plumbing detail. Passing context from one agent to the next is just moving a payload, and the framework has no opinion about whether the receiving agent should see what is in that payload. The boundary between agents looks like a function call, and function calls do not check permissions.
But conceptually, a hand-off is the same kind of event as a retrieval. In both cases, data is about to enter an agent's reasoning, and in both cases the right question is whether this agent, for this purpose, should be allowed to use this data. We already know how to answer that question at retrieval. The hand-off needs the same treatment, and the fact that the data came from a sibling agent rather than a document store does not make it any less in need of a decision.
Governing the boundary between agents
Governing hand-offs means putting a policy decision on the edge between agents, not just at the edges of the system. When agent A passes context to agent B, that context is evaluated against agent B's identity, role, and purpose, the same way retrieved chunks are evaluated against a user's. Data that agent B is not permitted to use is filtered, redacted, or denied before it enters agent B's reasoning. The receiving agent gets what it needs for its task and nothing it was not meant to have.
This depends entirely on the agents being known identities with declared purposes, which is why agent identity comes first. You cannot decide what agent B should receive if you do not know what agent B is for. With identity and purpose in place, the hand-off stops being a blind payload transfer and becomes a governed exchange.
Memory turns a moment into a persistent risk
Hand-offs are dangerous in the moment. Memory makes the danger persist. Agents accumulate context across turns, sessions, and sometimes across different users, and that stored context can resurface later in a completely different setting. A detail an agent learned while helping one user can appear in a response to another, not because anyone passed it deliberately, but because the agent simply remembered.
This is the cross-session and cross-role recall problem, and it is a hand-off stretched across time. The same principle applies: memory entries should carry sensitivity and policy, and every write and recall should pass through a policy decision rather than flowing freely. What one role's session retains should never silently appear for another. We covered the broader stakes of this in the agent memory governance gap, and the platform capability is memory governance.
The principle to hold onto
There is a clean way to think about all of this. An agent's reasoning is only as governed as the least governed thing that entered it. Retrieval can be perfect, and it does not matter if a hand-off or a memory recall quietly slips ungoverned data into the same reasoning. Multi-agent governance is the work of making sure every doorway into an agent's reasoning has the same guard on it, whether the data arrives from a source, a sibling agent, or the agent's own memory.
That is also why hand-offs and memory are not edge cases to handle later. In a real multi-agent system they are the main event, and governing them is most of what separates a clever demo from something you can actually run. The wider architecture sits in the complete guide to agent governance.