Multi-Agent Handoff Prompts: How to Write Instructions That Transfer Context Between Agents

Most multi-agent systems fail at the boundaries. Not because the models are bad, but because the handoff prompt -- the instructions that transfer context from one agent to the next -- loses critical information every time control passes.

A May 2025 study from Gao et al. found that as frontier models improve in long-context reasoning and tool use, the accuracy gains from splitting work across multiple agents actually shrink. Google Research, Google DeepMind and MIT tested 180 agent configurations and found the answer depends on the task: coordination helped a lot on work that splits into parallel pieces and hurt on sequential work, where the overhead ate the gains.

So why cover multi-agent handoffs at all? Because when you genuinely need them -- when a single agent can't hold the full context or when you need specialized tool access at different stages -- the handoff prompt is the single point of failure. Get it right and your five-agent chain maintains fidelity from start to finish. Get it wrong and you're playing telephone.

The cost of bad handoffs

Each agent in a multi-agent system carries its own system prompt. Context overlap between agents creates massive redundancy -- multi-agent runs consume roughly 15x more tokens than a single-agent chat on the same task, according to Anthropic's write-up of its multi-agent research system.

That's the token cost. The accuracy cost is worse.

A NeurIPS 2025 paper from Cemri, Pan, and Yang identified specific failure modes at handoff boundaries: unexpected context truncation (the receiving agent loses conversation history), conversation reset (the agent reverts to an earlier state), and inter-agent misalignment (gradual drift from the original task through ineffective communication between agents).

Every one of these failures traces back to what the handoff prompt did or didn't include.

Three handoff architectures and their tradeoffs

Before writing handoff prompts, you need to understand which architecture you're working with. Each one demands a different approach.

Full history pass-through. The receiving agent gets the entire conversation history and its own specialized system prompt. OpenAI's Agents SDK (evolved from Swarm) uses this pattern -- when a handoff happens, the system prompt swaps but the full chat history persists. The receiving agent parses what it needs from shared history through the lens of its own instructions. This works for short conversations. It breaks down in long-running workflows because the receiving agent drowns in irrelevant context.

Structured artifact handoff. Instead of passing conversation history, the sending agent writes a structured document -- a progress file, a state object, a briefing -- and the receiving agent reads that artifact. Anthropic describes this pattern in its harness for long-running agents: an initializer agent writes a claude-progress.txt file and makes a git commit, then the coding agent reads that structured state on every subsequent session. The progress file plus git history becomes the handoff mechanism. No summarized chat. Queryable artifacts.

Hierarchical with supervisor. One coordinating agent manages the workflow and passes targeted context to specialist agents. Research from Huang et al. (arXiv:2408.00989) shows this topology is the most resilient -- a hierarchical structure lost only ~5% accuracy when faulty agents were introduced, while a simple chain topology collapsed by ~24%. The tradeoff is that the supervisor becomes a bottleneck and a single point of failure.

The structured briefing pattern

Across multiple sources and production implementations, one pattern keeps emerging as the most reliable: the structured briefing. Instead of dumping raw history or trusting naive summarization, you pass a formatted context block with explicit sections.

Here's what a handoff prompt looks like using this pattern:

You are the code review agent. You receive work from the implementation agent.

## Your briefing

### Objective
{task_objective}

### Constraints
{constraints_list}

### What was already done
{completed_steps_summary}

### Decisions made and why
{decision_log}

### Current state
{current_artifacts_and_their_locations}

### What you need to do next
{next_step_description}

### Compliance rules that apply to this task
{governance_rules}

## Your instructions
Review the implementation against the objective and constraints above.
Flag any deviation from the decisions already made.
Do not re-decide anything in the decision log unless you find a blocking issue.
If you find a blocking issue, document it with evidence and return control
to the supervisor agent.

This prompt works because it gives the receiving agent everything it needs in a parseable structure -- without forcing it to reconstruct context from a wall of conversation history. The decision log is the critical piece most handoff prompts miss. Without it, the receiving agent will re-litigate decisions the previous agent already made.

The context priority hierarchy

You can't pass everything. Context windows are finite and tokens cost money. Here's how to prioritize what goes into a handoff:

Always pass: The system instructions for the receiving agent's role. The current workflow state (what step are we on, what's done, what's next). Active constraints and compliance rules.

Pass when relevant: Tool outputs from the current step. The decision log (what was decided and why). Error states or retry history.

Summarize: Older conversation turns. Long documents the previous agent consumed. Research or background context.

Discard: Redundant tool outputs (keep the final result, drop intermediate calls). Stale data from earlier steps that's been superseded. The previous agent's internal reasoning about how to structure its own work.

In multi-agent systems, the handoff prompt is where governance lives. If you're discarding compliance rules or constraint lists to save tokens, you're building a system that works in testing and fails in production.

A complete handoff example

Here's a realistic two-agent handoff for a content pipeline -- one agent researches, the next writes:

You are the writing agent for the content pipeline.

## Briefing from research agent

### Topic
{topic_title}

### Research findings
{research_summary_with_sources}

### Target audience
{audience_description}

### Required elements
- Must cite at least 2 of the provided sources with links
- Must include one concrete example with code/prompt
- Word count: 1000-1500
- Tone: educational, direct, second person

### Constraints
- Do not make claims beyond what the research supports
- Do not invent statistics or case studies
- If the research is insufficient for a section, flag it rather than fabricating

### Decision log
- Research agent chose angle: {chosen_angle} because {reason}
- Research agent excluded {excluded_topic} because {reason}

### Output format
Write the full post in markdown. Place source citations inline as hyperlinks.
When complete, save to {output_path} and report status.

This prompt tells the writing agent what to do, what it has to work with, what it can't do, and why certain decisions were already made. The writing agent doesn't need to see the fifteen tool calls the research agent made to gather sources. It needs the distilled findings and the rationale.

When you don't need multi-agent at all

Gartner reports a 1,445% surge in multi-agent system inquiries between Q1 2024 and Q2 2025. They also predict over 40% of agentic AI projects will be canceled by end of 2027 due to cost, unclear value, or risk.

The honest advice: start with a single agent. Give it good tools, clear instructions, and structured context. If a specific step keeps failing -- and you've confirmed it's failing because of context limits or specialized tool access, not because of a bad prompt -- split that one step into a sub-agent. This is the "hybrid" approach proposed in recent research and it's the one that actually ships.

Multi-agent coordination is a real skill worth learning. But the first prompt engineering problem to solve is always the single-agent prompt. If you can't write clear instructions for one agent, splitting the work across five won't fix anything. It'll just spread the confusion around.

Put it into practice

Pick one workflow you've been considering for multi-agent orchestration. Before splitting it, try writing a single structured briefing prompt that covers the full task. If the context fits in one agent's window and the agent can access all the tools it needs, you just saved yourself 15x in token costs and eliminated every handoff failure mode.

If you do need the split, use the structured briefing pattern above. Pass objectives, constraints, decisions, and state. Summarize history instead of dumping it. And always include the decision log -- it's the difference between agents that coordinate and agents that contradict each other.

If your team is building agentic systems and struggling with agent coordination, Kief Studio runs hands-on training sessions covering prompt architecture for single and multi-agent workflows. Join the conversation on Discord or book a session.