I Assumed Multi-Agent Meant 4x the Cost. The Math Said Otherwise.

When I first sketched a multi-agent redesign of one of my pipelines, I did the obvious math and almost abandoned the idea.

The pipeline evaluates items in bulk. Say a thousand items. The single-agent version makes one LLM call per item, so a thousand calls. The multi-agent redesign used four agents per item. Four thousand calls. Four times the cost, for the same throughput.

That math is correct, and it's also the wrong math. It took me an embarrassingly long time to see why.

Not all calls are equal.

The number I was ignoring is the price gap between model tiers. Small fast models cost a fraction of frontier models per token. Not slightly less. Dramatically less, often around twenty times cheaper.

A single-agent pipeline can't exploit this. One agent does the whole job, and the job as a whole is hard, so the whole job runs on the expensive model. Every token, including the trivially easy ones, gets billed at the frontier rate.

Decomposition changes that. Once the work is split into separate agents, each agent's job has its own difficulty, and you can ask a question that was meaningless before: does this specific step need frontier reasoning?

Sorting the work

When I actually sorted my pipeline's subtasks by difficulty, the pattern was obvious.

Scanning text for specific keywords and phrases: mechanical. Extracting fields into a fixed format: mechanical. Simple binary classification: mechanical. None of this needs a frontier model. A small model does it just as well, at a twentieth of the price.

Recommended by LinkedIn

What genuinely needed the big model: the nuanced judgment calls, the synthesis across many inputs, and the orchestration decisions about what to do next.

My four-agent design turned out to be two small-model agents and two big-model agents. Rerunning the cost math with real prices per tier, the four thousand call version came out cheaper than the thousand call version. And that's before counting the quality benefits, because a focused agent with a narrow brief simply does its one job better.

How to decide what to downgrade

You don't guess which steps can run on the small model. You measure.

My procedure, which is nothing fancy: take fifty representative samples. Run the subtask on the big model and the small model. Compare. If the small model agrees with the big one on roughly ninety five percent or more of the samples, the subtask gets downgraded. If not, it stays on the big model and I've spent a few cents learning that.

Two things to watch. First, rerun this check occasionally, because your data drifts. Second, be more conservative with subtasks that feed decisions than ones that feed summaries. An error that propagates costs more than an error that sits in a report.

The question that decides the architecture

The lesson I took away: when someone shows you a multi-agent design and objects that it multiplies the number of calls, the call count is not the interesting number.

The interesting question is: how many of those calls have to be expensive?

Sometimes the answer really is "all of them," and the multi-agent version costs more. You then decide if the quality and speed are worth it. But a surprising amount of the time, decomposition is exactly what makes the cheap tier usable at all, and the "expensive" architecture is the affordable one.

Next in the series: the five patterns that nearly every production multi-agent system boils down to. Once you can name them, you'll see them everywhere.