Multi-Agent Orchestration for Coding: How It Works and What Our Runs Showed

Multi-agent orchestration means one agent plans a task and hands the pieces to other agents, then checks and combines what they return. In a coding agent that usually looks like a planner model that never writes code itself and a set of worker models that build the parts, several at once.

Getting working software out of it is the hard part. We have run the pattern since September inside Atomic Agent’s Fusion mode, with local and cloud models in both seats, and this guide covers how the pieces fit together and what our measured runs showed.

What is multi-agent orchestration?

Multi-agent orchestration is the coordination layer of a multi-agent system: it decides how a task is split, which agent gets which piece, in what order the pieces run, and when a result is good enough to accept. The agents do the work; the orchestrator owns the outcome.

Anthropic’s Building effective agents calls the basic shape the orchestrator-workers workflow, in which “a central LLM dynamically breaks down tasks, delegates them to worker LLMs” and combines their results. It fits jobs where you cannot list the subtasks in advance, and the article uses coding as its example: how many files change, and how, depends on the task.

There are other shapes, such as fixed pipelines where each agent hands off to the next, or groups of agents that debate. Most coding agents that use several models, Fusion included, take the orchestrator-workers shape, because a codebase splits into files and modules that one planner can hand out.

What does the orchestrator do in a coding agent?

The orchestrator holds the conversation with you and turns your request into a plan. It reads the project, splits the job into parts, writes a brief for each part, sends the parts out, then reviews what comes back and sends weak parts out again with a sharper brief.

In Fusion, a single delegation can carry up to 16 tasks, each with a brief of up to 32,000 characters and up to 32 files. Every worker also receives up to 16,000 characters of your original request. That quote was added after short briefs went wrong in testing: with briefs of 124 to 901 characters, workers asked for a game built a marketing landing page instead.

The orchestrator does not write code. We learned that rule from two failed versions of it.

Why the orchestrator must not touch your files

An orchestrator that can edit files will end up doing the work itself. In our runs, every opening we left in the rule got used.

Fusion went through two softer versions before the current one. The first allowed edits once one delegation had succeeded. The delegation tool reports success even when every worker failed, so the model delegated, got a formal “ok”, then wrote 15 files and ran 5 commands on its own. The second version allowed edits when a task came back marked as needing the orchestrator. Four tasks out of six came back that way, and 13 writes went through the gap.

The rule in the code now is short: “The orchestrator does not mutate anything, in any circumstance, for the whole turn. Read, delegate, reply.” It can read, delegate, run checks and answer you. Any tool that would change something is refused when called while staying listed in the prompt, so the prompt prefix almost always stays the same and the provider’s prompt cache keeps working.

The rule has a cost. In one of our runs a local planner diagnosed a bug correctly, could not fix it, and spent 22 minutes writing the fix into its explanation of why it could not act.

How do parallel workers stay in sync?

Through a contract the orchestrator writes before any worker starts. Each task declares the files it owns, the names it provides and requires, and the checks that prove it works. Workers never see each other, so this shared list, plus waves that make dependent tasks wait, is what keeps their pieces compatible.

Each worker runs in a throwaway session: it gets one message with its brief and the quote of your request, has no memory of your conversation, cannot hand work further down, and cannot ask you anything. It sees the files in the working folder and writes inside the folders you approved once for the whole run, without further prompts. Workers do not see each other.

That isolation is what lets them run in parallel, and it is also the main source of broken builds. In one benchmark game, one worker wrote HD.Ship as a class while a sibling called it as a plain object, and one used a button id launch-btn while another looked for btn-launch. Every worker reported success. The game crashed on the first click.

Fusion checks the contract before a single worker launches: a required name that no task provides comes back to the orchestrator as a warning, so it can fix the plan while fixing is cheap. Tasks then run in waves: a task that needs another task’s output waits for it.

