Cost management: what a budget can and cannot do

There is a sentence in Microsoft's own documentation that changes how you design
cost control for agents, and most people have never read it.

"Notifications are triggered when the budget thresholds are exceeded. Resources
aren't affected, and your consumption isn't stopped."

A Microsoft Cost Management budget is an alert. It is not a brake. Setting one does
not prevent a single pound of spend.

And it is slower than you think

The second half of the problem is timing, and it is worse than the first.

"Cost and usage data is typically available within 8–24 hours and budgets are
evaluated against these costs every 24 hours."

So the loop is: your spend happens, the data appears somewhere between eight and
twenty-four hours later, and the budget looks at it once a day.

Now think about what an agent can do inside that window. An agent stuck in a
reasoning loop, or an orchestrator that keeps delegating, can burn through a
month's budget in an afternoon. Azure will not notice until tomorrow, and by then
the money is gone and the alert is an obituary.

This is not a criticism of Cost Management. It is an accounting system, and it
is a good one. It simply operates on a billing cadence, and agents operate on a
per-second one.

So you need two controls, catching different things

Cost Management catches the slow drift. Spend creeping up over weeks as usage
grows, a team's costs quietly doubling, a model change that made everything more
expensive. Use forecast alerts rather than actual-cost ones — they warn you
before the money is spent rather than after. And wire them to an action group
so the alert triggers a Function or a webhook that can actually do something,
rather than an email somebody reads on Monday. Note that action groups are
supported at subscription and resource-group scopes only.

The orchestrator budget catches the runaway. A hard per-request ceiling in
tokens or cost, enforced in code, that terminates the run and escalates. It has to
fail loudly — a silently truncated run produces a confident partial answer, which
is worse than an error because nobody knows to distrust it.

Neither substitutes for the other. Teams that build only the first find out the
difference in a single billing period.

The four words, which are four different mechanisms

The syllabus asks for a strategy covering "usage, quotas, allocations, and
chargebacks", and the exam distinguishes them.

Usage is what is actually being consumed, broken down finely enough to act on —
per agent, per tool, per environment. Aggregate spend tells you there is a problem
and never where it is.

Quotas are the technical ceiling: rate limits and capacity on a deployment. A
quota protects the platform. It is not a budget and it does not care about your
money.

Allocations divide capacity between consumers. The single highest-value move
here is separate deployments for interactive and batch workloads, so a batch
job cannot starve an interactive agent. That one decision gives you allocation,
protects latency, and makes chargeback straightforward — three of the four words
answered by one change.

Chargebacks attribute cost to whoever caused it. Which requires tagging from
day one, because you cannot reconstruct attribution afterwards. And note there is
no per-agent budget scope in Azure — the scopes are management group,
subscription and resource group. Agent-level attribution comes from tags and
filters, not from where you put the budget.

The trap

"Set a budget so we cannot overspend" is a trap in Microsoft's own words.

A budget is an accounting instrument with a daily cadence. The only thing that
stops an agent spending is a control inside the run — and if a scenario describes
a runaway loop or an unexpected overnight bill, the budget is the distractor and
the orchestrator ceiling is the answer.