Most multi-agent systems don't fail because the models are bad. They fail because the handoffs are.

A 2025 analysis of production multi-agent systems found that 79% of failures trace back to coordination problems -- specification ambiguity, unstructured context passing, agents misinterpreting their role in the chain. The models did their jobs fine. The wiring between them was the problem. (Cemri, Pan, Yang et al., 2025)

Before you build an elaborate multi-agent pipeline, though, you need to ask an honest question: do you actually need one?

When Multi-Agent Is Worth the Complexity

Google Research found that single agents with 45%+ baseline accuracy on a task get diminishing returns from adding more agents. Tool-heavy tasks actually suffer a 2-6x efficiency penalty in multi-agent setups versus a well-prompted single agent. (VentureBeat)

There's also the compound reliability problem. If each agent step runs at 99% reliability, a 10-step pipeline drops to 90.4% (0.99^10). At 95% per step -- more realistic for real workloads -- you're at 59.9%. Every handoff is a potential failure point.

So when does multi-agent actually make sense? When your task requires genuinely different capabilities (code generation + security review + deployment), when context windows can't hold everything at once, or when you need parallelism across independent subtasks. If a single agent with the right tools can do the job, let it.

But when you do need multiple agents, the handoff protocol is everything.

The Handoff Schema

The core idea is simple: instead of forwarding entire conversation histories between agents, you pass a structured context object. Full conversation forwarding costs 5,000-20,000 tokens per handoff and scales quadratically -- a 50-message thread with 4 handoffs means the 5th agent is processing roughly 200 messages. A typed handoff object runs 200-500 tokens.

Here's the schema that works:

{
  "handoff": {
    "task_id": "unique-identifier",
    "from_agent": "research-agent",
    "to_agent": "writing-agent",
    "timestamp": "2026-03-28T14:30:00Z",
    "task_state": {
      "objective": "Write a technical blog post on container security",
      "phase": "research_complete",
      "constraints": ["1500 word limit", "practitioner audience", "include code examples"]
    },
    "decisions_made": [
      {"decision": "Focus on runtime security, not build-time", "reason": "Reader survey showed 73% care about runtime"},
      {"decision": "Use Kubernetes examples specifically", "reason": "Most common deployment target in audience"}
    ],
    "artifacts": {
      "research_summary": "s3://pipeline/artifacts/research-2026-03-28.md",
      "source_urls": ["https://example.com/paper1", "https://example.com/paper2"],
      "key_statistics": [
        {"stat": "67% of container breaches happen at runtime", "source": "Sysdig 2025 Report"}
      ]
    },
    "open_questions": [
      "Should we cover eBPF-based monitoring or keep it higher level?",
      "Include Falco examples or stay tool-agnostic?"
    ],
    "context_window_usage": {
      "tokens_consumed": 12400,
      "tokens_remaining": 187600
    }
  }
}

Six fields. That's it. task_state tells the receiving agent where things stand. decisions_made prevents the next agent from relitigating choices. artifacts points to outputs without embedding them inline. open_questions flags what still needs judgment. And context_window_usage lets downstream agents budget their token allocation.

The decisions_made field is the one most people skip, and it's the one that matters most. Without it, your writing agent will re-research topics your research agent already rejected. Your review agent will question architectural choices your planning agent already resolved with good reasons.

Prompting the Handoff

The schema is the data format. You still need prompts that teach agents how to produce and consume it. Here's a system prompt for an agent that receives handoffs:

The Prompt:

You are the writing agent in a content pipeline. You receive structured handoff objects from the research agent and produce draft blog posts.

HANDOFF PROTOCOL:
1. Parse the handoff object completely before starting work.
2. Treat decisions_made as FINAL. Do not revisit or second-guess these choices. If you disagree, note it in your own handoff's open_questions -- do not override.
3. Use artifacts by reference. Fetch and read them, but do not duplicate their full content in your output.
4. Address every item in open_questions with either a decision (add to your decisions_made) or escalation (keep in your open_questions).
5. When you complete your task, produce a new handoff object for the next agent in the chain.