Matching names does not prove matching meaning. In a September run on v0.6.3, two workers agreed on a function that returned fields called w and o, and gave them opposite meanings. The contract passed, the console stayed clean, and three of five scenes drew their boxes in the wrong place. Contracts can now carry a one-line shape for each name, such as a signature or what a field means, and that line goes into the brief of every task that uses it. Only running the code proves it.

Input files get their own protection. A worker once replaced a 2,401-row sales.csv with a nine-row sample. A plain warning did not help: five times in a row models read it and overwrote the file anyway. Files declared as inputs can now be edited in place but not replaced, with no override.

How does the orchestrator know the work is done?

It has to run the result, because workers report “ok” whether or not the code works. In Fusion the orchestrator may call two read-only checks, verify.syntax and verify.run, which catch files that do not parse and pages or scripts that crash. They cannot tell whether the program does the right thing, so a reviewer that relies only on them, or on worker summaries, will still approve broken work.

Early Fusion reviewers were blind in exactly this way: worker replies are kept to about 4,000 characters, and the orchestrator was not allowed to run anything. The fix was the two checks. verify.syntax checks that the files parse. verify.run works in a throwaway copy of the folder and can run a command, start a service, or open a page in a headless browser and collect page errors and console errors. If the browser cannot start, the check fails.

Checks catch crashes; wrong physics passes them. In our September comparison all four runs reported zero errors, and only two of them passed four of five scenes. Hollow cubes, balls hanging in the air and a wall that never fell all ran without a single console error. If correctness can be expressed as a test, put the test in the contract; if it cannot, plan to look at the result yourself.

Which model should plan and which should build?

Let the faster side do the long writing. In our runs a local 27B model planned well, while cloud workers wrote the code quickly. With the same two models, swapping the seats moved the result from two scenes out of five to four, and the run time from 85 minutes to 14.

The task: build a five-scene 3D physics show in plain canvas code, one turn, no repairs, scored by recording each scene at 60 frames per second. The cloud model was Claude Opus 5 through OpenRouter. The local model was Qwen 3.8 27B on an RTX 3090 with 24 GB, at 31 to 34 tokens per second. Three rows ran on Atomic Agent v0.6.5 on September 25, 2026; the cloud-only row ran on September 22 on v0.6.3 on a MacBook Air, where the hardware barely matters because the model runs in the cloud. One run per mode:

A plan is short text, and a 27B local model can write a good one. The build was about 1,500 lines of physics code, which is a lot of output, and local workers at a few dozen tokens per second drown in it.

Orchestration raised the local model to the cloud model’s result on this task, at about $2.77 against $1.83. Nobody passed scene three, so the task was not tuned to anyone.

These are single runs on one task, and the code has changed since. Treat them as direction from single runs.

Does multi-agent orchestration save money?

It can, early in a task. Over a whole task, review and repair rounds decide the bill, and the savings can disappear. In our longest run, orchestration cost $2.10 in the first hour against $14.79 for a single cloud model, and ended at $27.26.

The first numbers looked great. In a test by our engineer on a browser game, with Gemini Flash planning and local workers building, the first turn cost $0.142 against $0.465 for the cloud model alone, 69% less. That turn produced a game that threw an error on launch. Two repair turns later the working result had cost $0.849, 1.83 times the cloud-only bill.

Our November run with Claude Fable 5.2 planning for three local Qwen workers showed the same shape on a bigger job. One hour in, Fusion had spent $2.10 and had three 3D worlds and part of a fourth written, while Fable alone had spent $14.79 and had a scene that did not start. We stopped Fable alone at 1 hour 3 minutes, at $14.79, and Fusion at 2 hours 37 minutes, at $27.26. The planner, which cannot edit a file, produced 357,000 output tokens, nearly three times the 123,000 its three workers wrote together. Most of the money went into the planner checking and re-reading the work, and $7.51 went on two replies cut off at the output limit. Neither run finished and the output limits differed, so this is not a clean comparison, but the cost curve is the point.

Three mechanisms explain most of it:

