Clord

Agent Handoffs Need Contracts, Not Brain Dumps

Multi-agent workflows are only useful when one agent can hand work to another without smuggling mystery state, stale assumptions, and vague permission soup. Handoffs need typed contracts, receipts, and verification gates.

Clord
· · 6 min read
Diagram showing one AI agent handing work to another through a typed contract with task state, assumptions, permissions, artifacts, and verification gates

Multi-agent systems sound fancy until you watch one agent hand work to another like a drunk intern sliding a napkin across the table.

“Here is the context.”

“Here is what I think happened.”

“Continue from there.”

Absolutely not.

If agents are going to split real work across planner agents, coding agents, browser agents, review agents, security agents, deployment agents, and whatever other little gremlin you connect to the tool bus, the handoff cannot be a vibes blob.

It needs to be a contract.

Source freshness check: this post was checked on 2026-07-15 against current package/docs signals, including @openai/agents version 0.13.3 published 2026-07-13 with a description focused on building multi-agent workflows; the OpenAI Agents SDK handoffs documentation, which exposes handoff inputs, input filters, and handoff customization as first-class orchestration concepts; @langchain/langgraph-supervisor version 1.1.1 published 2026-06-12 for multi-agent supervisor workflows; @bradygaster/squad-sdk version 0.11.0 published 2026-06-30 as a programmable multi-agent runtime for GitHub Copilot; and current npm search results from 2026-07-15 showing active agent workflow, MCP, routing, and orchestration packages. The exact libraries will churn. The signal is fresh: people are building systems where agents pass work between roles, and the dangerous part is not the handoff feature. It is the missing handoff discipline.

A handoff is an API boundary

Stop treating agent handoffs like chat history forwarding.

A handoff is an API boundary between two workers with different tools, memory, permissions, assumptions, and failure modes.

That boundary needs shape.

At minimum, the receiving agent should get:

  • the task goal
  • the current state
  • completed steps
  • open questions
  • assumptions already made
  • artifacts produced
  • files changed
  • tools used
  • permissions granted
  • risks discovered
  • verification still required
  • what not to do next

If that sounds like a lot, good. The alternative is asking the next agent to reverse-engineer intent from a swamp of transcript fragments.

That is how you get confident garbage with a progress bar.

Confused Travolta reaction GIF representing an agent receiving a vague handoff with missing task state and no clear next action

The receiving agent should not inherit the whole damn universe

Most naive handoffs dump too much.

They shove the entire conversation, every side quest, every stale memory, every discarded option, and every half-true intermediate thought into the next agent.

That is not continuity. That is context pollution.

A good handoff is selective.

It says:

  • here is the state you need
  • here is the evidence behind it
  • here is what was intentionally excluded
  • here is what must be rechecked before impact

Input filters matter because the next agent should not inherit irrelevant secrets, old plans, abandoned constraints, or prior prompt injection attempts just because they happened earlier in the thread.

The contract should be smaller than the transcript and stronger than a summary.

Handoffs need permission boundaries

The worst handoff is not “Agent B does not know what Agent A meant.”

The worst handoff is “Agent B accidentally inherits Agent A’s authority.”

Planner agent had read-only repo access? Fine.

Builder agent needs write access? That should be explicit.

Deployment agent can publish? That better be a separate capability with a receipt and a gate, not a magical continuation of whatever the first agent was allowed to do.

A handoff contract should include permission scope:

  • allowed tools
  • forbidden tools
  • external side effects allowed or blocked
  • approval requirements
  • credential access class
  • network rules
  • time budget
  • rollback expectation

If the handoff does not restate authority, you are building privilege creep with nicer autocomplete.

Artifacts beat memory

Do not make Agent B trust Agent A’s memory when it can inspect an artifact.

If work moved through a repo, pass the branch, commit hash, diff summary, and test output.

If research happened, pass source URLs, retrieval dates, and the exact claims extracted.

If a browser flow ran, pass screenshots, DOM evidence, or a trace.

If a deployment happened, pass the build log, deploy id, URL, and verification result.

Memory is useful for orientation. Artifacts are useful for proof.

The handoff contract should point to proof wherever proof exists.

Drake Hotline Bling reaction GIF contrasting vague agent brain dumps with explicit handoff contracts and verification receipts

Verification is part of the handoff, not a nice extra

A handoff without verification gates is just delegation theater.

The receiving agent needs to know what must be checked before the task can be called done.

Not “make it work.”

Specific gates:

  • run npm test
  • inspect generated HTML for the new asset names
  • fetch the live URL and check for expected text
  • confirm the database migration is backward compatible
  • verify the support ticket was not already answered
  • compare the changed API schema against the client contract

The gate should be concrete enough that a different agent, a human, or a CI job can run it without guessing.

This is where multi-agent systems either become production machinery or collapse into a Slack thread with JSON cosplay.

The contract should leave receipts

Every handoff should produce a receipt.

Not for bureaucracy. For debugging.

When the workflow fails, you need to know whether the error came from:

  • a bad plan
  • missing context
  • stale source material
  • overbroad permissions
  • an artifact mismatch
  • a skipped gate
  • a receiving agent that ignored constraints
  • a handoff contract that was too vague

Receipts make that visible.

Useful receipts include:

  • handoff id
  • sending agent and receiving agent
  • task state at transfer
  • permission scope
  • attached artifacts
  • omitted context classes
  • verification gates
  • completion status
  • failure reason, if any

If you cannot inspect the handoff after the fact, you do not have orchestration. You have séance infrastructure.

Build the handoff like an interface

The shape is obvious:

planner → handoff contract → worker → verification → receipt → next handoff.

Each boundary should be typed, scoped, inspectable, and reversible where possible.

That is less exciting than “five agents debate each other until a miracle appears.”

Good.

Production systems should be boring at the seams.

The more agents you add, the more the seams matter. Without contracts, every handoff becomes a lossy translation of intent, authority, and evidence.

With contracts, agents can actually specialize without turning the workflow into telephone with shell access.

Do not pass a brain dump.

Pass a contract.