What happens when the budget runs out
Every AI product has a cost problem and most solve it by hoping nobody notices. The two failure modes are an invoice nobody expected and a feature that stopped working without saying so — and the second is worse.
What it is, and what it is not
A per-tenant budget with per-agent caps beneath it, a pre-call decision about whether a request can proceed, and a stated order in which capability is withdrawn as the budget is consumed.
It is not usage reporting. A dashboard showing what was spent last month tells you about a decision that has already been made. The useful mechanism decides before the call, which is why the budget check sits in the request path rather than in a nightly job.
It is also not a hard stop. A cap that turns agents off entirely at 100% produces a Tuesday where the product visibly loses features and nobody can explain why — which is the same experience as a bug, and gets reported as one.
The mechanism: degrade in a stated order
As the budget is consumed, capability is withdrawn in an order you can read in advance rather than discover.
Expensive reasoning stops first — multi-hop traversals, large-context analysis, the operations that cost the most per answer and are used least often. Drafting stops second: preparing a change object is valuable and it is not urgent. Recommendation stops third.
Retrieval and citation never stop. Finding things and showing what they are grounded in is the cheapest thing agents do and the most continuously useful, so it survives to the end of the budget. An engineer searching semantically at 98% of budget still gets an answer.
Each step is a notification rather than a silence. Administrators are told when degradation begins, which agents are affected and what it would cost to restore them — so a budget reached is a decision somebody makes rather than a symptom somebody reports.
The failure it prevents
An organisation enables agents, uses them enthusiastically for a month, and receives an invoice three times the expected figure. Nobody can attribute it: the usage was real, distributed across forty people and a dozen agents, and there is no per-agent breakdown to argue with.
The response is almost always to turn the whole thing off, because a cost nobody can attribute is a cost nobody can manage. The feature was working; the accounting made it unusable.
The other version is quieter. A cap is hit mid-month and agents stop responding well. Users notice the assistant getting worse, conclude the AI is unreliable, and stop using it — and by the time somebody works out it was a budget ceiling, the reputational damage inside the organisation is done and does not reverse when the budget resets.
How it meets the rest of the product
Usage is attributed per agent, per user and per tenant, so “what did the Cost Agent spend this month” is a query rather than an estimate. That attribution is what makes a per-agent cap meaningful: you can disable an expensive agent rather than throttling everything.
Model routing is the other half of the same problem. Cheap mechanical work — classification proposals, similarity matching — routes to smaller models; multi-hop reasoning routes to larger ones. The usage screen shows which model handled which request, so a cost figure is explicable rather than aggregate.
Metering records land in the same audit trail as everything else, naming the agent, its tier, the tools called and the tokens consumed. A spend question and a governance question resolve to the same rows rather than two systems that disagree.
Where you bring your own model key, requests go to your provider account under your contract and are not metered by us at all — the budget mechanism becomes yours to run.
How it meets your ERP
Nothing about budgets touches your ERP, and this section exists to say so plainly rather than to manufacture a connection.
The one genuine intersection is that agents reading ERP context consume budget like any other work, and the read-back itself does not. Pulling cost and inventory on a schedule is connector traffic rather than model inference, so a tenant running agents at Observe pays for very little.
That matters for planning: the cheapest useful configuration is agents enabled for retrieval and citation over a fully synced ERP context, which gives engineers cost and stock visibility on every structure at close to no inference cost.
Where the boundary is
A budget is a spending control, not a correctness control. Staying under it does not make answers right, and the citation model and permission tiers are what address that — a cheap wrong answer is still a wrong answer.
It also cannot predict what a month will cost before you use it. Usage depends on how people work, and any figure quoted in advance would be a guess presented as a forecast. The honest approach is a low starting budget, per-agent attribution from day one, and raising it deliberately.
Facts
| Scope | Per-tenant budget, with per-agent caps beneath it |
| Decision point | Before the call, in the request path |
| Degradation order | Reasoning → drafting → recommendation |
| Never stops | Retrieval and citation — the cheapest, most useful work |
| On reaching a cap | A notification, never a silence |
| Attribution | Per agent, per user, per tenant |
| Routing | Cheap work to smaller models; shown per request |
| BYOK | Not metered by us at all — the budget becomes yours |
Frequently asked
What happens when we hit the budget?
Capability degrades in a stated order rather than stopping outright. Expensive reasoning goes first, then drafting, then recommendation. Retrieval and citation never stop at all, so an engineer searching semantically at 98% of their budget still gets a useful answer back.
Why not just stop at 100%?
Because a hard stop produces a Tuesday where the product visibly loses features and nobody can explain why. That is the same experience as a bug and gets reported as one, and the reputational damage inside an organisation does not reverse when the budget resets.
Can we see what each agent spent?
Yes — usage is attributed per agent, per user and per tenant. That attribution is what makes a per-agent cap meaningful, because you can disable one expensive agent rather than throttling everything and degrading work that was costing almost nothing.
Will we get a surprise invoice?
No. The budget check sits in the request path rather than in a nightly job, so spending is bounded rather than merely reported afterwards. Administrators are notified when degradation begins, which agents are affected by it, and what restoring them would actually cost.
How does model routing affect cost?
Cheap mechanical work such as classification proposals and similarity matching routes to smaller models, while multi-hop reasoning routes to larger ones. The usage screen shows which model handled which request, so a monthly figure is explicable rather than one opaque aggregate.
What if we bring our own key?
Requests go to your provider account under your own contract and are not metered by us at all. The budget mechanism becomes yours to run, and Manufacturing PLM never holds the content — which is also the strongest available answer to a data-boundary question.
Can you tell us what a month will cost?
Not honestly in advance. Usage depends entirely on how people work, and any figure quoted up front would be a guess presented as a forecast. Start with a low budget, watch per-agent attribution from day one, and raise it deliberately.