Agentic orchestration: how AI agents work together

Agentic orchestration is how several AI agents work together on one goal: which agent takes which part, in what order, how work passes between them and what happens when a step fails. It's the how. Deciding what the agents should work on, and why, is the other half of the job: AI agent management.

When to use it: when one goal splits into parts that can run separately, or that need different tools or permissions. When not: when one agent with a clear spec can do the job. Most coding work starts there.

What is agentic orchestration?

Orchestration is the coordination between agents. Picture a dance company. Management picks the piece and says why it's worth dancing. Orchestration is the choreography: who dances which part, who enters first, how one dancer hands off to the next and what happens when someone misses a step.

For AI agents, that means four things:

• Who takes which part. Which agent gets each task, based on what it's good at, what tools it has or what it's allowed to touch.
• In what order. Which steps run one after another, which run side by side, and which wait for something else to finish.
• How work passes between them. What each agent hands to the next: a result, a summary, a file, a note.
• What happens when a step fails. Retry, hand to another agent, or stop and ask a person.

You'll see three names for nearly the same idea. Agentic orchestration stresses that the agents themselves make some of the calls along the way. Multi-agent orchestration stresses that there's more than one agent. AI orchestration is the widest: it can include plain model calls, tools and data steps with no agent in them at all. The glossary entry has the short definition.

Orchestration is the choreography: who dances which part, who enters first, how one dancer hands off to the next and what happens when someone misses a step.

How is orchestration different from agent management?

Management is the what and why. Orchestration is the how.

A well-orchestrated team of agents can still build the wrong thing very efficiently. And a clear plan still stalls if nobody sorts out who does which part. That's why most teams running several agents end up needing both.

One more thing to know when you read about this online. Some tools use "agent management" to mean permissions, versions and monitoring: governing agents as infrastructure. On this site it means direction, the what and why. AI agent management covers that side in full.

What is multi-agent orchestration?

Multi-agent orchestration is orchestration with more than one agent doing the work. One agent with tools can handle a lot. Several agents come in when one goal splits into parts that need different skills, different tools or different permissions, or that can run at the same time.

Microsoft's architecture guide puts the bar plainly: "Use the lowest level of complexity that reliably meets your requirements." It lists three levels, from a single model call, to one agent with tools, to multi-agent orchestration, and calls one agent with tools "often the right default". Several agents add coordination, delay and new ways to fail. They earn their place when one agent can't reliably hold the whole job.

For a product builder, the usual reasons to go multi-agent are:

• The work splits cleanly. A frontend change, a backend change and the tests, each in different files.
• You want a second opinion. One agent builds, another reviews against the spec without seeing the first one's reasoning.
• You want speed on research. Several agents read different parts of a problem at once, then compare notes.

What is the purpose of an orchestrator agent?

An orchestrator agent is a lead agent that runs the others. It reads the goal, splits it into tasks, hands each task to a worker agent, then combines what comes back and decides what happens next.

Fig 4.1 · Lead and workers

Anthropic's research feature works this way. Their write-up says the system "uses a multi-agent architecture with an orchestrator-worker pattern": a lead agent plans the research and hands parts of it to subagents that search in parallel. Claude Code's agent teams follow the same shape. One session acts as the team lead, "coordinating work, assigning tasks, and synthesizing results", and the teammates each work in their own context window.

The orchestrator is good at three jobs:

1. Splitting. Turning one goal into tasks small enough for one agent each.
2. Assigning. Giving each task to the agent that fits it, and keeping two agents off the same task.
3. Combining. Pulling the results back together and checking whether the goal is met.

What it can't do is pick the goal. An orchestrator agent knows the task it was handed. It doesn't know which customer is about to leave, what you decided last month or which idea you already tried. That comes from management, and from you.

What are the common orchestration patterns?

Two widely cited sources name the patterns: Anthropic's "Building effective agents" and Microsoft's "AI agent orchestration patterns" guide. They use different names for overlapping ideas.

Microsoft describes its handoff pattern as agents that "decide whether to handle it directly or transfer it to a more appropriate agent", and its magentic pattern as built for "open-ended and complex problems that don't have a predetermined plan of approach". The names differ. The choice underneath is the same: who decides the next step, the code or an agent?

For most coding work, the first and last patterns do the most good. A spec written in one session and built in another avoids a chat full of failed attempts. A fresh reviewer catches what the builder talked itself into.

What is an orchestration layer?

The orchestration layer is the part of a system that holds the coordination: the task list, who holds each task, the order, the handoffs and the retries. It sits above the individual agents and below the person directing them.

In an application you're building, the layer is code: a framework, a workflow engine or an orchestrator agent you wrote. When you direct coding agents on your own product, the layer is often split between tools:

• Inside one tool. Claude Code's subagents and agent teams keep their own task list and messages inside one session.
• Across tools. Claude Code, Cursor, Codex and Grok don't share a runtime. What they can share is a list they all read, a claim on each job and notes they leave for each other.

How do you orchestrate coding agents?

There are four common setups, from lightest to heaviest.

1. One session. One agent, one spec, one branch. No orchestration at all. Most jobs should start here.

