Your ERP AI Is Metered by the Action and You Have No Circuit Breaker

Two things happened to enterprise software pricing in the last eighteen months, and almost nobody has put them in the same sentence. The meter moved from named users to autonomous actions, and the buyer never built the ability to stop the thing generating the actions. Separately, survivable. Together they turn a predictable subscription into an open-ended one.

I am not arguing against putting agents on your ERP. The operational case is the strongest it has been. I am arguing that the commercial construct you are about to sign has no ceiling in it, and that the ceiling is negotiable before signature and very hard to get afterwards.

The meter moved and the safety property went with it

Per-user licensing has an ugly reputation and one virtue nobody appreciated until it was gone. A named user is a physical constraint on spend. A person can only work so many hours, so your exposure was bounded by headcount, and headcount is a number your CFO already controls.

That bound was never perfect, and this audience has the scar tissue. Indirect access was exactly its failure: machines generated ERP activity under contracts that counted people. Worth remembering, because it was the dress rehearsal. The paper was not ready then either, and this time the machines initiate the work themselves.

SAP's AI Units, Microsoft's Copilot Studio credit metering, Oracle's Fusion AI Units and ServiceNow's assist allotments all price the work rather than the worker. Watch the shape rather than the branding: several are consumption riders bolted onto a per-user SKU, and that hybrid is where uncapped exposure hides, because the familiar half of the line item is the half that gets reviewed.

A human being in a retry loop notices. An agent in a retry loop bills.

That is not a hypothetical failure. It is the most common failure in distributed systems and has been for thirty years: a service returns something malformed, the agent tries again, and on most of these meters the unit is the attempt rather than the outcome. Nothing in the pricing model distinguishes a retry storm from productive work. If you cannot say whether your meter bills failed attempts, that is finding number one.

The number that should worry you

VentureBeat published research on 12 August 2026, from a July wave of 107 enterprise respondents, that puts a figure on this. Twenty one percent of enterprises track agent spend only through post hoc logs, with no real time way to halt a runaway execution. A further thirty percent rely on their platform's own budget caps and throttling, which is to say on the vendor's instrumentation to limit the vendor's revenue.

Treat those as directional. It is a small, self selected sample, and self selection in a survey about agent governance skews toward organisations that think about it, so my assumption is that the real figures are worse rather than better. The direction matches what I see in the field, and a native platform cap, when you press on it, is usually a toggle that disables the agent tomorrow rather than halting the one running now.

Why ERP makes this worse

The loop runs against your systems of record. Be precise about the mechanism, because the obvious version is wrong: retrying a posting that genuinely failed writes nothing. The dangerous case is the retry after a timeout that had already committed, where the agent cannot tell a lost response from a failed write and books the document twice. Non-idempotent retries against a ledger turn a billing problem into a reconciliation problem, and the second takes longer to clean up than the first takes to pay.

The workload is lumpy in the wrong way. Period close, year end, a migration cutover. Agent volume spikes by an order of magnitude at exactly the moments nobody is watching a consumption dashboard, because everyone is watching the close. Your worst billing month and your least supervised week are the same week.

Rate is not cap, and most schedules only give you a rate

Read the overage language in your AI schedule. Not the ordering document, the schedule. In most agreements I have reviewed in the last year it specifies an overage rate, what you pay per unit past your entitlement. It does not specify an overage cap, the most you can be charged in a period regardless of consumption.

Those are different instruments and the difference is the whole exposure. A rate tells you the price of the next unit. A cap tells you the worst case. A rate with no cap is not a price, it is a slope, and a slope multiplied by a process running at machine speed is not a number anyone in your finance function has modelled.

A good vendor counsel will answer that the entitlement is already the cap, because these units are sold prepaid: you buy a pool, and when it is gone the service stops. Where that is genuinely true it is a real answer, so establish whether it is true of yours. Prepaid drawdown has three exits. If the service stops mid close nobody accepts that, so the pool is topped up under duress at the prevailing rate, which is a cap with a hostage. Many agreements carry an overconsumption clause that flips to list rate billing once credits run out rather than halting anything. And a fixed pool is only a fixed quantity of work if the conversion between work and units is fixed.

The other standard answer is that overages get reconciled at true up. That is usually sincere and worth little. Goodwill is not a contractual limit, and a commitment living in an email thread does not survive an audit or an acquisition.

The conversion factor is the clause nobody reads

Where a vendor meters in an abstract unit rather than your currency, something converts your activity into that unit, and that factor decides what you actually pay.

Gartner has warned, and The Register reported on 19 May 2026, that SAP's contracts give SAP the ability to alter those factors. Be precise, because SAP has answered it: changes take effect only upon renewal for existing customers. The acute fear, a bill moving mid term while your workload sits still, is one the vendor has publicly disclaimed.

Take that seriously, then notice what it does not do. It moves the exposure to renewal, which is where you have least leverage and the highest switching cost. Gartner's own advice is the tell: check your contract for price protection, and baseline the current rates from the SAP AI Services List on the Trust Center so you can measure a change rather than take it on trust.

