AI Agent Handoff Patterns: How to Pass Context Between Agents Without Losing Your Mind

If you've ever built a multi-agent workflow and watched it fall apart mid-task — an agent that "forgot" what the previous one did, or a handoff that dropped critical context — this guide is for you.

Handoffs are where most multi-agent systems quietly fail. Here's how to get them right.

Why Handoffs Break

When Agent A finishes and Agent B picks up, several things can go wrong:

1. Context truncation — Agent B gets a summary so short it's useless
2. Format mismatch — Agent A returns prose; Agent B expects structured data
3. Silent assumptions — Agent A "knew" the user's name; Agent B doesn't and never asks
4. Lost reasoning — Agent A figured out something clever; Agent B starts from scratch

Most multi-agent failures aren't intelligence failures. They're handoff failures.

The Four Handoff Patterns

1. The Baton Pass (Sequential, Structured)

Each agent produces a structured output that explicitly feeds the next agent's input.

How it works:

Agent A → JSON output → Agent B prompt includes JSON → Agent B → JSON output → Agent C

When to use it: Linear pipelines where each step has a clear input/output contract (research → draft → edit → publish).

Make it work:

• Define a schema for each handoff object upfront
• Include a context field that carries forward anything the next agent needs to know
• Add a reasoning field — let Agent A explain why it made key decisions

Example handoff object:

{
  "task": "draft_blog_post",
  "topic": "AI agent handoffs",
  "key_points": ["...", "..."],
  "tone": "practical, no fluff",
  "audience": "solopreneurs building agent workflows",
  "context": "User wants this published today, emphasis on quick wins",
  "reasoning": "Chose 3 examples over 5 — user said keep it short"
}

2. The Briefing (Summary-First Handoff)

Before handing off, Agent A writes a briefing document — a short, structured summary of what happened and what Agent B needs to know.

How it works:

Agent A completes task → writes briefing → briefing injected into Agent B's system prompt

When to use it: Long-running tasks where full conversation history is too expensive to pass forward. Research agents, customer support escalations, project management.

Briefing template:

## Handoff Briefing

**Completed:** [what Agent A did]
**Key findings:** [bullet points]
**Decisions made:** [and why]
**Open questions:** [what Agent B should resolve]
**Watch out for:** [edge cases, constraints, user preferences]
**Next action:** [exactly what Agent B should do first]

The "Watch out for" section is the one most people skip. It's the most valuable.

3. The Shared Memory Pattern

Instead of passing context agent-to-agent, all agents read and write to a shared state object (a file, a database row, a structured doc).

How it works:

Shared state file ← Agent A reads/writes
                  ← Agent B reads/writes
                  ← Agent C reads/writes

When to use it: Parallel workflows, long-running projects, situations where agents might need to revisit previous context.

In practice:

• Use a Markdown file or JSON file as your "working memory"
• Each agent reads the full state at start, writes updates at end
• Include a lastupdatedby and timestamp field so agents know what's fresh
• Keep a changelog array — append, don't overwrite

This is how MEMORY.md works in OpenClaw. Each agent session reads it, updates it, and future sessions benefit. Same principle scales to any multi-agent system.

4. The Supervisor Pattern

A coordinator agent manages all handoffs. Sub-agents report back to it; it decides what to pass where.

How it works:

User request → Coordinator → assigns to Agent A
Agent A reports back → Coordinator → assigns to Agent B with context package
Agent B reports back → Coordinator → synthesizes and responds to user

When to use it: Complex workflows with branching logic, error recovery, or dynamic task routing.

The coordinator's job:

• Maintain the master context
• Decide what each sub-agent actually needs (not everything — just what's relevant)
• Handle failures: if Agent B fails, the coordinator retries or reroutes
• Synthesize final output

Key insight: The coordinator doesn't need to be your smartest/most expensive model for every step — it just needs to route well. Save the heavy models for the actual task agents.

The One Thing That Kills Every Handoff Pattern

Assuming the next agent will figure it out.

It won't. Every handoff should be designed as if the receiving agent has zero context beyond what you explicitly provide. That discipline forces you to:

• Be explicit about constraints ("must be under 500 words")
• Carry forward user preferences ("user prefers bullet lists over prose")
• Pass failure context ("Agent A tried X and it didn't work because Y")

If you wouldn't be comfortable handing this to a new contractor on their first day with no briefing, the handoff isn't ready.

Quick Checklist

Before any agent hands off to another:

• [ ] Is the output format the next agent expects?
• [ ] Are key user preferences included?
• [ ] Is there a clear "next action" statement?
• [ ] Are any constraints or hard limits stated?
• [ ] Are decisions explained (not just stated)?
• [ ] Are open questions flagged?

Applying This to Your Setup

If you're using the Ask Patrick Library, the agent configs there already follow the Baton Pass and Shared Memory patterns. The SOUL.md/MEMORY.md architecture is a live example of the Shared Memory pattern in practice.

For Workshop subscribers: bring your specific handoff failures to a session. Most can be fixed with a better handoff schema or a 5-line briefing template.