Agent A drafts a vendor contract summary. Agent B checks it against policy. Agent C files it into the contract system. In the demo, this runs in eleven seconds and looks like magic. In production, Agent B rejects the summary because it’s missing a termination clause, and nobody defined what happens next — so the pipeline either stalls silently, retries forever, or Agent C files the rejected version anyway because it was never told the handoff failed.
That’s the failure pattern. Not that the agents are individually bad at their jobs, but that the seams between them were never designed. Three agents chained together isn’t an orchestration — it’s three single-purpose scripts hoping the others behave.
The handoff is where the plan always breaks
Most teams build agent chains the way they’d build a happy-path demo: Agent A’s output becomes Agent B’s input, Agent B’s output becomes Agent C’s input, done. Nobody asks what Agent B does when the input from A is malformed, half-complete, or technically valid but wrong in a way A couldn’t detect.
So the failure shows up downstream and unattributed. A rejects nothing because A doesn’t know it was rejected. B times out waiting on a system that’s slow that day, and the orchestration layer either hangs or silently drops the task. C receives something that looks like valid input and acts on it, because C has no way to tell a successful handoff from a degraded one.
The worst version isn’t the crash — it’s the chain that keeps running after a bad handoff and produces a plausible, wrong result. A crash gets noticed. A contract filed with the wrong clause because C never knew B’s check had failed gets discovered three months later, if at all.
Orchestration means naming who owns the failure, not just the task
Connecting agents is the easy part — most frameworks do that in a few lines. The actual work of orchestration is deciding, before anything runs, what each agent is accountable for when the step before it doesn’t behave.
That means every handoff needs three things defined in advance: what a valid input from the previous step looks like, what happens when it isn’t valid, and who — which agent, which policy, or which human — owns the decision to retry, escalate, or abort. “Retry until it works” is not a failure policy. It’s a way to turn one bad output into three.
Concretely, this looks like a contract at each seam: Agent B doesn’t just receive A’s output, it validates it against an explicit schema and confidence threshold before acting. If validation fails, that’s not an exception to handle later — it’s a defined state with a defined next step, which might be “return to A with the specific gap,” might be “escalate to a human reviewer,” or might be “halt the chain and flag it.” The chain’s designer decides this up front, not the agents at runtime.
This is also where governance and audit stop being separate concerns from orchestration and start being the same problem. A policy gate that only fires on the happy path isn’t a gate. And if B rejects A’s output, that rejection — what was rejected, why, and what happened after — has to be a first-class recorded event, not something you reconstruct from application logs after someone asks. When we design multi-agent deployments, we build the rejection and timeout paths as real states in the system before we build the happy path, because that’s the part that actually determines whether the chain survives contact with real data. If you’re working through this for your own agent chain, a diagnostic call is a reasonable place to start mapping the seams.
This adds real overhead, and sometimes it isn’t worth it
Defining ownership and failure behavior at every handoff is slower to build than wiring three agents together and hoping. For a low-stakes, easily-reversible task — summarizing internal meeting notes, say — that overhead can cost more than the failure it prevents. Not every chain needs a formal escalation path.
The judgment call is matching the rigor of the handoff design to the cost of a silent failure. A three-agent chain that touches customer-facing contracts, financial postings, or access permissions needs explicit accountability at every seam. A three-agent chain that drafts internal Slack summaries probably doesn’t need the same machinery, and building it anyway is its own kind of waste.
It’s also possible to over-orchestrate: adding a coordination layer, a message queue, and a state machine to a process that two well-scoped agents could handle directly. More handoffs means more places for the coordination itself to fail. The goal isn’t maximum structure, it’s structure sized to what actually goes wrong when this specific chain breaks.
The question to sit with
Pick the last multi-step automation your team built with more than one AI agent in it. If the second agent had rejected the first agent’s output yesterday, would anyone know it happened — and would anyone have been designated to do something about it?