Agentic orchestration: what it actually means once you run more than one agent

What is agentic orchestration in plain terms?

It is the answer to four questions, asked continuously: which agent handles this work, when does it run, what does it get as input, and where does its output go. Everything people file under orchestration (routers, planners, queues, retries, budgets, traces) is machinery for those four. Strip the vocabulary away and you have a dispatcher.

The distinction that matters is against ordinary workflow automation. A Zapier or n8n workflow knows all its steps before it runs, so the tool only has to execute them in order. An agent decides at runtime. It reads the email, judges it a refund exception rather than a refund, and routes it down a path the flowchart never drew. That single property is what drags in the rest of the machinery: you cannot pre-plan retries for a step that did not exist when you deployed, and you cannot budget work nobody scheduled.

Orchestration is not a tool you buy. It is the set of decisions you are already making badly by hand.

When do you actually need agentic orchestration?

Honestly: not at one agent, and usually not at two. One agent needs a trigger, a retry, and somewhere to log failures. That is a cron job and a try/except, and calling it orchestration only makes it sound expensive. Two agents that never read or write the same data are two separate programs. Run them separately and enjoy it.

The trigger is coupling, not headcount. You need an orchestration layer the moment agents share state, hand work to each other, or can fire each other. That usually lands around the third agent, because the third one is the one that finally overlaps with the first two.

That is not a story about a simple case. It is five agents, run in production, daily, with zero orchestration software. What made it possible was the partition: no two of his agents write to the same thing, so there is nothing to coordinate. Partitioning your agents by domain is the cheapest orchestration decision available, and almost nobody makes it deliberately.

The cheapest orchestration layer is a clean split of responsibilities plus one human who knows what good work looks like.

What breaks when you run three or more agents?

Five things, in roughly this order, and none of them appear in a framework tutorial because tutorials run once on a clean database.

1. Two agents write to the same record. The enrichment agent and the follow-up agent both update the same CRM contact. Last write wins, and the loser's work is gone without an error anywhere.
2. An agent triggers an agent that triggers it back. Agent A writes a note; the note is a webhook; the webhook wakes agent B; B updates the record; the update wakes A. Nothing crashes. It just runs all night.
3. Fan-out nobody metered. One request becomes four sub-tasks becomes sixteen tool calls. The unit of spend stopped being "a message" and nobody changed how it's tracked.
4. No single place to see what ran. Three agents, three log surfaces, three tabs, and the interesting event is the handoff between them, which lives in none of the three.
5. Nobody can answer "which agent did this?" The bad record has no author. And because agents are non-deterministic between runs, you cannot re-run to find out.

Anthropic's engineering team described the same class of problem from the inside of their own multi-agent research system in June 2025: "minor changes cascade into large behavioral changes", agents are "stateful and errors compound", and their early agents made mistakes like spawning 50 subagents for simple queries and distracting each other with excessive updates. If that happens to the team that builds the model, it is not a skill issue on your side.

Every one of these five failures is silent. That is the actual problem. Agents fail by producing confident work nobody asked for.

How do agents hand work to each other?

Three mechanisms, and the choice matters more than the framework you wrap around it. Shared record with a status field: agent A writes a row and sets it to ready_for_review; agent B picks up rows in that state. Direct call: agent A invokes agent B and waits for the reply inside its own context. Event or message queue: agent A publishes a fact, and whichever agents care subscribe.

For internal business agents, the shared record wins nearly every time. The handoff is durable, so a crash mid-flight does not lose the work; it is inspectable, so you can see what state everything is in with one query; and it decouples the two agents, so B can be down for an hour without breaking A. Direct calls feel natural and cost the most, because the child's output gets copied into the parent's context, and you pay for it on every subsequent turn.

The fix for that is worth stealing: pass a reference, not the payload. Anthropic's multi-agent write-up describes subagents storing their work in external systems and passing lightweight references back to the coordinator, which stops large outputs from being copied through conversation history. In practice that means agent B writes the draft to a document and hands back an ID. It is the difference between a handoff that costs 200 tokens and one that costs 20,000.

One thing we learned the expensive way: a handoff is also a credential boundary. Going from one user to a team turned a shared agent instance into a shared-secrets problem in our deployments. Whoever used it inherited whatever access it held. The fix was isolation per user or department with scoped credentials, decided before the agents started passing work around rather than after.

