Your AI agent has no idea what it costs

By Lindsey JNovember 12, 2026

Picture a team that builds a support agent to read a ticket, pull billing history from two systems, draft a reply, and retry on its own when a tool call fails.

The agent works well in testing. Six weeks after launch, the team notices its monthly AI bill has tripled. Nobody on the team can say which step caused it.

That gap, between an agent working and a team knowing what it costs to run, is common enough now to show up in survey data, not just in one team's invoice.

Why AI agent cost control breaks down

An IDC survey of 318 senior decision-makers at organizations with more than 1,000 employees in the United States, United Kingdom, and Ireland, commissioned by DataRobot and published in December 2025, found that 92 percent of organizations running agentic AI said costs came in higher than expected. 71 percent of respondents overall said they have little to no control over where that cost comes from.

The reason is structural, not a one-off mistake. A traditional software feature's cost scales with how many people use it. An agentic workflow's cost scales with how many steps one task takes, and that number is not fixed in advance. An agent can retry a failed tool call, loop while it waits on a slow system, or chain several calls together to answer one question. A pilot usually runs for days. A production workflow runs for months, which is enough time for a rare expensive path to become a routine one. None of that shows up on a dashboard until the invoice does.

A decision rule: set the ceiling before the agent runs

The fix is not a bigger budget. It is a limit set at design time, the same way a rate limit protects an API from one client overwhelming it. Apply the same idea one level up, at the task instead of the API call. Before an agentic feature ships, name a maximum token or dollar spend for one task. Decide in advance what happens when the agent is about to cross that line: stop and return what it has, escalate to a person, or fall back to a cheaper, simpler path. The ceiling does not need to be perfect on day one. It needs to exist. It needs an owner who gets paged when it is hit, the same way an on-call engineer gets paged for a service outage.

Before you ship an agentic feature, check:

Does every agentic workflow have a maximum cost or token budget per task, set before launch?
When an agent is about to exceed that budget mid-task, do you know whether it stops, escalates, or keeps going?
Can you see, per completed task, which single step consumed the most tokens or tool calls?
Does your cost-per-task number reach the same dashboard as your cost-per-ticket or cost-per-resolution number?
If this agent ran ten times more tasks next month, would anyone notice before the invoice did?

A test to run this week

Pick one agentic workflow already in production. Pull its last 20 completed tasks and find the single most expensive one. If it cost noticeably more than a typical task, trace the step that caused it. Usually the cause is a retry loop, an unusually long context window, or a tool call repeated more times than the task needed. That step is where the ceiling belongs. Do this before the next budget review, not after it, so the finding changes a design decision instead of becoming a line item explained after the fact.

A ceiling only works if someone is actually watching it. That is the same bottleneck we found when we looked at approval volume for agentic features: once an escalation step exists, its own volume becomes the limiting factor, not the budget line.

FAQ

Is this only a problem for agents that make many tool calls?

No. Even a single-call workflow can run long if it retries on failure or waits on a slow tool before giving up. The ceiling applies to any agent whose number of steps is not fixed in advance, not only to agents built from many tools.

Will a cost ceiling make the agent less reliable?

It can, if the ceiling is set too low and the agent stops before finishing real work. That is why the ceiling needs an escalation path, not only a stop command. A person who can approve more budget for a task that is close to finishing keeps the ceiling from becoming a new failure mode.

Who should own the ceiling, engineering or finance?

Neither owns it alone. Engineering knows where the loop lives in the workflow. Finance knows what cost per task should be for the business to make sense. The decision rule works only when both groups see the same number on the same dashboard.