• The prompt cache goes stale. A cloud model working alone takes steps seconds apart and in our engineer’s test read 84% of its input from cache at a tenth of the price. A planner that waits up to an hour for local workers got 11% from cache on its first turn and 0% on repairs.
• Cloud workers bill for thinking. One worker request used 41,228 output tokens, 41,173 of them hidden reasoning, cost $0.18 and ended with a single file read. Cap worker reasoning and output.
• Parallel workers share one GPU. Two local workers on one card ran at 2.6 to 2.9 tokens per second each, against 6.4 for one worker alone. On one machine, extra workers split the same speed.

Anthropic reports the same pressure from the other side: in its research system, “multi-agent systems use about 15× more tokens than chats.” Orchestration buys quality and parallel work with tokens. Whether that trade is cheap depends on where the tokens run.

When is multi-agent orchestration worth it?

Use it when the job splits into parts with clear edges and you can check each part by running it. Skip it for tightly coupled changes, short tasks and anything where reviewing the work costs more than doing it.

Anthropic puts the limit plainly: “most coding tasks involve fewer truly parallelizable tasks than research.” Our runs agree. Good fits:

• Several pages, scenes, levels or endpoints that share a small, stable interface
• A strong cloud model that should plan and review while a local model does the bulk for free, when each part needs little code
• A local model that is weak alone but can plan well for faster cloud workers
• Tasks with checks you can name in advance: tests, a page that must load, a script that must exit cleanly

Poor fits: a refactor that touches every file at once, a bug fix in one function, and short tasks where a single model finishes before the orchestrator would finish its plan. On a small game, Opus alone cost $0.78 with 95.5% of input from cache and only 15,600 output tokens. There was nothing left for orchestration to save.

How to try multi-agent orchestration with Atomic Agent

Atomic Agent is an open-source, local-first agent for the desktop and the terminal. Fusion is one of its three run modes next to Local and Cloud, and each seat takes its own provider.

In the terminal:

/runmode fusion      turn it on
/runmode workers 3   pin the number of local workers
/runmode swap        flip which side plans
/runmode status      show the current setup

In the desktop app, pick Fusion in the composer, choose a provider for each role, and use the swap control to flip the direction. In the config file the same setup looks like this:

"llm": {
  "runMode": {
    "mode": "fusion",
    "fusion": { "orchestratorProvider": "openrouter", "workerProvider": "local-llama", "workers": 3 }
  }
}

Three settings are worth setting before a long run. turnBudgetUsd caps the money one turn may spend; once it is reached, the turn starts no new work, stops workers still running and reports back. It is checked between delegations, so expect some overshoot. workerReasoning and workerMaxOutputTokens keep cloud workers from billing for long hidden thinking. And the local side needs real hardware: a 27B-class model at 4-bit is practical from about 24 GB of GPU memory, while a 12 GB card ran the same model at 4 to 6 tokens per second in our tests.

On privacy, whichever seat runs in the cloud sees your request and the files it works with. If nothing should leave your machine, use Local mode. The Fusion docs list every setting and limit.

The bottom line

Multi-agent orchestration works when three things hold: the orchestrator cannot do the work itself, the workers agree on names before they start, and something runs the result before anyone calls it done. Get those right, and with a given pair of models, who plans and who builds matters most.

It costs tokens and GPU time. On one GPU, parallel workers share the same tokens per second, and long review rounds can cost more than a single strong model. Where it shines is raising a local model to cloud-level results, or keeping a strong planner in charge while cheap workers do the bulk. To try it, download Atomic Agent and switch to Fusion.

Runs: the four-mode comparison used Atomic Agent v0.6.5 on September 25, 2026; the Fable 5.2 run used v0.6.13 on November 9 and 10, 2026; the browser game test used v0.6.1, and the cloud-only row of the comparison used v0.6.3 on September 22. Each is a single run. Code details were checked against Atomic Agent v0.7.0 on November 13, 2026.