Agent FinOps: A Runtime Concern, Not a Procurement One

A signed enterprise agreement with better per-token pricing feels like the finish line on agent cost control. It isn't. It's the easiest 20% of the problem, and it's the 20% procurement teams are already equipped to solve. The 80% that actually determines whether an agent fleet's spend stays predictable happens after the contract is signed, inside the runtime, on every individual request — and most organizations we've walked into have no governance mechanism there at all.

The failure mode contracts can't prevent

A negotiated rate doesn't stop a planning agent stuck in a reasoning loop from calling a tool forty times on a single user request because a validation step keeps failing and the retry logic has no ceiling. It doesn't stop a poorly scoped prompt from pulling ten thousand tokens of irrelevant context into every call because someone concatenated a full document instead of a retrieved excerpt. It doesn't stop a genuinely useful agent from getting so popular, so fast, inside the organization that its weekly spend triples before anyone notices, because nobody owns a number that would have triggered an alert. Every one of these is a runtime event. None of them shows up in a vendor negotiation.

What runtime governance actually requires

Three mechanisms have to exist, and in our experience the first two are usually missing entirely even in organizations that consider themselves cost-disciplined.

Per-request and per-session budgets, enforced, not just logged. An agent session gets a token and tool-call budget at initiation, tied to the task it's actually performing — a support-ticket triage session and a multi-document research session should not share a ceiling — and when the budget is exhausted, the agent has to degrade gracefully (hand off to a human, return a partial answer) rather than silently continuing to spend.

Circuit breakers on retry and loop behavior. Any agent architecture with self-correction or re-planning needs an explicit, low ceiling on how many times it will retry a failing step before escalating, because the failure modes that cost the most money are exactly the ones where an agent is "trying its hardest" — most looping-cost incidents we've diagnosed were an agent behaving exactly as designed, just without a ceiling on how long "trying" was allowed to run.

Spend attribution at the level of task type, not just API key. A single API key shared across a dozen agent workflows tells you the organization spent $40,000 last month and nothing else useful. Attribution tagged by task type at the point of the call tells you which specific workflow's unit economics changed, which is the only version of that number anyone can act on.

Why this has to live in engineering, not finance

Finance teams are good at negotiating rates and bad at instrumenting runtime behavior, for the unremarkable reason that runtime behavior isn't visible from an invoice. The organizations that get agent spend under control treat it the way they'd treat infrastructure cost governance — as an engineering discipline with dashboards, alerts, and an on-call response, sitting next to the observability stack that already watches latency and error rate. The budget enforcement code lives in the same request path as the agent's tool-calling loop, not in a monthly spreadsheet reconciliation. That's the actual shift: cost stops being a thing you review after the fact and becomes a constraint the system respects while the request is still in flight, the same way you'd treat a timeout or a rate limit.