Most teams think handoffs are “passing state.” They’re not. A handoff is three distinct events compressed into one: a trust transition (who’s now authoritative?), a context serialization event (what gets captured?), and a coordination checkpoint (did both sides actually agree on what happened?). Each of these can fail independently. In production multi-agent systems, they regularly do.
The MAST taxonomy — the first systematic study of failure modes across 1,600+ annotated traces from seven popular multi-agent frameworks — identifies 14 distinct failure modes organized into three categories: specification and design failures, inter-agent misalignment, and task verification 1. Six failure modes (an entire category) are classified as inter-agent misalignment failures — failures that occur specifically at the interfaces between agents. That’s not a coincidence. The boundary between agents is where implicit assumptions collide with reality.
This post documents what specifically fails at handoffs and session boundaries in production systems and provides practitioners a design framework for building against those failures. This is not a tutorial on how to implement handoffs generically. It is an analysis of where the protocol breaks, grounded in evidence from real systems.
What a Handoff Actually Transfers (and What It Doesn’t)
Before diagnosing failure modes, it helps to be precise about what a handoff is supposed to transfer.
Multi-agent systems have three distinct handoff types, each with different trust dynamics:
- Worker → Lead: Output passes upward for synthesis or decision. The receiver is expected to evaluate, not merely consume. The worker’s role ends; the lead’s judgment applies.
- Lead → Worker: Instructions pass downward. The receiver is expected to execute. The lead’s reasoning is typically not included — only the directive.
- Peer → Peer: A lateral pass. Neither party has formal authority over the other. Trust is symmetric but usually unverified — each peer assumes the other is operating correctly.
What gets serialized in practice:
- Task outputs (what the agent produced)
- Completion status (done / not done)
- Sometimes: key decisions made
What does not get serialized:
- Active reasoning chains — the working hypotheses still in progress when the session ended
- Tentative conclusions — findings flagged internally as “probably correct, pending confirmation”
- Unresolved ambiguities — things the agent knew it didn’t know
- Negative evidence — what the agent tried, what it rejected, and why
This gap between what’s in state and what’s in-context is the structural root of most handoff failures. The receiving agent gets conclusions without the caveats. It gets a completion status without knowing what completion meant.
Concrete scenario: A worker finishes a research task but holds an unresolved ambiguity in its working context — it processed an ambiguous input and flagged it internally as “probably correct, verify later.” The handoff state captures the output but not the flag. The lead assumes clean completion. The ambiguity surfaces as a bug three sessions later when the output is used as a hard dependency.
AgentAsk (2025) characterizes this problem precisely 2. The researchers identify four error types at inter-agent message transfers: Data Gap (missing information in the transfer), Signal Corruption (degraded or distorted information), Referential Drift (loss of contextual clarity), and Capability Gap (mismatched agent competencies). Each is a symptom of the same structural failure: the handoff protocol captures what was produced, not how or under what conditions.
Five Failure Modes at Handoffs
The following failure modes are documented from production fleet operation and corroborated by research evidence. They are not exhaustive, but they are the ones that recur.
1. Context Serialization Loss
Signature: The receiving agent gets conclusions without the caveats. It acts on outputs as if they were ground truth when the producing agent held significant uncertainty.
How it manifests in practice: A worker completes a research task with 70% confidence and three unverified assumptions. The handoff state says “research complete.” The receiving agent begins planning as if the research is definitive. Hours later, the plan fails because an unverified assumption was wrong.
The MAST taxonomy identifies FM-1.4 (loss of conversation context mid-interaction) and FM-2.4 (critical information not shared between agents) as separate failure modes 1. This is important: context loss can occur within an agent’s session and at the handoff boundary — independently. You can fix one without fixing the other.
Design signal: If your handoff state schema captures only outputs and status — not confidence, open questions, or rejected paths — you are structurally guaranteed to lose context at every handoff. The schema is not a passive artifact; it defines what the protocol can express.
2. Trust Escalation at Handoff
Signature: A worker-level agent hands off to a system that treats its output as authoritative. Errors propagate without skepticism.
How it manifests in practice: Worker → Lead handoffs are supposed to involve evaluation. But when the lead agent receives a well-formatted, complete-looking output, it often has no mechanism to assess the quality of the reasoning behind it — only the output’s surface appearance. The lead treats it as authoritative and acts on it. A confident-sounding but incorrect conclusion from a worker becomes a hard input to the lead’s planning.
“Intelligent AI Delegation” (2026) names this structural problem 3. In multi-agent delegation chains where agents receive outputs from other agents without critical evaluation, each agent acts as an unthinking router rather than a responsible actor. Trust propagates downstream, but so does error. The authors describe a “broad zone of indifference” in delegation chains: a zone in which the delegating agent provides neither enough context for the delegatee to evaluate its instructions critically, nor enough skepticism from the receiver to push back.
The consequence is not just that errors propagate — it’s that they propagate fast. In a hierarchical chain, a worker-level error that goes unchallenged at the first handoff will typically be amplified at every subsequent handoff as downstream agents build on the corrupted premise.
Design signal: Handoff state should include provenance markers — which agent produced this, under what instructions, with what constraints, and at what point in its reasoning. Receiving agents need this information to calibrate skepticism. A lead that receives an output labeled “worker output, research phase, 3 open questions” should treat it differently than one labeled “lead decision, planning phase, verified.”
3. Ghost Tasks
Signature: A task is marked complete in the handoff state, but has an incomplete side effect. The next session has no record that anything is missing.
How it manifests in practice: An agent completes “write config file” and marks the task done. The config file was written, but a downstream dependency that the config should have updated was missed. The handoff state says “done.” The receiving agent — or the next session of the same agent — has no record that a follow-up check was needed.
MAST identifies FM-3.1 (ending tasks before objectives are fully met) and FM-3.2 (insufficient or absent verification mechanisms) as distinct failure modes 1. Together they describe the ghost task failure precisely: the task looks complete from the outside because the verification step that would have caught incompleteness was skipped or never existed.
Ghost tasks are particularly dangerous because they are invisible. An agent cannot detect a ghost task by inspecting current state — it can only discover it by re-running the verification that was skipped the first time. If the session ended before verification ran, that verification is not in anyone’s memory.
Design signal: “Done” is not a binary. Handoff states should encode what was verified, not just what was completed. A task completed without verification is a different thing than a task with confirmed clean outputs. The handoff schema should make this distinction explicit and mandatory.
4. Cascading Session Reinit Costs
Signature: In a multi-agent fleet, session startup overhead compounds when agents at a coordination boundary reinitialize simultaneously.
How it manifests in practice: A coordinated fleet runs on a shared heartbeat cadence. At each session boundary, every agent reloads its context from memory, re-reads its brief, and re-establishes its working state before doing substantive work. In an eight-agent team, that is eight parallel cold starts at every boundary. When agents are also passing work to each other at those same boundaries — which they typically are, since handoffs are scheduled around session checkpoints — the coordination cost compounds. Agent A’s output is not ready when Agent B reinitializes; B either waits or starts on stale state.
The MAST study found that ChatDev, a well-studied multi-agent coding system, achieved accuracy as low as 25% on complex tasks 1. Multi-agent coordination overhead — including boundary reinit costs — is a significant contributor to that degradation.
Unlike the other failure modes here, cascading reinit is not a single-point failure. It is a structural tax that accumulates across every session boundary in the fleet’s operation. Individual session performance looks acceptable; fleet-level throughput degrades systematically.
Design signal: Session boundaries in coordinated agent teams should be staggered, not synchronized. Outputs should be passed asynchronously rather than at fixed boundary points. Design for “read when ready” rather than “read at reinit.” Treat session synchronization as the bug it is.
5. Memory Poisoning at Handoff Boundary
Signature: Adversarial or corrupted content written into handoff state by one agent propagates into the receiving agent’s context as trusted input.
How it manifests in practice: An agent processes external content — a document, a web search result, a tool output — that contains injected instructions. The agent includes that content in its handoff state as part of its task outputs. The next agent in the chain receives the handoff state as trusted system input and follows the injected instructions, treating them as coming from the orchestrator.
This is the multi-agent analogue of prompt injection, but with a crucial asymmetry: in a single-agent system, the attacker must get their content into the agent’s prompt. In a multi-agent system, they only need to get it into the output of any agent in the chain. Once it’s in handoff state, it propagates with the credibility of system-level communication.
The problem is structural. A receiving agent’s context window does not distinguish “trusted orchestrator state” from “output from an agent that was processing untrusted data.” Both arrive through the same channel. Without explicit structural separation, the receiving agent cannot apply different trust levels to different parts of its input.
Design signal: Handoff state should be structurally separated from agent-processed content. Data retrieved from external sources should be flagged as untrusted in the handoff schema, not passed through verbatim as part of task outputs. Receiving agents should apply skepticism proportional to the provenance of each piece of handoff content, not uniform trust to all of it.
Session Boundary as a Design Decision
The session boundary is a choice, not a constraint. Most teams treat it as a constraint and optimize nothing about it.
At the session boundary, two opposite failure modes are possible:
Session amnesia: The agent reinitializes too cleanly, losing institutional context that was never serialized. A lead forgets which workers it has already dispatched. A worker reinitializes without knowing which subtasks are already in flight. The session starts fresh, but the working state is gone. Subsequent actions duplicate work, ignore pending outputs, or restart coordination from scratch.
Session accumulation: The agent inherits too much state from prior sessions and develops drift. It continues applying heuristics that were valid in session 3 but are incorrect in session 19. Its behavior diverges from brief spec — not because of a single error, but because of accumulated context that was never validated against current conditions. Rath (2026) identifies three forms of this pattern in production agent systems: semantic drift (outputs diverge from original intent), coordination drift (inter-agent communication protocols degrade), and behavioral drift (decision-making patterns shift from original specification) 4. The Agent Stability Index (ASI) proposed in that work provides a framework for detecting when accumulated state has corrupted an agent’s behavior.
The governing design principle is: persist decisions and their rationale, not just state.
State without rationale is data without meaning. An agent reading its memory in the next session needs to know not just what was decided, but why — and what conditions the decision was contingent on. When conditions change, state-only persistence has no mechanism to flag that the decision needs revisiting.
What to Persist vs. What to Recompute
| Category | Persist? | Reasoning |
|---|---|---|
| Task outputs (verified) | Yes | Ground truth; recomputing wastes resources |
| Decisions with rationale | Yes | Future sessions need the “why” to know if conditions still hold |
| Working hypotheses | No | Stale hypotheses mislead; recompute from current state |
| Tool results | Context-dependent | Cheap to rerun: don’t persist. Expensive: cache with timestamp |
| Agent-processed external content | No | Re-fetch fresh; never trust stale external data |
| Intermediate reasoning chains | No | Costly to store, decays quickly, cannot be trusted across sessions |
| Open questions and caveats | Yes | The most important thing to persist; most often omitted |
Practical Handoff Design
Minimum Viable Handoff State
Every handoff must include, at minimum:
- What was completed — specific outputs, with verification status (verified or unverified)
- What was left open — ambiguities, pending checks, deferred decisions
- What was tried and rejected — to prevent the receiving agent from repeating discarded paths
- Provenance — which agent produced this, under what instructions, with what constraints
Absence of any of these is a structural deficiency in the protocol, not a minor omission. A handoff state that has only task outputs and status code is not a complete handoff — it is a summary that discards the information most likely to matter downstream.
Handoff Validation at Receipt
Can the receiving agent detect a malformed or incomplete handoff before acting? This is an underspecified requirement in most frameworks.
A receiving agent that begins acting on an incomplete handoff will produce outputs that look valid — it will complete something — but that something will not be the right thing. The failure will only be discovered later, when the output is used.
Design pattern: receipt confirmation before action. Before a receiving agent begins executing on a handoff, it verifies that the handoff state meets minimum completeness requirements. If it cannot confirm validity, it halts and requests clarification rather than proceeding on incomplete state.
This pattern is validated in practice. AgentAsk demonstrates that inserting minimal clarification steps at handoff boundaries — precisely when ambiguity is detected — improves accuracy by up to 4.69% across benchmarks while keeping added latency and cost below 10% 2. The cost of checking is low; the cost of proceeding on bad state is high.
Idempotency at Boundaries
If the same handoff is processed twice — because a session crashed and retried, or because a message was duplicated — what breaks?
This is a critical test for handoff design. A well-designed handoff is idempotent: processing it twice produces the same result as processing it once. This requires:
- No accumulating side effects (no “append” operations without deduplication)
- No counters or state that increments on receipt
- No outbound messages sent as part of handoff processing that would be sent twice
Most agent handoff implementations fail this test, because idempotency is not a framework default — it is a deliberate design requirement that must be built explicitly.
Confirmation Gates for High-Stakes Handoffs
For handoffs where the downstream action is irreversible or high-cost, require explicit confirmation before acting. This is not a universal requirement — most handoffs are low-stakes and mandatory confirmation would create unacceptable overhead. But for handoffs that trigger external system writes, delegation to agents with independent resource budgets, or actions that cannot be rolled back, a confirmation gate is a default, not an exception.
Decision Framework: Handoff Type → Design Requirements
| Handoff Type | Trust Posture | Verification Required | Minimum State |
|---|---|---|---|
| Worker → Lead | Evaluate, don’t assume | Yes — lead should verify before acting | Outputs + open questions + caveats |
| Lead → Worker | Accept instructions | Worker may reject unclear instructions | Directive + rationale + constraints |
| Peer → Peer | Verify independently | Optional but recommended | Outputs + provenance |
| External → Agent | Treat as untrusted | Yes — sanitize before including | Never pass through verbatim |
Conclusion
Handoff design is a first-class protocol problem. Teams that treat it as state serialization will debug ghost tasks and cascading failures that should have been caught at the boundary.
The five failure modes documented here — context serialization loss, trust escalation, ghost tasks, cascading reinit costs, and memory poisoning — are not edge cases. The MAST analysis of 1,600+ multi-agent traces identifies inter-agent misalignment as a primary failure category across seven frameworks, independent of the underlying model 1. These failures are structural, not stochastic. They occur because the handoff protocol does not capture what it needs to capture.
The fix is not more sophisticated agents. It is a more complete protocol: persist decisions with rationale, validate handoffs at receipt before acting, build idempotency into every boundary, and structurally separate trusted orchestrator state from agent-processed external content.
Session boundaries compound these problems by adding amnesia and drift as failure modes that operate on longer timescales than any single handoff. Session amnesia loses working context; session accumulation corrupts it. The only defense is deliberate design: what you persist, what you discard, and what you recompute must be explicit decisions, not defaults inherited from a framework that was designed for demos.
Most teams are not making those decisions. They are inheriting them. The gap shows up as ghost tasks, trust escalations, and behavioral drift — bugs that feel nondeterministic but are structurally inevitable given the protocol they are running on.
Handoff is not the boring part of multi-agent architecture. It is where the system fails.
Footnotes
-
Cemri, M., Pan, M. Z., Yang, S., Agrawal, L. A., et al. “Why Do Multi-Agent LLM Systems Fail?” arXiv:2503.13657 (2025). https://arxiv.org/abs/2503.13657 ↩ ↩2 ↩3 ↩4 ↩5
-
Lin, B., Yang, K., Tan, Z., et al. “AgentAsk: Multi-Agent Systems Need to Ask.” arXiv:2510.07593 (2025). https://arxiv.org/abs/2510.07593 ↩ ↩2
-
Tomašev, N., Franklin, M., Osindero, S. “Intelligent AI Delegation.” arXiv:2602.11865 (2026). https://arxiv.org/abs/2602.11865 ↩
-
Rath, M. “Agent Drift: Understanding and Mitigating Behavioral Drift in Multi-Agent Systems.” arXiv:2601.04170 (2026). https://arxiv.org/abs/2601.04170 ↩