Multi-Agent Architecture Cost Is Mostly Coordination

When a multi-agent system underperforms, the reflex across the industry is to upgrade the model. That is the most visible lever and close to the weakest one. Multi-agent architecture cost is set by two things a model swap does not touch: where your token volume sits, and how much engineering it takes to stop two agents from answering the same design question in two incompatible ways. A planner that reasons well and writes nothing will save you more than one clever agent doing all of it.

What actually drives multi-agent architecture cost

Execution is where the tokens go. In Cursor’s published swarm benchmark, worker agents accounted for at least 69 percent of tokens in every configuration and usually over 90 percent. Reading files, calling tools, parsing responses, retrying the call that timed out, writing the output — that is volume work, and volume work is most of what an agent does once it touches real systems. Deciding what to do next is a thin slice of the traffic, and it is the only slice that needs a capable model.

Run one model across both and you are buying premium reasoning tokens to do clerical work. Cursor’s numbers put a size on that mistake: a frontier planner supervising cheap workers finished the SQLite task for $1,339, while a single frontier model doing everything spent $10,565. Topology moved the bill further than any model choice inside either arm of it.

The dashboard is what hides this. Most agent telemetry reports spend per run. Nobody is watching spend per role. So before you compare model names, take one real trace and tag every call as deciding or doing, then look at which side of the split your money sits on.

Why planners and workers should be different models

The split is strict or it is decorative. A planner takes the goal and cuts it into tasks a worker can finish in one pass, and it never produces the deliverable itself. A worker takes one task, executes it, returns the result, and reports back when the task turns out harder than described. It does not re-plan.

Price is the obvious reason to separate them. Context is the better one. A single agent has to carry the end goal and the current sub-task in the same window, and as a run gets long the goal is what gets squeezed out. What you see then is an agent optimizing hard for a sub-task that no longer serves the objective. It reads as incoherence. The model is doing exactly what its remaining context tells it to.

Diagnosis matters more once it is running in production. When a run produces the wrong answer you need to know whether the plan was wrong or the execution was. In a single-agent trace those are the same log line. Separate the roles and the failure has an address: either the task tree was badly cut, or a leaf was executed badly, and each has a different fix.

What does agent coordination cost to build?

No model release fixes coordination. Two agents working the same codebase or the same ticket queue will duplicate effort, and duplicated effort is the mild version. The expensive version is both of them deciding the same design question, deciding it differently, in separate places, each internally consistent. Nothing fails. The system now contains two answers. Cursor calls this split-brain design, and at swarm scale it got severe enough that the earlier architecture piled up more than 70,000 merge conflicts on a single task.

Reconciling that is human work, and it grows with throughput. Agent count has little to do with it.

Four pieces of infrastructure sit below the agents and hold this line. A written record of decisions that every agent reads before acting and appends to after deciding. A check in the build that fails when code contradicts the record, so drift surfaces at compile time and not in review. An arbiter with authority to pick one of two conflicting implementations and delete the other. Scoped credentials per agent, so a worker cannot quietly widen its own remit — that last piece sits in the API and integration layer. The record, the check and the arbiter are application code, and someone has to write them.

Budget that substrate as its own workstream. No prompt produces it and no framework setting switches it on.

When one agent is cheaper than several

Usually one agent with a good tool list can hold the whole job, and we will say so during scoping rather than after.

The test is whether you can draw the task graph before the run starts. If the sub-tasks are known in advance and always execute in the same order, a planner deciding at runtime is paying a model to read out a diagram you already have. Hard-code the graph, call a model at the points where judgment is genuinely required, and you get a workflow you can test deterministically. The agents versus automation trade-off is worth settling before anyone writes a tool definition.

A support agent that issues refunds fails that test, and building it as a swarm buys arbitration work for a job that had none. Multi-agent earns its overhead in a narrower case: the task tree is discovered during the run, the branches are independent enough to execute in parallel, and no single context window can hold the whole job. Long code migrations qualify. So does deep research, where you only find out which sources matter after the searching has started.

How to price a multi-agent build

Start from the single-agent baseline. An agent that owns one job, grounded in your own documents and writing to a system or two, sits in the ₹14L – ₹18L band in our agent scoping guide — that tier carries an approval path for anything above your limit, full tracing, an evaluation set and a staged rollout. It is the honest comparison point, and it is the version most buyers should price first.

Multiply that figure by agent count and you get the wrong number. The agents are the cheap part. What gets added is the decision record and the checks enforcing it, the arbitration path, per-agent credentials and traces, and an evaluation set that has to score the whole system end to end. Work of that shape belongs in the agent-platform tier on the same guide, and the figure comes out of a paid discovery against a written scope, because coordination requirements follow your existing systems and approval chains, which the agents themselves never touch.

Then there is the operating line. A planner-worker topology can cut token spend hard, as Cursor’s benchmark did. What it also does is stop the spend behaving like a fixed cost per request: it moves with every retry and every re-plan after a failed leaf. Ask for that estimate at your real volume before you sign anything, and ask what happens to it when a planner decides one task needs decomposing twice.

Adding a second agent: the cost you are accepting

Get these answers in writing before the second agent exists. Where does its output go, and what happens when that output contradicts the first agent’s? Who or what decides between them, and does that thing have authority to delete work? Which decisions are allowed to be made at runtime, and which get looked up from the record? And what does a single run cost at production volume, retries included?

If the answers come out thin, the build is a single AI agent with a tool list, and it will do the job for less.

Coordination debt stays silent while agent count is small. With two agents there are few enough overlapping decisions that a clean trace is the expected result, not evidence the architecture holds. The design looks like it is working right up to the point where throughput makes collisions routine. What arrives then are two cost lines that both grow with volume: tokens spent generating work that gets thrown away, and people whose week goes on reconciling machine output nothing can arbitrate automatically. A model upgrade will not touch either. The plan-and-execute split, the decision record and the arbitration path all sit underneath the agents, so retrofitting them means rebuilding the system around agents you have already shipped and are already depending on — and every month of volume growth makes that rebuild more expensive than it was the month before.