If a handoff exists only inside a conversation, it does not exist. Write it down or lose it.

Who decides which agent runs — a router, a planner, or a plain queue?

Three designs, in ascending order of how much you are trusting a model. A queue means the work item already names its agent, decided by whatever created it. A router means one cheap classifier reads the input and picks from a fixed list. A planner means an LLM decides at runtime which agents to run and in what order.

Pick the queue if you can enumerate the categories of work. You can, more often than you think: invoices, refunds, inbound leads, contract reviews. Pick the router when the input is genuinely ambiguous at arrival, which is mostly email and chat, and keep the destination list short enough to read on one screen. Pick the planner when the task is open-ended research and the set of steps is not knowable in advance.

Planners are the fashionable choice and the one we deploy least. Anthropic's own assessment is blunt on the limit: "LLM agents are not yet great at coordinating and delegating to other agents in real time." A planner also destroys your cost model, because the thing choosing how much work to do is the thing you are paying by the token. If you do run one, bound it the way they did, with explicit rules for how many subagents and tool calls a given complexity of task is allowed.

Let a model choose the plan only when you genuinely cannot list the plans.

How do you stop two agents fighting over the same record?

The default rule: one writer per record type. Every other agent reads. If the follow-up agent needs the contact updated, it writes a request that the contact-owning agent picks up, rather than reaching into the record itself. This costs you a little indirection and removes the entire class of problem.

Where two writers are genuinely unavoidable, the fixes are the same ones every concurrent system has used for forty years. Claim the row before working on it with a status column plus claimed_by and claimed_at, so a second agent sees it is taken. Check a version number on update and fail loudly if it moved underneath you, instead of overwriting. And put an idempotency key on every external side effect, because the retry that saves you from a timeout is also the retry that sends the customer a second invoice.

This is the part people expect their agent framework to handle. It does not. LangGraph, CrewAI and AutoGen orchestrate calls between agents; none of them knows that your CRM contact is a contended resource. Concurrency control lives in your database and in the API contracts of the systems the agents touch, exactly where it lived before any of this was called agentic.

Give every record exactly one agent allowed to write to it. Everything else reads and asks.

How do you keep cost predictable when agents call agents?

Start from the published multiplier so you are not guessing. Anthropic reported in June 2025 that agents typically use about 4x more tokens than chat interactions, and multi-agent systems about 15x more than chats, and said plainly that multi-agent architectures only make economic sense where the task is valuable enough to pay for it. Treat 15x as the shape of your bill, not as an outlier.

The spend that actually kills projects is not the busy agent, though. It is the idle one.

Four controls hold the line, and all four are things you build once. Cap the fan-out: a hard limit on how wide and how deep sub-agent spawning can go, enforced in code rather than requested in a prompt. Put a token ceiling on each run and fail the run when it is hit, loudly. Meter per run, not per month, because a monthly invoice tells you that something went wrong three weeks ago. And audit the idle loops on a schedule: every heartbeat, poll and refresh should have a named reason for existing, or it gets deleted. Per-department budgets and idle-loop audits are a standing deliverable in our agentic OS builds, because agent bills fail quietly and the controls have to be installed rather than hoped for.

For a fuller cost model, covering build fees, running costs and where the money actually goes, our guide on AI agent token costs breaks the bill down line by line.

Budget the agents that are doing nothing. Those are the ones that end programmes.

How do you trace what an agent did after the fact?

You propagate one run ID through every hop and write a row per step. Minimum viable columns, and we do mean minimum: run_id, parent_run_id, agent, agent_version, trigger, input_ref, output_ref, tokens, cost, status, started_at, ended_at. That table answers "which agent did this, what did it read, what did it cost, and what woke it up" with one query. Most teams building agent fleets do not have it, which is why post-mortems turn into archaeology.

Why it cannot be skipped: you cannot reproduce the failure. Agents make different decisions on identical input, so re-running the job tells you what it does now, not what it did on Tuesday. Anthropic hit precisely this. Users reported agents "not finding obvious information" and the team could not see why until they added full production tracing, which is what let them diagnose failures systematically rather than guess between bad queries, bad sources and tool errors.

