Multi-agent systems fail in the seams. One agent finishes a partial job, another assumes a different state, and the workflow stalls or doubles work. This guide focuses on state, ownership, and failure-path patterns that keep handoffs legible. No invented case studies. Patterns are illustrative and meant for operators designing real workflows.
Name the units of work before you name the agents
Write the workflow as a sequence of outcomes, not personas. Classify ticket, draft reply, and schedule follow-up are outcomes. Classifier agent and writer agent are implementation labels. If you start with personas, you will invent handoffs that serve the org chart of agents rather than the work.
For each outcome, define the minimum state required to start and the state produced on success. State should be data a later agent or human can read without replaying a chat. Prefer structured fields over prose memories when the next step depends on a decision. Write those fields in a shared schema document before any prompt tuning begins.
Teams that skip this step often discover mid-pilot that Agent B expected a priority enum while Agent A wrote free text. Fixing that late costs more than writing the schema on day one. Keep the schema versioned beside the workflow map so product and engineering argue about fields, not vibes.
Ownership patterns
Every active workflow instance needs one owner at a time. Ownership means who may mutate the shared state and who is responsible for progress. When Agent A hands to Agent B, ownership transfers with an explicit event: timestamp, prior owner, next owner, and a version of the state blob.
Pass ownership only at decision boundaries. If Agent B only needs a read-only view to draft text, do not give it write ownership of the ticket fields Agent A already finalized. Split read collaborators from write owners. Humans can be owners too. A common healthy pattern is agent draft, human ownership for send.
Fail closed when ownership is unclear. If two agents can write the same field, you will eventually debug a race that looks like model weirdness and is actually a missing lock. Put the lock in the ledger, not in a polite prompt sentence.
State patterns that survive handoffs
Keep a single source of workflow truth outside the model context when possible. Model context is a cache, not a ledger. Store decisions, tool results, and approvals in a system you already trust: a ticket, a database row, or an object store document with versions.
Version the state. When Agent B starts, it should declare which state version it read. If a human changed the ticket meanwhile, Agent B should refresh or stop. Silent work on stale state is a common multi-agent failure and it is expensive to unwind.
Separate scratchpad from committed state. Agents may brainstorm in private context. Only committed fields move across the handoff. That separation makes audits possible and reduces prompt injection surface from prior chatter that never should have become policy.
Failure-path patterns
Design the unhappy path with the same care as the happy path. For each handoff, define timeout, retry budget, escalation owner, and compensation. Compensation means how to undo or mark partial work. If Agent B fails after Agent A created a draft, decide whether the draft stays, gets labeled failed, or gets deleted.
Use explicit failure tokens in state such as needs_human, tool_timeout, and invalid_state. Do not rely on the next agent to infer failure from missing fields. Missing fields happen for many reasons and inference creates silent wrong turns.
Escalation should name a human role and a queue. Multi-agent systems that cannot escalate become silent backlog machines. Measure stuck time the same way you measure completion rate.
Contract-style handoffs
Think of each handoff as a tiny contract: inputs required, outputs promised, errors enumerated, timeout, and idle policy. Write the contract in a short schema. Validate on both sides. If Agent A cannot satisfy the contract, it must not hand off. If Agent B receives an invalid payload, it must reject rather than improvise.
Contracts also help when you swap models or vendors. The agents change. The contract stays. That is how multi-agent systems avoid becoming a tangled pile of prompts that nobody wants to edit.
Illustrative workflow map
Take a research brief workflow. Agent A collects sources and writes a structured list with URLs and quotes. Ownership transfers to Agent B only when the list meets a minimum count and each item has a URL. Agent B drafts the brief and may not add sources without returning ownership to Agent A. A human owns publish.
If Agent B times out, the draft is marked failed and ownership returns to the human queue. If a source URL is missing during Agent B run, Agent B records the error and requests Agent A compensation rather than inventing a replacement citation. That map is illustrative. Your fields will differ. The point is visible ownership and rejection rules.
Testing handoffs
Unit-test contracts with fixtures. Integration-test timeouts by killing a tool mid-run. Chaos-test stale state by editing the ledger between agents. Log every ownership transfer in a format on-call staff can search. If you cannot explain a handoff from logs alone, the design is not ready for production traffic.
Include multi-agent eval cases in the same checklist spirit as single-agent eval: success criteria, permission boundaries, and cost per successful completion. Handoffs add a fourth lens: transfer correctness. Track how often ownership returns to humans for reasons the contract did not list, then tighten the contract.
Anti-patterns to cut early
Avoid circular handoffs without a hop limit. Avoid shared mutable chat transcripts as the only state. Avoid manager agents that re-prompt forever without changing ownership. Avoid hidden tools that let a non-owner mutate fields. Avoid celebrating autonomy metrics that ignore stuck workflows.
Also avoid cloning the same agent five times and calling it orchestration. If roles do not differ in tools or contracts, you added latency without clarity. Cut the clones and keep one clear owner path.
Practical next step
Map one workflow handoffs on a whiteboard. For each arrow, write owner, state version, timeout, and escalation. Then implement the ledger before you tune prompts. If you are naming a product around multi-agent work, keep capability claims tied to these mechanics. Category words are not a substitute for contracts.
For background on distributed work coordination ideas that predate agents, classic systems literature on state machines and idempotency still applies. Resources such as the IETF blog and API design notes across the industry can inform timeout and retry thinking. Apply them to agent contracts with the same seriousness you would apply to payment APIs.
When the map is clear, run a dry multi-agent pilot with humans as optional owners at every hop. Remove human hops only when logs show boring reliability. Boring is the goal. Operators who keep a written handoff map find on-call quieter because ownership disputes shrink. Teams that skip the map tend to debate prompts while state races continue underneath.
Put the ledger first, then the prose instructions, then the model choice. That order keeps multi-agent work inspectable when something breaks late at night. Revisit the map after each pilot week and delete hops that never changed outcomes. A shorter honest map beats a decorative diagram that nobody trusts.