AI Agent Orchestration: When an Agent Manages the Fleet
The short version
An orchestrator is the agent that reads your other agents' work so a person doesn't have to. You need one at the point where your fleet files more runs in a day than anyone will genuinely read. Below that line it's overhead. Above it, the orchestrator is what keeps the fleet trustworthy, and the job it hands back to you is checking the thing that checks the work.
We run a fleet of agents at LimeLight. One maintains our website. Others handle client SEO work, product feed enrichment, research, and reporting. They wake on a schedule, produce real deliverables, and file them for a person to review.
For a while I read every run. That held while the fleet was small. As it grew, the daily pile of "here's what I did" turned from a morning habit into a second job, and a day skipped stayed skipped. Agents nobody reads drift, and the drift tends to surface weeks later in something a client can see.
So we built an agent that reads them. That's what an orchestrator is, and this piece covers what it does, what it costs, and when a team needs one. It's the sixth rung of the Claude adoption ladder, and the rung I get asked about most by teams who haven't built the five underneath it.
What an orchestrator actually is
The pattern has a name in the engineering literature. Anthropic calls it orchestrator-worker and describes it as an architecture where "a lead agent coordinates the process while delegating to specialized subagents that operate in parallel." Most of the writing about it concerns a single complex task, split across subagents for a few minutes and then torn down.
Ours is that shape stretched across weeks. The workers are standing agents with their own clients, their own memory, and their own schedules, and the orchestrator sits above them permanently. Ours is called Nora. It does four jobs.
- It grades. Every run gets scored against a rubric, so output quality becomes a number that moves over time.
- It carries learnings sideways. When one agent works out something the others could use, the orchestrator is what moves it across, through a review gate.
- It triages. Out of a hundred runs, it surfaces the four a person needs to look at today.
- It reallocates. It notices an agent that has spent three weeks on work that isn't moving, and says so.
All four are management. The orchestrator ships nothing a client ever sees, so a team that evaluates it on output will read it as pure cost.
When you need one, and when you don't
Anthropic's own guidance here runs more conservative than most vendor material on the subject, and it's worth taking seriously. Their January 2026 write-up on multi-agent systems opens by telling you to start with a single agent: "A well-designed single agent with appropriate tools can accomplish far more than many developers expect." The common failure they name is teams building an elaborate architecture, then discovering that better prompting on one agent got them the same result.
That matches what I've seen: the orchestrator layer is the last thing you build. Two numbers tell you whether you're there yet. How many runs do your agents file in a day, and how many of those did a person actually read last week? Teams overestimate the second one, because the figure that counts is what gets read on a Tuesday when three clients need something at once. Reviewing a run properly costs real minutes, and a handful of agents on hourly schedules will outrun any single reviewer.
Two or three agents don't need this. That team needs better single agents, and the orchestration question can wait until review is the bottleneck.
What it costs
The cost is easy to miss, because it lands across the whole system and the orchestrator's own bill is the small part of it.
Anthropic's published numbers are the clearest public read available: agents use roughly four times the tokens of a chat interaction, and multi-agent systems about fifteen times. Their more recent guidance puts multi-agent implementations at three to ten times a single agent for equivalent work. Anywhere in that range, you're paying several times over for the same deliverable.
You get something real for it. On their internal research evaluation, a multi-agent setup with Opus as the lead and Sonnet subagents beat single-agent Opus by 90.2%. On one benchmark, token usage alone explained 80% of the performance variance, so a good share of the gain is bought rather than engineered.
For marketing work I use a simpler test than a token budget. Would a person have read this output anyway? If yes, the orchestrator is replacing labor already on the payroll, and the token cost is competing against an hourly rate it will almost always win against. If no, you've automated something nobody was checking, and what you bought is a more expensive way to produce work of unknown quality.
The distinction that makes it work: memory versus learning
This is the piece I'd hand to anyone building one of these, because we got it the wrong way round first.
An agent accumulates two kinds of knowledge, and they need separate homes. There's what it should remember about this client: a route on their site that 404s by design, the one person whose approval actually counts, a connector whose property list vanishes for a day and then comes back. Then there's what it worked out that would help any agent on a site it has never seen: a technique, a trap, a check worth running before a certain kind of change.
Put both in one store and the fleet degrades in two directions at once. Client detail leaks sideways into work it doesn't belong to, and general technique gets buried under specifics nobody else can use. We keep them structurally separate now. Client memory stays with the agent that earned it, and general lessons go to a shared corpus every agent can draw on.
The shared corpus needs a gate, which is the part that surprised me. An orchestrator that propagates learnings automatically will eventually push one confident, wrong lesson to every agent at once, and a fleet-wide regression costs far more to unpick than a single bad run. Ours grades each submitted learning as it arrives and holds the weak ones for a human. Most runs file none at all, and a corpus full of near-misses would be worse than a thin one.
Where it breaks
We hit three failure modes, in this order.
The orchestrator agrees with everything. The first version graded generously, because a model asked whether some work is good tends to say yes. Anthropic names this one directly: verification agents that mark outputs as passing without real testing. The fix is to make the grader argue the opposing case, and to check its scores against your own read on a schedule. That checking is the reviewing-the-reviewer job.
Coordination eats the benefit. Anthropic's guidance flags subagents that spend more tokens coordinating than executing, and warns against splitting work by problem stage, planning then building then testing, when the useful split is by what context can genuinely be isolated. When two agents need the same context to do their jobs, the split is usually wrong and they belong together.
Nobody reviews the reviewer. This architecture works well enough for long enough that you stop looking at it. The orchestrator is software with a point of view, and points of view drift. We keep a person on it deliberately, and I'd read any pitch that removes the human from this layer as a pitch from someone who hasn't run one in production.
One design decision worth stealing
Each of our agents wakes on a schedule, gets handed a fresh contract describing who it is, what's due, what it's allowed to touch, and what it learned last time, does the work, files a report, and exits with nothing kept inside the process.
A persistent agent sitting there thinking sounds more sophisticated, and in practice the disposable version is what makes a fleet manageable. State lives outside the process, so a crash costs you one run and never an agent's accumulated understanding. Permissions get re-evaluated every tick, so revoking an agent's ability to publish takes effect on the next run instead of waiting for someone to catch it mid-task. And because every run produces a report against the same schema, the orchestrator has something uniform to read.
Most of what makes a fleet governable turns out to be plumbing of that kind, decided early and boring to describe.
Where to start
If you're weighing this for your own team, count your agents, then count how many of their runs a person read last week. Numbers that sit close together mean you don't have an orchestration problem yet, and the work in front of you is on the rungs below. A gap that's wide and widening is what this layer closes, and a first version can be narrow: grade the runs and surface the exceptions, then leave learning propagation and priority reallocation for later.
The thing I'd avoid is treating this as a product decision. The orchestrator encodes what your team considers good work, which means somebody has to write that down before software can check for it. That rubric is the real deliverable, and no platform hands it to you.
We build and run this stack with brand marketing teams, and we're happy to give you a straight read on where your operation sits today. Start a conversation.