If you want the trace to outlive your tooling choices, use the OpenTelemetry GenAI conventions rather than a vendor's schema. The OpenTelemetry project's March 2025 post on AI agent observability makes the reason explicit: because observability and evaluation tools come from many vendors, standardising the shape of agent telemetry is what avoids lock-in to a vendor- or framework-specific format. There is a privacy dividend too. Anthropic monitor agent decision patterns and interaction structures without recording the contents of individual conversations, which is the pattern to copy if your agents touch client data.

If you cannot answer "which agent did this and what did it read" in one query, you do not have orchestration. You have agents.

Do you need a framework — or a queue and a cron?

For a 20–50-person company running a handful of internal agents, a queue and a cron is usually the right answer, and we say that knowing it sells nothing. This is also not a contrarian position. Anthropic, writing in December 2024 after working with dozens of teams building agents, found that the most successful implementations used simple, composable patterns rather than complex frameworks, and warned that framework abstraction "can obscure the underlying prompts and responses, making them harder to debug". Their advice was to start with the LLM APIs directly and to understand the code underneath if you do adopt a framework.

The honest read of that table: the plain queue wins on setup time, on maintenance, on cost behaviour, and on being understandable by someone who did not build it. It loses on exactly one thing, open-ended work whose steps you cannot enumerate, and that is a smaller share of internal business work than the framework docs imply. Temporal earns its place when a job must survive a restart and money is on the line. A framework earns its place when the agent graph is the product you sell.

One caveat we will not skip: a queue you wrote yourself is a queue you maintain yourself, and the day you need distributed timers, backpressure and exactly-once semantics, you will have rebuilt a worse Temporal. Watch for that day. Most teams never reach it.

Choose the smallest orchestration that fails in ways you can see.

How does agentic orchestration relate to an agentic OS?

Orchestration is the machinery. An agentic OS is the operating model that decides what the machinery should do: which agents exist, which department owns each one, which human approves the irreversible actions, and what shared knowledge every agent answers from. Routing and locking are engineering problems. Ownership and approval are management problems, and they are the ones that decide whether the fleet is still running in six months.

The sequence is visible in our rollouts. The founder and exec team go first; the first department is onboarded 2–4 weeks later; roughly 30% of staff are active users at three months. The engagement runs a couple of months of back-and-forth: skills per department, choosing or building the connectors, training, and restructuring the agent hierarchy as real usage reveals what matters. That restructuring is the tell: the orchestration graph you need at month three is not the one you designed at week one, which is another argument for a layer that is cheap to change.

If you are earlier than that, at one agent or none, the sequencing question is answered in our guide on how to implement AI agents, and the knowledge layer that agents read from is covered in the knowledge readiness audit.

Orchestration decides which agent runs. An agentic OS decides who is accountable when it runs badly.

Who should not build an orchestration layer yet?

Four groups, and we tell them so on the call rather than after the invoice. If you run one or two agents that do not touch the same data, you are being sold a solution to a problem you have not got. Separate them cleanly and revisit at the third. If nobody on your team can read the code or the config, building custom orchestration hands you a system you cannot debug at 6pm on a Friday; take the managed platform and accept its limits. If your agents are still failing on their own tasks, orchestration will coordinate the failures faster, nothing more. And if the reason you want it is that a vendor demo showed agents talking to each other, that is a demo, not a requirement.

Where we lose honestly: a competent engineer who already runs your background jobs can build the queue, the claim logic and the trace table in a week or two, and they will maintain it better than we would because they already carry the pager. We are worth hiring when the orchestration question is tangled up with the operating-model question (which agents should exist, who owns them, what they are allowed to touch), which is what our agentic OS engagements cover, and when nobody internally has a spare month.

Orchestration is not what makes agents work. It is what stops working agents from damaging each other.

Frequently asked questions

Sources

• Anthropic, How we built our multi-agent research system (13 June 2025) — the 4x and 15x token multipliers, error compounding, subagent spawning failures, and the production-tracing point.
• Anthropic, Building effective agents (19 December 2024) — simple composable patterns beating frameworks across dozens of teams, and the debugging cost of abstraction.
• OpenTelemetry, AI Agent Observability — Evolving Standards and Best Practices (6 March 2025) — why agent telemetry should follow a shared convention rather than a vendor format.

Related reading

• How to implement AI agents — the step before this one: first agent, sequencing, and getting staff to use it.
• AI agent token costs — where the monthly bill actually comes from, with the idle-loop breakdown.
• Agentic OS — the operating model around the machinery: org chart, approvals, budgets.
• All Cognio guides — the rest of the library.