What can go wrong in a multi-agent handoff?

Two capable agents can fail at the boundary between them. A planner assigns “verify the supplier,” but the receiving agent cannot tell which supplier record, which verification standard or whether it may contact an external service. It does useful-looking research, returns a confident summary, and the planner marks the task complete. Every local step appears reasonable; the workflow is wrong.

The handoff is a protocol, not a passage of prose. It has to preserve the task, evidence, state and authority while making acceptance and completion unambiguous.

Eight failures hide inside a simple transfer

Failure	What the receiver experiences	Consequence
Goal drift	A paraphrase changes the requested outcome	Work solves a nearby problem
Context loss	Decisive evidence or constraint is missing	Receiver fills gaps with assumptions
Context contamination	Untrusted instructions travel as authoritative context	Receiver follows hostile or irrelevant direction
Authority inflation	Broad credentials arrive with a narrow task	Receiver can act beyond the mandate
Ownership ambiguity	Both agents act, or neither believes it owns the step	Duplicate work or silent omission
State divergence	Sender and receiver hold different workflow versions	Late work overwrites a newer decision
Completion ambiguity	“Done” means drafted to one agent and verified to another	Workflow closes too early
Failure suppression	Timeout or partial result is summarised as success	Recovery never begins

These failures compound. Missing context can cause a worker to ask for a broader tool; authority inflation then turns the misunderstanding into an external effect.

Make the handoff envelope structured

Use a machine-enforced envelope with human-readable explanation. Include:

• unique task and parent workflow IDs;
• sender and intended receiver identities;
• goal and explicit non-goals;
• input references with provenance and access labels;
• expected output schema and completion evidence;
• delegated tools, permissions, scope and expiry;
• budget, deadline and retry limits;
• current workflow and contract versions;
• acknowledgement deadline;
• escalation route; and
• deduplication key.

The receiver should validate the envelope before starting. If required context is unavailable or the requested work exceeds its capability or authority, it should reject or ask for a corrected handoff. “Best effort” completion is dangerous when the planner interprets any response as success.

The MAST research found failure modes across system design, inter-agent misalignment, and verification or termination. That grouping maps directly to the handoff: specify the contract, align the participants on it, and verify what completion means.

Preserve provenance without forwarding everything

A receiving agent needs enough context to perform its task, not the sender’s entire context window. Forwarding a full transcript can expose irrelevant sensitive data, import untrusted instructions and bury the actual constraint.

For each material input, pass:

1. a stable reference or minimised value;
2. source identity and version;
3. why it is relevant;
4. whether it is an observation, instruction, hypothesis or prior agent output;
5. the access decision that permits this receiver to use it; and
6. any conflict or expiry the receiver must handle.

Do not let one agent’s conclusion become fact merely because it arrived in a trusted envelope. Preserve the difference between “system record shows payment received” and “research agent believes payment probably arrived.”

Surveys of LLM-based multi-agent systems describe communication, workflow and memory as core infrastructure challenges (Vicinagearth). The practical design response is typed, attributable context rather than an undifferentiated conversation buffer.

Delegate capability, not a shared master credential

The receiving agent should obtain only the tools and rights needed for its assigned task, for a bounded time. Preserve the actor chain so downstream systems can distinguish the user or service on whose behalf work occurs from the agent that performed it.

RFC 8693 formalizes a distinction between delegation and impersonation and allows an actor to remain represented in a token chain. An agent protocol need not implement that RFC to adopt the principle: retain subject, actor, scope, audience and expiry; avoid handing every worker the orchestrator’s standing credential.

Revoke or expire the grant when the task completes, is cancelled or moves to another owner. If the receiving agent wants to delegate again, require policy to allow that step and preserve the chain rather than silently multiplying authority.

Treat acknowledgement and completion as different events

A reliable handoff has at least four protocol events:

1. offered — the sender records the proposed assignment;
2. accepted — the receiver validates and takes responsibility under a lease;
3. result-submitted — the receiver supplies output and evidence; and
4. result-verified — the orchestrator or another control confirms the contract was met.

Message transport acknowledgement proves only delivery to infrastructure. It does not show that the agent accepted the task. Likewise, an agent’s completion message is a claim, not verification.

Use leases or deadlines to handle abandoned work. A late result from an expired lease should not overwrite a newer assignment. It can be retained as evidence and compared, but the state transition must follow the current workflow version.

Specify completion in observable terms

Replace “research the issue” with a completion contract such as:

Return the current regulator-issued rule, publication date and applicable section for jurisdiction X; identify conflicts or absence; do not contact external parties; complete only when every claim links to the primary text.

For action tasks, define the authoritative end state and required receipt. For analysis, define the evidence coverage and output schema. For code, define repository state and tests. For a human escalation, define queue acknowledgement and decision record.

MultiAgentBench uses milestone-based measures and compares coordination topologies. That approach reflects a key evaluation lesson: coordination quality cannot be inferred from a final answer alone.

Test handoffs under adversarial timing

Run protocol tests that force:

• duplicate delivery to the same and different workers;
• lost acknowledgement after acceptance;
• result arrival after lease expiry;
• cancellation while a tool action is in flight;
• sender restart after dispatch;
• receiver restart after an external effect;
• incompatible protocol versions;
• omitted or unauthorised context;
• a malicious instruction inside a referenced document; and
• a worker returning a plausible answer without required evidence.

Assert task ownership, external effects, permission scope and final workflow state. Also measure the cost of coordination: message volume, repeated context, latency, model calls and human recovery. Multiple agents should not be retained merely because their traces look collaborative.

NIST’s tool-use taxonomy distinguishes tools by access pattern, statefulness and risk. Include those attributes in handoff scenarios because transferring a research task is not equivalent to transferring a write-capable action.

Decide whether the extra boundary earns its cost

Compare the multi-agent workflow with a single agent or fixed pipeline using the same cases. Keep the handoff when it provides evidenced value: specialist capability, separation of duties, bounded context, independent verification or fault isolation. Remove it when it adds mainly translation, latency and another failure surface.

A release review should answer:

• What information can be lost or distorted at each boundary?
• Which authority can cross, and how is it constrained?
• Who owns work at every state?
• What evidence establishes acceptance and completion?
• How does the system reconcile duplicates, late results and cancellation?
• Does the multi-agent design outperform the simpler baseline on the decision that matters?

Agents do not become a team because they can send messages. They become an operable system when their protocol keeps intent, evidence, authority and state intact across every transfer.