CURRENT HANDOFF:
{handoff_json}

Write the blog post according to the task_state constraints, using the research in artifacts. Then output your handoff object for the review agent.

Why This Works: The prompt establishes clear rules about decision authority -- the receiving agent can't override upstream decisions, only flag disagreements. It forces the agent to process the full handoff before acting, and requires it to produce a handoff for the next agent in the chain.

Expected Output:

The agent would produce the blog post content followed by a new handoff object where from_agent is writing-agent, to_agent is review-agent, decisions_made includes any open questions it resolved, and artifacts points to the draft it just created.

Three Approaches Compared

Not every pipeline needs the full schema. Here's when to use what:

Full context forwarding passes the entire conversation history. Zero information loss, but it costs 5,000-20,000 tokens per handoff and breaks down after 3-4 agents. Use it for simple two-agent setups where you can afford the tokens.

Structured context objects (the schema above) run 200-500 tokens with controlled, schema-defined information loss. This is the right choice for production pipelines with 3+ agents. You decide what crosses the boundary.

Summarized context uses an LLM to compress the conversation into 500-2,000 tokens. Cheaper than full forwarding, but you lose 10-30% of information and add 500ms-1.5s latency per handoff for the summarization call. Use it for long-running conversations where structured objects would be too rigid.

The best pipelines mix these. Use structured objects for the main handoff chain. Attach full context for critical transitions where you can't afford any loss. Summarize for background context that's useful but not essential.

The Standards You Should Know About

Two protocols are shaping how agent handoffs work at the infrastructure level.

MCP (Model Context Protocol) standardizes how agents connect to tools and data sources. Originally from Anthropic (November 2024), now under the Linux Foundation. The 2026 roadmap includes Agent Graphs with standardized handoff patterns. MCP is about agent-to-tool communication.

A2A (Agent2Agent Protocol) standardizes how agents talk to each other. From Google (April 2025), also now Linux Foundation. Uses Agent Cards -- JSON files at /.well-known/agent-card.json -- for capability discovery. A2A is about agent-to-agent communication.

They're complementary, not competing. MCP handles what an agent can do. A2A handles how agents find and talk to each other. Your handoff schema sits on top of both -- it's the content of the message, while MCP and A2A are the transport.

Framework-Specific Patterns

Anthropic's agent teams (launched February 2026) use task lists and peer-to-peer messaging for state sharing. The production-tested sweet spot is 2-5 specialized agents with 5-6 tasks each. State flows through a shared task system, not full context forwarding. Teams larger than 5 hit coordination overhead that cancels parallelism gains.

In OpenAI's Agents SDK, handoffs are first-class functions. You define a handoff that specifies which agent receives control and what context transfers with it. The framework handles the routing; you control the payload.

LangGraph uses typed state channels -- each node in the graph reads from and writes to explicitly typed state objects. This is the closest to the structured handoff schema pattern, because the state object IS the handoff.

In all three cases, the principle is the same: define what crosses the boundary, make it explicit, and don't pass more than the receiving agent needs.

The Honest Take

The best handoff protocol is no handoff. Anthropic's programmatic tool calling lets a single agent write code that orchestrates multiple tools, processes outputs, and manages its own context -- all in one turn. Models are getting better at handling complex multi-step tasks without needing to be split across agents.

Gartner projects that 40%+ of agentic AI projects will be canceled by end of 2027 due to escalating costs and unclear value. A lot of those will be over-engineered multi-agent systems that should have been one agent with good prompts and the right tools.

But when you genuinely need multiple agents -- when the task truly requires different capabilities, different context windows, or parallel execution -- a structured handoff protocol is the difference between a pipeline that works and one that fails 4 times out of 10.

Start with a single agent. Split only when you hit a real wall. And when you split, make the handoffs explicit, typed, and minimal. Your future debugging self will thank you.

Want hands-on training on building reliable agentic workflows for your team? Connect with Kief Studio on Discord or schedule a session.

multi-agent handoff

Agent Handoff Protocols: How to Transfer State Between Specialized Agents Without Context Loss