This is not a vendor complaint. Abstract unit pricing is spreading because it decouples the invoice from anything the customer can independently verify. A price you can benchmark is a price you can negotiate. A price in a proprietary unit the vendor defines is a price you cannot benchmark at all.

Ask for the version you can actually get. Not a veto over the table, which no vendor grants one customer over a global price book metric. Ask for the definitions at signature to be term locked and attached as an exhibit, plus an economic equivalence clause: a conversion change that raises the effective cost of an unchanged workload beyond an agreed percentage triggers a price adjustment or a termination right.

The Agent Spend Control Test

Five checks, none of which need a project. You can finish all five this week with people you already employ.

1. Rate or cap, prepaid or postpaid. Find the overage language, then find the exhaustion clause and read what happens when the pool empties. Does the service stop, or does billing continue at list rate? If it defines only a rate, or exhaustion silently converts to list rate, you have no contractual maximum.

2. Halt it live. Have your platform team demonstrate stopping an agent mid execution. Not disabling it for tomorrow, not opening a vendor ticket. If the demonstration turns into an explanation, that is your answer. Expect a different answer for agents you built than for ones you bought, and accept the same one for neither.

3. Threshold alerting you own. Gartner has named the specific shape here: SAP meters AI Units in real time but reports monthly, so you can consume a large share of an annual allocation before the first report lands. Ask whether anyone is alerted at fifty percent, then ask whose monitoring generates it. Vendor side alerting is useful and it is not a control, because it is instrumented by the party whose revenue it constrains.

4. Attribute every action to an owner. Check whether your billing export and consumption API carry an agent identifier and a caller identity at all, or only a total by service and period. Aggregate spend tells you the money went. Attribution tells you which process to fix. Without it, a runaway agent looks exactly like healthy adoption.

5. Baseline the conversion table. Get the current rates in writing, dated, and keep the copy. If the vendor will not attach it as an exhibit, price the risk: model your committed spend against a materially adverse change at renewal and decide whether you would still sign.

What good looks like depends on who runs the agent

Most writing on this, including my own first draft, gives one answer. That is a mistake. Your estate has two halves with different control surfaces, and the remedy for one is unavailable for the other.

Agents you build, calling ERP APIs from your own orchestration layer, are an engineering control problem. Put the budget in your own infrastructure as a quota that fails closed, and give yourself a chokepoint the agent cannot argue with: revoke a credential, close a gateway. It is the same pattern as a breaker in front of a downstream dependency. The novelty is only that nobody thought to put a fuse in front of a licence meter.

Agents you buy embedded in the vendor's cloud are a different problem. There is no orchestration layer of yours for a Joule action or a bundled assist to pass through. Your entire real time control surface is whatever admin toggle the vendor shipped. For that half of the estate, the engineering answer does not exist.

Which is the point, and the reason this piece is mostly about contract language rather than architecture. The more deeply an agent is embedded, the more completely the contract is your circuit breaker. That is uncomfortable, because it puts the control in a document owned by procurement rather than a system owned by engineering. It is still where the control lives. Sort your inventory into those two columns and you will know which problems you can engineer your way out of and which you can only negotiate.

The honest counterargument

Caps fail closed, and an agent that stops mid close because it hit a quota can cost more in disruption than the overage it prevented. True, and an argument for setting the cap correctly and alerting well beneath it. A breaker with a bad threshold is a tuning problem. No breaker is a design problem.

Every CFO then reaches for the cloud precedent: we have run uncapped consumption billing on AWS and Azure for a decade and survived. Three differences compound. Cloud units are open, defined outside the vendor, independently meterable. Agent units are proprietary and vendor convertible, so the same workload can consume a different quantity without anyone changing anything. And cloud workloads run when your engineers deploy them, whereas an agent initiates its own work. There is an honest bonus that argues my side: the hyperscalers shipped hard spending limits because buyers demanded them. That was a procurement outcome, not a gift.

The strongest version is that consumption pricing genuinely aligns cost with value, and buyers demanding ceilings pay a premium for the vendor to carry variance. Also true, and it assumes both parties can see the variance. Where the unit is proprietary, the conversion is set by one side and the measurement is the vendor's, that is not risk transfer. It is an uncapped liability with a friendly name.

Where this lands

Buy the agents. Organisations that sit this out to avoid a licensing problem will lose more than they save.

Ask for three things: a ceiling, an independent stop where the architecture permits one, and a conversion table you can read. You will not always get them, and that is not a reason to walk away. Where the ceiling is refused, buy with the risk priced rather than ignored: a smaller commitment, a shorter term, a gateway quota for the half of the estate where you can build one, and the adverse case written into the business case.

The meter changed. Your controls did not. That gap is being papered into multi year agreements right now, and the fifteen minutes it takes to find the word "cap" in your AI schedule is the highest return work available to you this quarter.

Shubhendu Tripathi is an AI and ERP strategy consultant based in Toronto, and the host of The Integration Layer, a podcast on AI, enterprise systems, and the work of making them fit together. Connect on LinkedIn or reach out at tripathis@qubittron.com.