A McKinsey study on agentic coding workflows, reported by Business Standard in August 2026, found that multi-turn agentic workflows can consume up to 1,000 times as many tokens as a standard chat or a single-turn reasoning task. Of that token spend, the final output the user actually sees accounts for only 5%-15%. The rest goes to processing context: planning steps, tool calls, agent-to-agent handoffs, and retries.
McKinsey’s separate Enterprise AI FinOps survey, published in May 2026, found that 93% of respondents had already exceeded their AI budgets. Those two numbers describe the same problem from opposite ends.
I lead the Salesforce and Vlocity CPQ and CLM transformation at T-Mobile, through Mphasis, and outside that role, I research token optimization and COâ‚‚-aware inference. My contrarian read, and it’s one some of my peers push back on, is that compute economics, not model capability, will decide which enterprise AI programs are still funded in 2027. The token multiplier problem is exactly why.
Where the tokens actually go
Every agent added to a workflow adds a planning step, a tool call, and usually a self-check before handing off to the next agent. None of that is visible in the final output of a business user review. A five-agent chain that ends in one paragraph of customer-facing text can burn through tens of thousands of tokens to get there, most of it context that the agents pass to each other and reread at every step.
This is invisible to most budget owners because the bill arrives as one number per month, not broken out by agent or by step. PwC’s 2026 Global CEO Survey found that only 12% of executives report that AI is delivering both cost and revenue improvements simultaneously, while 56% report no significant financial benefit from their AI investments so far. A program can look successful in a demo and still be burning a budget that nobody can trace to a specific cause, because the cost sits inside a workflow that was never instrumented to show where the tokens went.
Carbon-aware inference routing
The idea is simple: not every step in an agent chain needs the same model. Planning a multi-step task and reasoning through an ambiguous judgment call benefit from a larger, more capable model. Formatting a response, checking a value against a rule, or validating a handoff between agents usually don’t. Routing each step to the smallest model that can do it correctly, rather than running the whole chain on a single frontier model by default, reduces token spend at steps where a smaller model is just as accurate.
The carbon-aware part adds one more variable: when and where the inference runs. Compute regions and time-of-day power mixes vary in carbon intensity, sometimes by a wide margin depending on the grid. For workloads that aren’t latency-sensitive, batch jobs, overnight contract processing, non-urgent report generation, and routing to a lower-carbon region or time window cost nothing in output quality and reduce the footprint of work that didn’t need to run in real time anyway.
Neither piece requires new model capability. Both require treating inference routing as a design decision made before a workflow ships, not a setting nobody revisits after launch.
In a CPQ and CLM agent chain like the one I work on, that split is concrete. Assessing whether a discount exception fits a customer’s negotiated terms is a judgment call and should be handled by the larger model. Confirming that a generated quote matches the approved template or formatting a summary for a rep is a rule check and doesn’t need the same model. Routing those two step types differently, instead of running the entire chain on one model, is the kind of change that shows up in the token bill within a month, not a quarter.
Who should own this line item?
Most transformation programs place AI infrastructure costs under IT, alongside cloud spend and licensing. That’s the wrong owner for a workflow tied to revenue. If an agent chain generates quotes, reviews contracts, or touches anything in the quote-to-cash process, the team that owns the business outcome should also own the token budget for it, just as they’d own a staffing cost or a tooling license.
An IT-owned infrastructure line item gets optimized for uptime. A RevOps-owned one is optimized for the cost of the outcome it produces, the number that actually matters to a transformation program’s return.
What I’d measure before optimizing anything
Before choosing a routing strategy, get visibility into where the tokens are actually going. Three numbers, per workflow, not per account:
Token cost per agent step, not per workflow. A five-agent chain needs five numbers, not one. Without that breakdown, there’s no way to know which step is worth optimizing and which one is a rounding error.
The ratio of context tokens to output tokens. If output is 5% to 15% of total spend, as McKinsey’s research found, the other 85% to 95% is the actual target for reduction, not the part users see.
Retry and self-check frequency. Agents that re-verify their own work or retry failed tool calls can multiply token spend silently. That number alone often explains a cost spike better than usage growth does.
None of this requires new tooling that most enterprises don’t already have. It requires logging at the step level instead of the workflow level, which most agent deployments don’t do by default because it wasn’t required to get the demo working.
The takeaway
Pick one agent workflow already in production and get the per-step token breakdown before adding a sixth agent to it. If nobody on the team can produce that breakdown today, that’s the actual finding, and it’s worth more than any model upgrade you’re considering next quarter.
Sources cited:
