By Greg Nowak. Last updated 2026-08-08.
A billing dashboard tells you what an AI agent has already spent. It does not stop the agent that is still retrying a broken tool, expanding its context, or delegating more work while nobody is watching the chart.
That is the practical difference between monitoring agent costs and controlling them.
Agent spending is created inside the workflow. A single task can trigger several model calls, tool invocations, retries, investigations, and subtasks. A monthly account limit matters, but it is too blunt to manage what is happening inside one runaway session. Controls also need to work at the cycle, task, session, and workflow level.
The aim is bounded autonomy: give the agent enough room to do useful work, with a clear spending envelope and a safe response when it approaches the edge.
Agent spending fails in unfamiliar ways
Most conventional software follows a path designed in advance. An agent can decide how many steps to take as it runs. That flexibility is part of its value, but it creates cost patterns that ordinary infrastructure monitoring may not catch quickly enough.
AWS’s Agentic AI Lens identifies reasoning-loop token spikes, tool-invocation storms, and memory growth as agent-specific escalation patterns. It recommends detecting these within minutes instead of finding them days later in billing data. AWS also calls for spending boundaries at several layers, including per-cycle, per-task, and per-day budgets.
A 2026 research paper treats LLM-agent budget overruns as a production failure class. Its catalog covers 63 confirmed incidents across 21 orchestration frameworks. The important point is not simply that model calls cost money. Retry loops and delegated budgets can keep consuming resources before an operator notices, understands the cause, and intervenes.
If a workflow can spend repeatedly without making corresponding progress, it is not just expensive. It is malfunctioning.
A notification is not a guardrail
Budget settings often look more protective than they really are. GitHub’s current guidance draws a useful distinction: reaching an enterprise or cost-centre spending limit sends a notification by default, but usage continues unless “Stop usage when budget limit is reached” is enabled.
GitHub also warns that a heavy user or an automated agent session can consume a disproportionate share of a pooled allowance early in the billing cycle. Its approach combines user-level budgets, individual overrides for legitimate power users, an enterprise spending limit, hard-stop configuration, and ongoing monitoring.
Every budget therefore needs an enforcement policy. When the threshold is reached, does the workflow stop, use a cheaper route, request approval, return a partial result, or hand the task to a person? If the only response is an email, the budget is still an observability feature. It is not a brake.
Put controls around each run
Useful cost control starts with run-level records. For every run, capture the task type, model, token consumption, tool calls, retry count, latency, outcome, and estimated cost. If the work branches into subtasks, preserve the relationship between each child task and its parent. Otherwise, the real cost of the original request becomes difficult to reconstruct.
Raw spend is only one measure. Cost per successful result is usually more revealing because it exposes workflows that look cheap per call but need several attempts to finish. A cheaper model may cost more in practice if it creates extra retries. An expensive investigation may still be sensible when it resolves a valuable problem in one bounded run.
| Control level | What to watch | Practical response | Why it matters |
|---|---|---|---|
| Cycle or step | Tokens, tool calls, repeated state | Stop the step or change strategy | Catches loops before they compound |
| Task | Total cost, retries, elapsed time | Return partial work or request approval | Keeps the task within its economic value |
| Workflow | Fan-out, delegated spend, completion rate | Block new subtasks or route to a person | Stops parallel work bypassing the parent budget |
| Daily or account | Aggregate spend and unusual growth | Throttle throughput or enforce a hard stop | Protects the wider service and shared allowance |
| Review cycle | Cost per successful result | Retune limits, models, prompts, and tools | Improves cost and quality together |
These layers solve different problems. The account ceiling protects the organisation. A step-level limit catches a runaway sequence early. A task budget protects the economics of one job, while a workflow budget prevents delegated subtasks from collectively spending more than their parent task was authorised to use.
Do not make every threshold an emergency stop
A true maximum needs a hard stop, but that does not have to be the first response. AWS recommends graduated throttling and approval workflows so valuable work can continue at reduced throughput.
At an early threshold, the workflow might skip optional enrichment or move a straightforward step to a cheaper model. If retries increase without meaningful progress, loop detection can end the current strategy. Near the task ceiling, the agent can summarise what it has completed and ask for approval to continue. At the absolute limit, further billable execution stops.
This gives the workflow room to recover without leaving the spending boundary open-ended. The limit stays deterministic; the response reflects how much value the task has produced and how close it is to completion.
Pay close attention to autonomous triggers
Background activity deserves particular scrutiny under consumption-based billing. Microsoft states that billing for the Azure Copilot Observability Agent took effect on July 1, 2026. Its billing guide distinguishes focused chat from deeper, multi-step investigations involving multiple agent and tool calls.
Microsoft caps a single deep investigation at 500 Azure Agent Credits. It also explains that automatically triggered deep investigations are billable and can be disabled when an organisation wants a person to decide whether the additional work should run.
The wider lesson is to review what starts a run, not just the price of each call. An automated trigger connected to recurring alerts or events can multiply an otherwise reasonable per-run cost. Trigger frequency, duplicate suppression, investigation depth, and authority to launch another run all belong in the cost design.
The stop path is part of the workflow
Reaching a limit should not leave behind an opaque failure. A useful stop-or-handoff record preserves the task identifier, reason for stopping, spend consumed, steps attempted, evidence gathered, and recommended next action. A person can then continue from that point instead of paying the agent to rediscover the same information.
Alerts also need to distinguish between failure patterns. A reasoning loop, a failing external tool, rapid subtask fan-out, and normal demand growth require different responses. AWS specifically cautions against detecting anomalies without routing them through differentiated runbooks.
So the useful business question is not simply, “Can we see the AI bill?” It is, “Can every run explain what it cost, show whether it succeeded, and stop safely before it exceeds its authority to spend?”
Greg can help put that control layer in place: instrumenting runs, calculating cost per successful result, setting task and workflow budgets, adding retry ceilings and loop detection, and designing approval or human-handoff paths. The goal is straightforward—a workflow that remains useful and measurable without giving an agent an open-ended licence to spend.
Related on GrN.dk
- OpenAI Is Retiring Agent Builder: Save the Workflow, Not Just Prompts
- When AI writes JSON, one bad field can break the workflow
- AI Images Need a Chain of Custody, Not Just a Disclosure Label
Need help with this kind of work?
Design your agent cost controls Get in touch with Greg.
