← All articles
FinOps 8 min read

When the Software Spends on Its Own: FinOps for Agentic AI

AI agents that loop, call tools, and spawn sub-agents can multiply token consumption in ways no per-request budget anticipates. Here is how finance teams should think about the cost of software that decides how much to spend.

CostDefender Team ·

Listen to article

Narrated by CostDefender

Download

For most of software history, the cost of running a feature was fixed by its code. A function did a defined amount of work, and finance could reason about its cost from usage counts. Agentic AI breaks that relationship. An agent is a language model given a goal, a set of tools, and permission to decide its own next step, so the amount of work it does, and the amount it spends, is determined at runtime by the model, not by the engineer who wrote it. The same request can cost pennies or dollars depending on how many steps the agent decides it needs.

That is a genuinely new cost dynamic, and it is arriving fast. Vendors across the industry, from the major model providers to the frameworks built on top of them, have shifted their roadmaps toward agents that plan, use tools, and run multi-step workflows with limited human intervention. The productivity case is strong. The finance case is that a single agent invocation is not one API call; it is a loop of them, and loops without limits are how a controllable feature becomes an uncontrollable bill.

One request, many billed callsUser goalAgent plans(billed call)tool call → re-reasontool call → re-reasonsub-agent (its own loop)Each step re-sends the growing history as input, and each is billedThe model, not the code, decides how many steps happenA single “request” can be five calls or fifty; cost is decided at runtime
Agentic workloads turn one user action into a variable, model-directed number of billed calls.

Why an agent costs more than it looks

To understand agent cost you have to picture the loop. The agent receives a goal and makes a model call to plan its first action. It calls a tool (a search, a database query, a code execution) and feeds the result back to the model to decide the next step. It repeats until it believes the goal is met. Every one of those steps is a billed model call, and because the APIs are stateless, each call re-sends the entire accumulated history: the original goal, every prior thought, and every tool result so far.

This produces two compounding effects at once. The number of calls grows with the difficulty of the task, and the size of each call grows as the transcript accumulates. A ten-step agent run does not cost ten times a single call; it costs more, because the tenth call carries the weight of the previous nine. Anthropic’s own published analysis of multi-agent systems has noted that agents can consume many times the tokens of a single chat interaction, and that architectures using multiple coordinating agents multiply that further. When an agent is allowed to spawn sub-agents, each with its own loop, the fan-out is multiplicative rather than additive.

The practical consequence for finance is that the unit of cost is no longer stable. In a traditional feature, cost per request is roughly constant and you forecast on volume. In an agentic feature, cost per request is a distribution with a long tail: most runs are cheap, but a minority spiral into dozens of steps, and those tail runs can dominate the bill. Forecasting on an average, without understanding the tail, is how teams get surprised by a monthly invoice that is double the model.

The failure modes that actually run up the bill

Agents fail expensively in a handful of recognizable ways, and each has a cost signature finance should learn to spot.

Loops that don’t terminate. An agent that cannot solve a problem may keep trying, re-planning, re-calling the same tool, and re-reading the same growing transcript, until something forces it to stop. Without a hard step limit, a single stuck run can consume more tokens than thousands of successful ones. The most important cost control in any agent is the least glamorous: a maximum step count and a maximum token budget per run, enforced in code.

Context bloat. Because every step re-sends the full history, a long-running agent’s per-call cost climbs steadily as its transcript grows. An agent that dumps entire tool outputs (a full API response, an entire file, a complete search result set) into its context pays to re-read all of it on every subsequent step. Trimming, summarizing, and caching context is not a nicety; it directly bounds the cost of long runs.

Retries and verification overhead. Robust agents check their own work, retry failed steps, and sometimes run a second model to verify the first. Each of these is sound engineering and each adds billed calls. They are worth paying for, but only if someone has decided they are worth it, rather than accumulating by default.

Unbounded fan-out. Multi-agent designs where one orchestrator spawns many workers can deliver better results on complex tasks, but the token cost scales with the number of agents. A design that spawns a sub-agent per item in a list can quietly turn a single request into hundreds of model calls. Fan-out needs an explicit cap, the same way a thread pool does.

Governing spend the software controls

The uncomfortable truth about agentic AI is that the software is making spending decisions, so the governance has to move to where those decisions happen: into the agent’s own execution, not just the monthly review. The good news is that the controls are concrete.

The foundational one is a per-run budget. Every agent invocation should carry a hard ceiling, a maximum number of steps and a maximum number of tokens, beyond which it stops and returns what it has. This is the circuit breaker that turns a catastrophic runaway into a bounded, recoverable failure. It should be enforced in code, not left to the model’s judgment, because the whole premise of an agent is that its judgment about how much work to do is exactly what varies.

Above the individual run, the same FinOps disciplines that govern cloud compute apply, adapted for agents. Attribute every run’s cost to a feature, team, and environment so you can see which agentic workload is driving spend. Track cost per completed task, not just per request, because a cheap run that fails and a costly run that succeeds are very different value propositions. Watch the tail of the cost distribution, not the average, because the tail is where the money and the risk live. And route by difficulty: use a smaller model for the routine planning steps and reserve the flagship for the genuinely hard reasoning, since an agent that makes fifty calls magnifies the price gap between model tiers fifty times over.

The value question finance should keep asking

None of this argues against agents. Agentic workflows can automate work that no fixed program could, and when they succeed they often replace far more expensive human effort. The point is that their cost is variable by design, so the discipline has to be too. The right posture is not to cap agents so tightly they cannot work, nor to let them run unbounded because the demos are impressive. It is to make each agent’s spend visible, attributable, and bounded, then compare it honestly against the value of the task it completes.

The organizations that will use agents well are the ones that treat an agent as what it is: a piece of software that has been delegated a budget. You would not give an employee an unlimited corporate card and no reporting. An agent that decides how much to spend deserves exactly the same governance: a limit, a ledger, and a regular review of whether the results were worth the run.


CostDefender gives finance a read-only, closed-loop view of AI and cloud spend together, attributing cost to the features and agents that generate it, flagging the runaway, and verifying that every optimization reached the run rate. See the approach →

CostDefender

Defend your cloud budget.

CostDefender gives finance teams read-only cloud cost visibility, verified savings tracking, and closed-loop accountability across AWS, Azure, and GCP.

Request Early Access →