2. Subagents inside a session. Claude Code's docs describe subagents as "specialized AI assistants that handle specific types of tasks". Each "runs in its own context window with a custom system prompt, specific tool access, and independent permissions", and reports its result back to the main session. Good for focused side jobs: research a library, run the tests, review the diff.

3. Agent teams. In Claude Code's agent teams, which are experimental and off by default, "teammates share a task list, claim work, and communicate directly with each other". The lead creates tasks, and teammates claim them, with file locking so two can't claim the same one. The docs suggest starting with 3 to 5 teammates and warn that two teammates editing the same file leads to overwrites, so split the work by files.

4. Several sessions, several tools. You run Claude Code in one terminal, Codex in another and Cursor in your editor, each on its own branch and its own working copy (a git worktree). Nothing inside any one tool coordinates them. The coordination has to live somewhere they all read: one ranked list, a claim on each job before any code, a handoff note when a job changes hands and evidence against each Done When line. The guide to managing multiple AI agents walks through each piece.

Anthropic notes a limit that matters here: "most coding tasks involve fewer truly parallelizable tasks than research." Code shares files, tables and API shapes. Before you split a job across agents, check that the parts touch different files, or run them one after another.

How do you orchestrate AI agents, step by step?

1. Start with one agent. Get one agent doing the job well, with a spec and a check it can run. If it can, stop here.
2. Split by files, not by role. Give each agent a part that touches different files. "Frontend, backend, tests" works. "Planner, coder, critic" on the same files collides.
3. Write each part down. One short spec per part: the problem, what to build, the files to touch and the Done When lines.
4. One holder per part. Each agent claims its part before writing code. An agent that finds a part taken moves to the next.
5. Decide the order. Parts that change a shared piece, like a table, an API shape or the config, run one after another. The rest can run side by side.
6. Hand over with a note. When an agent stops partway, it leaves five lines: what it did, what failed, what it ruled out and the exact next step. See Claude Code handoff.
7. Check against the spec. Each part is done when its Done When lines have a receipt, not when the agent says so.
8. Keep a person on the real calls. Scope changes, customer data, money and choices between real options come to you. The human in the loop guide has rules to paste.

What frameworks are best for orchestrating multiple AI agents?

The best one is the lightest one that does the job. Rather than rank tools, here are the kinds and when each fits.

Pick by the question you actually have. If the agents can't pass results to each other inside one application, you need a framework. If they keep building the same thing, or the wrong thing, no framework fixes that. That's a management problem.

What does orchestration cost?

More than one agent, in tokens, time and review.

• Tokens. Anthropic found its multi-agent research system used "about 15× more tokens than chats". Claude Code's docs say agent teams "use significantly more tokens than a single session", and that token use scales with the number of active teammates.
• Coordination. Every handoff is a place where context drops. Every parallel branch is a merge to make.
• Your review. Three agents produce three times the output to check. The real limit on how many agents you can run is how much you can review with care.

The trade is worth it when parts run independently and the time saved is real. For routine jobs, one agent is cheaper and usually just as fast.

What mistakes do people make with orchestration?

• Orchestrating before one agent works. If one agent can't do the job with a good spec, three won't either.
• Splitting by role on shared files. A planner, a coder and a reviewer all editing the same module will overwrite each other.
• Expecting the orchestrator to pick the work. It sequences what it's given. It doesn't know your customers.
• Passing whole transcripts between agents. The next agent needs five lines, not five hundred.
• No owner for each task. Two agents start the same job and you pay for both.
• Trusting "done" from the lead. A lead agent can decide the team is finished before every task is. Check each Done When line yourself, or have a fresh agent check it.
• Running agents unattended for hours. Long runs without check-ins drift. Look in, steer and pull the plug on approaches that aren't working.

Where does Annsa fit?

Annsa gives the direction and coordinates the work. Your coding agents run it.

• The what and why. Priorities are ranked inside your bets: what a person marked broken first, then what customers asked for, then ideas. Each keeps its evidence: the customer's words, the account and its revenue.
• A spec for each job. The spec has the problem, the evidence, what to build, the files to touch and the Done When lines. You, your agent over MCP or Ask writes it.
• Who holds what. Claude Code, Cursor, Codex and Grok connect over MCP. An agent claims a priority before it starts, so no two take the same one, and leaves a handoff note when it stops.
• Proof it's done. Each agent records evidence against each Done When line before the job ships.
• Only the real calls reach you. Needs You holds the questions a person has to answer. Decide once, and every agent reads it.

Annsa doesn't start, run or route your agents. Their own tools do the running: one session, subagents, agent teams or any orchestrator. Annsa is the list they all read. See AI agent management for the whole picture.

Sources

• Anthropic, Building effective agents, 19 December 2024 (the workflow patterns and starting simple).
• Anthropic, How we built our multi-agent research system, 13 June 2025 (orchestrator-worker pattern, token use, parallel coding tasks).
• Microsoft Azure Architecture Center, AI agent orchestration patterns (levels of complexity; sequential, concurrent, group chat, handoff and magentic patterns).
• Anthropic, Create custom subagents (Claude Code subagents).
• Anthropic, Orchestrate teams of Claude Code sessions (agent teams: lead, shared task list, claiming, team size, token use).