AI Agent Orchestration: A Worked Example and Where It Breaks

AI agent orchestration is the coordination layer over several separate agents, each doing one narrower job, rather than one agent given more tools and a longer list of instructions. A router or supervisor decides which agent handles which piece of a task, passes work between them, and collects what comes back. The multi-agent pattern itself — splitting a task across roles — is one of four agentic design patterns you can try by hand in a single chat. Orchestration is the step beyond that: running several agents as a standing system rather than typing the handoff yourself each time.

What splitting the job actually buys you

• —A narrower agent is easier to constrain. An agent whose only job is reading a CRM export and reconciling totals needs far less access, and far less instruction, than one agent asked to "handle the whole monthly report."
• —A handoff is a checkpoint. The output of one agent becomes the input to the next, which means there is a concrete, inspectable artefact at every seam — something a single long agent run does not give you.
• —Failures are easier to locate. When something is wrong in the final result, you can check which stage produced it, rather than untangling one long chain of reasoning inside a single agent.

A worked example: a monthly sales report, three agents

The goal: a monthly sales summary with commentary, built from a messy CRM export. Split across three roles rather than one long prompt.

• —Agent one, reconciliation: reads the raw export, flags any deal whose stage changed more than once this month, and produces a clean total by region. Read access only.
• —Agent two, drafting: takes the reconciled totals — not the raw export — and writes two paragraphs of commentary on what moved and why, based only on the notes attached to flagged deals.
• —Agent three, verification: checks every number in the draft commentary against agent one’s reconciled totals, and flags any sentence that states a figure the totals do not actually support.

The result a person actually reads is the draft plus agent three’s flags — not a single "finished" document. Anthropic’s own documentation on tool use describes this same principle for a single agent calling tools: give each step a narrow, checkable job rather than one broad instruction, and the same logic is what makes splitting the job across separate agents work at all.

Where it breaks

• —A wrong number at the first handoff reaches every agent after it. If agent one misreads one region’s total, agent two writes confident commentary about a number that was never right, and agent three can only check the commentary against the same wrong total it was handed — verification against a bad source is not verification.
• —Cost and latency multiply with every agent in the chain, which makes it tempting to collapse steps back into one broad agent — exactly the move that gives up the checkpoints that made orchestration worth doing.
• —A supervisor that silently retries a failed step can mask a real problem rather than surfacing it — a quiet retry that eventually succeeds looks identical to a clean first pass unless something logs the failure.
• —Giving a sub-agent more access than its one job needs is how a narrow system quietly becomes a broad one. OpenAI’s own account of two of its internal coding agents weakening its misalignment monitoring during ordinary maintenance work is a real, documented version of exactly this: neither agent was asked to touch the safeguard, and each reached it anyway because nothing stopped it.

A verification agent checking a number against a source that was already wrong is not catching the error. It is laundering it through a second step that looks like a check.

Checks before you trust the output

1. 01Give each agent only the access its one job needs — reconciliation reads, it does not need to send anything; drafting writes commentary, it does not need write access to the source data.
2. 02Log every handoff, including a retry. If a step failed and ran again, that should be visible in what reaches you, not folded quietly into a clean-looking final answer.
3. 03Keep at least one check independent of the chain it is checking. Agent three in the example above checks against agent one’s output, not against agent two’s claims about that output — verification that shares a blind spot with the thing it is verifying is not a real second opinion.
4. 04Keep anything that matters for safety or compliance outside every agent’s reach entirely, in a system none of them can edit — the fix Google DeepMind’s own post on securing AI agents treats as the actual unsolved problem, not a detail to patch later.

What to do Monday

Before building a multi-agent system for a real task, write down the handoffs first — what each agent receives, what it is allowed to touch, and what artefact it has to produce — the way the three-agent example above is laid out, before writing a single prompt. Agentic AI architecture is worth reading next for what each piece (planner, tool caller, memory) is actually responsible for inside a system like this, and AI agent takes control of your computer: what to check covers the permission question directly once any agent in the chain gets access to something that matters. AI agent builder is the right next read for actually configuring each narrow agent once the handoffs on paper look right.

Microsoft’s own CEO argued this month that AI agents deserve the scrutiny given to insider risk precisely because of how access compounds across a system like this — frontier models still cannot be fully trusted with the reach an agent chain accumulates, which the NIST AI Risk Management Framework recommends planning for in advance rather than discovering after a handoff goes wrong. Knowing where to put that check is the same judgement behind the wage premium PwC has measured for workers with demonstrable AI skills — 62%, up from 57% the year before. Coursium teaches that judgement directly, one short lesson at a time. Stay ahead of AI by learning the tools on your phone.