The economics of agentic workflows, optimizing for cost and latency

We have the clearest public data point on this from Anthropic, whose engineering team published a candid account of how they built the multi agent system behind their research feature. The architecture is an orchestrator and worker pattern. A lead agent receives a question, plans an approach, and spins up several subagents in parallel, each with its own context window, each chasing one independent thread, after which a separate pass reconciles their findings and attaches citations. On their internal evaluation this arrangement outperformed a strong single agent by a little over ninety percent. The price of that capability was striking. The system consumed roughly fifteen times the tokens of an ordinary chat interaction, and even a single agent uses around four times the tokens of a chat.

Where the cost actually comes from

Tokens are the metered resource, and agentic systems spend them in three ways that a single chat does not. They make many more model calls, because planning, tool use, reflection, and synthesis are each separate turns. They carry much more context, because each step re reads the accumulated state of the task. And when they run several agents, they multiply both of those by the number of agents. A pattern where several agents debate across several rounds is the clearest example, because the cost grows with the number of agents multiplied by the number of rounds, and that product climbs quickly.

When the cost is worth paying, and when it is not

The decisive question is whether the task genuinely decomposes into independent parallel parts. Anthropic was direct about the limitation. Parallel subagents help only when the subtasks are truly independent. If one subagent needs another's findings before it can do its own work, the parallelism collapses into expensive serial execution with extra coordination overhead, and you pay the multiplier without earning it. Breadth first research, where the directions are independent and the answer is valuable, is a good fit. Tightly interdependent work such as coding and debugging, where every part depends on the others sharing the same context, is not. A separate body of research that asks why multi agent systems fail points to exactly this, where coordination and miscommunication between agents are common causes of failure.

The levers that move cost and latency

Once you accept that tokens are a budget, the optimization work looks a lot like ordinary performance engineering.

Choose the simplest architecture that works. Anthropic's own guidance on building effective agents argues for reaching for the simplest pattern first, and for using a fixed workflow rather than an open ended agent whenever the task is predictable enough to allow it. Most teams reach for multiple agents reflexively when a single well designed agent, or even a simple chain of steps, would do the job at a fraction of the cost.

Route work to the right sized model. Not every step needs your most capable and most expensive model. A small fast model can handle routing decisions, classification, and easy steps, escalating to a larger model only when the work demands it. The research on cascading models, including the well known study on reducing cost while improving performance, shows how much can be saved by sending the easy questions to the cheap model and reserving the expensive one for the hard ones.

Cache the stable context. When the same large instruction block or document is sent on every call, caching it avoids paying to process it again and again, which cuts both cost and latency.

Return summaries, not transcripts. Subagents that hand back a condensed result rather than their entire working transcript keep the orchestrator's context small, which is the single biggest driver of cost in a deep multi agent run.

Bound the loops. Give agents explicit budgets, maximum step counts, and early stopping conditions, so a confused agent cannot quietly spend a fortune circling a problem it cannot solve.

Measure cost per outcome, not cost per token

The metric that matters is not the price of a token. It is the cost of a successful outcome, which is the total spend divided by the rate at which the system actually produces the result you wanted. A cheaper per token system that fails half the time and has to be retried can easily cost more per successful outcome than an expensive system that succeeds the first time. This reframing is what lets you reason about agentic spend the way a business reasons about any other unit economics.

The summary

Multiple agents buy capability with tokens. Spend that budget deliberately. Use the simplest architecture the task allows. Route work to the right sized model, cache the stable context, return summaries rather than transcripts, and set bounds on loops. Judge the system by the cost of a successful outcome rather than the price of a token. These practices keep an agentic system affordable as it scales.