What should an agent’s budget buy?

The agent stayed under budget, but did it finish anything worth paying for?

A spending limit answers an important operating question: how much are we prepared to spend? It cannot tell us whether the expenditure was useful. For that, the team needs a definition of completed work and a way to connect the cost of trying with the outcome of those attempts.

This sounds obvious until a dashboard offers a reassuring green budget bar and nothing beside it that describes the job.

Decide what counts as completed work

Consider a hypothetical support agent that reads incoming tickets and prepares responses for a human to review. A useful unit might be an acceptable response draft: grounded in the right account information, consistent with the support policy, and requiring no substantive correction.

“One model response” is a different unit. The agent might produce several while searching, correcting a tool call, or rewriting an answer that missed the question. Counting each response as completed work would reward activity regardless of whether the reviewer could use it.

Even “one ticket closed” could be wrong if the agent is not authorized to close tickets, or if it closes them before the underlying problem is resolved.

The task owner should define the outcome. The engineering team should make it observable. The cost owner should state which expenses are included. None of these responsibilities can be replaced by a token counter, although the counter supplies useful evidence.

The FinOps Foundation makes a related distinction between resource-efficiency measures and business-unit measures. Cost per token and cost per case resolved answer different questions; their usefulness depends on the decision being made. FinOps unit economics.

Charge unsuccessful attempts to the work

Suppose, purely for illustration, one configuration spends $4 and produces 8 acceptable drafts. Another spends $5 and produces 20. Their direct model cost per acceptable draft is $0.50 and $0.25 respectively.

The cheaper run is not the cheaper way to produce an acceptable draft. But neither calculation establishes overall business value. Perhaps the second configuration mishandles the most consequential tickets, or shifts more work to a reviewer. The completion rubric and task mix still matter.

Include failed attempts and retries in the total cost before dividing by accepted drafts. Dividing only the cost of successful calls by successful outcomes quietly makes unsuccessful work disappear. A configuration that wastes most of its budget can look efficient under that accounting.

Also keep unfinished work visible. “No acceptable outputs” should be reported directly, with the cost incurred. A cost-per-success metric with a zero denominator is undefined; it is not zero cost, and it should not be omitted from the report.

Decide when another attempt is worth it

A retry is a decision about the next unit of effort. It may recover a transient failure, improve a nearly acceptable answer, or repeat the same mistake. That makes retry policy part of the budget's purpose.

For a queue of independent tickets, the team might prefer to move on after a bounded number of unsuccessful attempts. For a nearly complete high-value task, another attempt could be justified. The right choice depends on the task's consequence, recoverability, and alternatives—not just on the fact that money remains.

Keep infrastructure retries distinct from asking the model to try again. One may repeat a request after a temporary service error; the other may run a larger reasoning-and-tool cycle. Nested retry behavior can make the actual attempt count difficult to see. AWS's reliability guidance recommends limiting retries and considering the layer at which they occur. Control and limit retry calls.

A budget report should make both kinds visible. If the agent spent its last dollar, an operator should be able to tell whether it bought another task, another model revision, or another attempt to reach an unavailable dependency.

Be precise about the money

“This run cost $5” can describe several different things: a configured allowance, an estimate calculated from usage, an amount reported by a service, or a reconciled invoice allocation.

Those numbers need not be identical. The estimate might exclude tool charges or infrastructure. Usage may arrive after a request finishes. A provider's billing terms may differ from a simple public-rate calculation. A distributed limiter's behavior near the boundary depends on its implementation and concurrent work.

These are reasons to label the basis, not reasons to abandon measurement. Early teams can start with a narrow, honest view: direct model usage valued using a named rate sheet on a named date, excluding specified costs.

For the last row, start with a note about the reviewer's work if you can't yet measure it. You can still use a limited cost estimate, as long as you say what it leaves out.

A cap is still a sensible first move

There is no need to postpone a spending limit until the organization has perfect unit economics. A cap can contain an experiment, protect a shared allowance, and expose unexpected behavior. It is a practical first control.

The mistake is asking that control to answer a different question. “We limited the exposure” and “this workflow is worth expanding” require different evidence.

Start with one workflow, one acceptable outcome, and one declared cost basis. Track what was attempted, what passed, and what remained unfinished. Add human effort and shared costs as the decision starts to require them.

Then ask the budget owner a better question than whether the agent stayed under its limit: would you buy the same completed work again, under the same conditions, at that cost?