Multi-Agent Handoffs Need a Receiving Contract
When one agent finishes its part of a job, the next agent should not have to reconstruct the work from conversation history. A handoff is reliable only when it names the artifact, the decision boundary, and the work that remains.
This article develops a practical handoff contract for multi-agent workflows: a small record that lets agents transfer work without losing context, repeating side effects, or creating an invisible queue.
The handoff is a boundary, not a message
A message says what someone chose to tell the next participant. A handoff marks the point at which responsibility moves. That distinction matters in agent systems because the receiving agent may run later, under a different prompt, with different tools, or after the original context has expired.
A useful handoff therefore answers four questions:
- 1. What work was requested?
- 2. What has been completed and where is the evidence?
- 3. What remains unresolved?
- 4. What may the receiver do next?
Without those answers, “research complete” is ambiguous. Did the agent check all required sources? Did it write a brief? Is the result ready for drafting, or is a claim still waiting for review? The next agent should not need to guess.
A small contract is enough
The contract does not need to reproduce the entire execution trace. It needs stable fields that downstream code and operators can inspect:
``json { "handoff_id": "travel-brief-2026-08-19", "from": "researcher", "to": "itinerary-planner", "status": "ready", "completed": ["compare routes", "record constraints"], "artifacts": ["research/route-brief.md"], "open_questions": ["confirm refundable fare preference"], "allowed_next_step": "draft itinerary; do not book", "evidence_timestamp": "2026-08-19T15:30:00Z" } ``
The names are less important than the distinctions. completed describes work, while artifacts points to proof. open_questions prevents uncertainty from being mistaken for completion. allowed_next_step expresses scope, especially when booking, sending, publishing, or another external effect is out of bounds.
A handoff should also have an identifier that survives retries. If the receiving agent sees the same identifier twice, it can recognize a resume or duplicate rather than starting a second workflow.
Separate facts from instructions
The most useful handoffs keep observations separate from recommendations. “The fare is refundable” is a fact that should point to its source. “Book this fare” is an instruction that may require approval. Combining them in one prose paragraph makes it difficult to tell which parts are verified and which parts are proposed.
This separation is particularly important in multi-agent teams. A researcher can establish facts without granting the planner permission to purchase. A planner can prepare an itinerary without granting a booking agent permission to charge a card. Each boundary should preserve the review state instead of silently escalating authority.
In DAL terms, the handoff can be a returned map consumed by the next stage. The coordinator can validate required fields, persist the record, and route ready, blocked, or waiting_review differently. The language-level value is preferable to parsing a transcript because its shape is explicit and its consumers are testable.
Design for partial completion
Real workflows stop halfway. A source may be unavailable, a required preference may be missing, or a tool may fail after producing useful artifacts. A good handoff makes that state visible rather than forcing the next agent to choose between repeating everything and proceeding blindly.
For example:
``json { "handoff_id": "trip-brief-42", "from": "researcher", "to": "planner", "status": "blocked", "completed": ["destination shortlist"], "artifacts": ["research/destinations.md"], "blocked_on": "dates are not confirmed", "safe_resume": "collect dates; preserve existing shortlist" } ``
safe_resume is a recovery boundary, not a command to bypass policy. It tells the next participant what can be reused. The receiver should still validate that the artifact exists, is current enough, and matches the original request.
This approach also makes queue management clearer. A blocked handoff belongs in a human-input queue. A waiting_review handoff belongs in an approval queue. A ready handoff can move to the next autonomous stage. Treating all three as generic “pending” work creates noise and encourages unsafe retries.
Make acceptance explicit
The receiving agent should acknowledge the handoff with a result of its own. Acceptance can confirm that the artifact was found, the scope was understood, and the next action is permitted. Rejection should identify the missing field or invalid assumption rather than merely returning an error.
A minimal acceptance record might include:
- the original
handoff_id; - the receiver and timestamp;
- the artifact paths actually consumed;
- the next stage entered;
- any constraints carried forward.
This creates a chain of custody for context. If a later result is wrong, the operator can see which handoff introduced the bad assumption. That is more useful than attributing every mistake to “the model.”
Keep the record concise. Detailed traces belong in logs and research files; the handoff should remain readable enough for an operator to review quickly. Version the schema when persisted records may outlive a deployment, and reject malformed handoffs early rather than letting missing context surface as a downstream hallucination.
A practical adoption path
Start with one workflow that already has clear stages. Define three statuses—ready, blocked, and waiting_review—and require an artifact path plus one explicit next-step field. Add identifiers before adding more metadata; deduplication and resumption are usually more valuable than a large schema.
Then test the uncomfortable cases: the producer completes but cannot write its artifact, the receiver gets the same handoff twice, a source becomes stale, and an external action is proposed before approval. The desired behavior should be visible in the returned record: preserve completed work, stop at the correct boundary, and tell the operator what input or approval is needed.
Finally, make the contract part of the workflow interface. Document which agent owns each stage, which fields it must produce, and which effects remain gated. Once the handoff is treated as a durable artifact rather than incidental prose, adding another agent becomes a controlled integration task instead of another prompt chain.
Conclusion: transfer responsibility without transferring ambiguity
Multi-agent orchestration does not become dependable merely by adding more specialists. It becomes dependable when each specialist can hand work to the next one with evidence, limits, and an unambiguous state.
Choose one staged job this week. Define its handoff record, persist it beside the artifacts it references, and require the receiver to acknowledge what it consumed. Keep external actions behind their existing review gates. The result is a quieter system: fewer repeated investigations, fewer invisible blockers, and a clear answer to the most important operational question—what is the next safe step?