The Handoff Protocol That Keeps My Agents From Stepping On Each Other

Everyone talks about agents like they're employees. They're not. Employees figure out the messy middle. Agents don't. When you string three or four agents together to run a real workflow, the thing that breaks isn't the model. It's the handoff between them.

We learned this the hard way at 47. Our first multi-agent pipeline had a research agent feeding a writer agent feeding an editor agent feeding a publisher. Looked beautiful on a whiteboard. In production it produced garbage about 30% of the time. Not because any single agent was bad. Because they were stepping on each other.

This post is the protocol we built to fix it. We call it the Handoff Contract. It's boring. It works. If you're running anything more complex than a single agent loop, you need something like it.

Why agent pipelines actually fail

When a pipeline breaks, you'll usually blame the model. Wrong tool call, hallucinated field, lost context. But trace it back and the real failure is almost always at the seam between two agents.

Here's what actually goes wrong:

• Agent A produces output Agent B can't reliably parse. Maybe it's JSON 90% of the time and prose 10% of the time. B chokes on the 10%.
• Agent B assumes context Agent A never wrote down. A knew the user wanted a technical tone. B writes for executives.
• Both agents share a tool and race for it. Both try to write to the same file or hit the same API key with conflicting params.
• Errors propagate silently. A returns a half-broken result, B treats it as gospel, and by the time you see output four agents downstream, you can't tell where it went wrong.

None of these are model problems. They're protocol problems. Same way two services in a distributed system don't fail because the code is wrong, they fail because the contract between them is fuzzy.

The Handoff Contract

Every agent-to-agent handoff in our system has to satisfy four rules. We enforce them in code, not in prompts.

1. Structured output, always

No agent ever passes free text to another agent. Period. Every handoff is a typed schema. We use Zod on the TypeScript side and Pydantic where we're in Python. If an agent can't produce a valid schema, it doesn't get to hand off. It retries, or it escalates.

This sounds obvious. Most people don't actually do it. They let agents pass prose to each other because it feels flexible. It's not flexible. It's fragile.

2. Explicit context, no inheritance

The next agent in the chain does not see the previous agent's full context window. It sees the structured output, plus a small explicit context block that the upstream agent has to write deliberately.

That context block has three fields: goal, constraints, assumptions. The upstream agent has to fill them in. If it can't, that's a signal the handoff isn't ready.

This is the single highest-leverage change we made. When agents have to explicitly write down what they're handing over, they stop assuming the next agent will just figure it out.

3. One writer per resource

If two agents can write to the same thing, you will have a collision. Eventually. Doesn't matter how unlikely it seems.

So we enforce single-writer for every shared resource. Database tables, files, API endpoints, anything stateful. One agent owns it. Other agents request changes through that agent, they don't write directly. This is just basic ownership but you'd be surprised how often people skip it because their pipeline is small.

4. Errors bubble up immediately

If an agent produces output that fails validation, the pipeline stops. It does not pass a degraded result downstream. It does not try to repair silently. It surfaces the error to the orchestrator, which decides whether to retry, route around, or kick to a human.

The temptation is to make agents resilient by having them "do their best" with bad input. Don't. That's how you end up with a publish step that puts garbage on your site because the writer compensated for bad research and the editor compensated for bad writing.

What this looks like in practice

Here's a stripped-down version of one of our actual handoffs. This is a research agent passing to a writer agent.

The research agent's output schema looks like this:

• findings: array of claims with sources and confidence scores
• open_questions: things the research couldn't resolve
• recommended_angle: one of a fixed set of angles, not free text
• handoff_context: the goal/constraints/assumptions block

The writer agent literally cannot start without all of those fields. If recommended_angle is null, the pipeline halts and pings me. If open_questions has items above a threshold, it routes back to research for another pass before writing.

The writer never sees the research agent's reasoning. It only sees the structured output. This is on purpose. The writer should not be influenced by how the researcher got to its conclusions, only by the conclusions themselves.

The orchestrator's job

You need an orchestrator. It can't just be "agent A calls agent B." That works for two agents. By four, it's a tangled mess.

Our orchestrator does three things and only three things:

1. Validates handoffs. Every output gets schema-checked before it moves forward.
2. Routes based on state. Not based on what the previous agent says to do. Based on the actual state of the work item.
3. Owns retries and escalation. Individual agents don't retry themselves. The orchestrator decides.

This keeps agents stateless and dumb, which is what you want. Smart agents inside a dumb orchestrator beats smart orchestration inside dumb agents every time. The model is the smart part. Everything around it should be boring.

The debugging payoff

The real reason to do all this isn't reliability. It's debuggability. When something breaks in a pipeline that follows the Handoff Contract, you can point at the exact seam where it broke. You see the input, you see the output, you see the validation failure. Fix takes minutes.

Without the contract, debugging a multi-agent pipeline feels like trying to figure out why a dream didn't make sense. You're squinting at logs trying to reconstruct what the model was thinking three steps ago. Don't do that to yourself.

Start smaller than you think

If you're building your first agent pipeline, don't start with four agents. Start with two. Get the handoff between those two bulletproof. Then add a third.

The mistake I see most often from people copying our setup is wiring up six agents on day one and wondering why nothing works. The agents aren't the hard part. The contracts between them are. And contracts get harder to design the more parties are involved.

Two agents with a clean handoff will outperform six agents with sloppy handoffs every single time. By a lot.

This is the unsexy work of running a business on agents. Not prompt engineering. Not picking the right model. Protocol design. It's the difference between a demo and a system that actually runs your operation while you sleep.