Summary
Every business rushing to deploy AI agents is focused on what the AI itself costs. While that is justified as the era of “cheap AI” fades and “Tokenomics” gains traction, almost no one is asking what the AI does to the cost of everything else it touches. This article looks at that blind spot: the hidden compute and third party software costs generated by agentic use, the pressure agents place on traditional enterprise pricing models, the licensing questions raised by non-human users, the renewed relevance of indirect-use disputes such as SAP v Diageo, and the practical steps businesses should take before deploying agents across their IT estate.
The AI bill nobody budgeted for
As an agent navigates its way around your systems, care should be taken to understand the costs that may arise. This matters most obviously if you are paying for the agent itself on a usage-based model, but the more overlooked exposure is the cost the agent racks up elsewhere. An agent using your own IT systems can drive compute costs up exponentially compared with traditional human users, simply because the volume of interactions and queries it generates is many multiples of what any person could produce.
This is already leading to unexpectedly high charges arising purely from an agent’s use of existing systems, well before anyone has assessed whether the licence even permits that use. The total cost of ownership for agentic deployments therefore cannot stop at the agent’s own token-based subscription or API fee. It needs to extend to every system the agent touches, and to the compute, storage and third party licence costs that increase with agentic query volume rather than headcount.
The assumptions behind enterprise software pricing
Enterprise software pricing structure range from “all you can eat” enterprise-wide licences to consumption-based pricing linked to transactions or services consumed. Many traditional SaaS and on-premise contracts, however, are priced on seats or end-users. Agentic AI puts pressure on all of those pricing structures in different ways.
Under consumption-based pricing, it is a straightforward financial risk. Deploying an agent without usage guardrails can cause costs to spiral, and contracts should be reviewed for any restrictions on agentic use before that happens. Under an enterprise-wide licence, an agent’s usage can shoot up the effective consumption of a system far beyond what was priced in when the fixed annual fee was agreed, handing the customer a level of benefit the vendor never priced for.
Per-seat pricing is where the most exposure is. A single agent accessing a system via an API may be treated, on paper, as one user, even though it can do the work of ten, twenty or one hundred traditional users. This “per-seat leakage” cuts both ways: it can hugely disrupt SaaS vendors’ revenue models, but it also gives vendors a clear incentive to review their terms, monitor usage more closely (and threaten audits and enforcement on their customers), and price agentic use differently from human seat use.
What rights of use does an agent actually have?
Before questions of security or regulatory compliance even arise, there is a prior question: is the business actually allowed to point an agent at a given system? The answer is often less clear than teams assume, and it depends entirely on how the underlying licence is drafted.
- Many software licences already contain explicit restrictions on machine use, whether in an acceptable use policy or as a straightforward prohibition.
- Some licences expressly permit machine use, historically described as robotic process automation, but make clear that it is subject to separate pricing.
- Even licences silent on non-human use often require users to be “named”, or define a user by reference to a “person”, wording that a court could well construe as excluding agentic use altogether.
Where agentic use is expressly prohibited, a conversation with the vendor about a right of use, and the pricing that comes with it, is unavoidable. Where the contractual model is enterprise-wide or consumption-based and agentic use is not prohibited, the risk is comparatively limited. Where pricing is linked to users and the position is genuinely unclear, careful analysis of the exact definitions is needed before an agent goes anywhere near the system.
Even without an outright prohibition, vendors are likely to seek comfort through software audits or SaaS usage monitoring, to confirm that agentic use either isn’t happening at scale or is being paid for. Expect these questions to arise at renewal too, as vendors move to close the gaps in legacy contract terms and bring pricing into line with genuine agentic usage.
The ghost of SAP v Diageo
This is where a decade-old dispute becomes newly relevant. In SAP v Diageo, Diageo implemented a solution allowing multiple employees to input data directly into a system that had previously only been accessible to a limited number of named “super-users”. The court found that this made Diageo liable to pay the relatively high per-user price attributable to those super-users for every employee who ended up accessing the system indirectly.
Many commentators felt the court got the underlying logic wrong, but the case was not appealed and remains the leading authority on indirect use of per-user priced software. It now has direct relevance to the new world of agentic deployment: where an agent is accessed by, or fed data by, multiple end-users but the underlying software is priced per user, vendors have a pre-existing legal argument for treating each of those end-users as chargeable, regardless of how few of them ever touch the licensed system directly. It would not be a surprise to see vendors argue this as agentic deployments scale.
What businesses should be doing now
None of this is an argument against deploying agentic AI; the productivity benefits are real and the direction of travel is clear. But treating the agent’s own subscription fee as the total cost of the deployment is a significant, and increasingly expensive, blind spot. So what should businesses in the midst of agentic rollouts do?
- Model total cost of ownership across every system the agent touches, not just the agent’s own licence or token-based fees, including compute, storage and third-party software consumed indirectly.
- Audit existing software contracts for machine-use restrictions, RPA carve-outs, and user definitions that turn on “named” individuals or “persons” before pointing an agent at the system.
- Implement usage guardrails and monitoring into the deployment itself, so that consumption-based costs are visible and controllable before they spike.
- Flag agentic use proactively at contract renewal, rather than waiting for a vendor audit to raise it first.
Conclusion
Every article on deploying AI systems stresses the importance of guardrails to ensure use is lawful, safe and delivers the intended benefits. On pricing and cost specifically, the same discipline is also true. An agentic AI deployment can quietly reshape compute costs, energy costs and licence fees across an entire IT estate, and businesses that only budget for the agent itself are budgeting for a fraction of the real bill.
The SAP v Diageo case shows that courts have already been willing to enforce per-user pricing against indirect, high-volume access, long before agentic AI existed. Software vendors will not need much encouragement to apply that logic to agents. Getting ahead of it, through contract review, usage guardrails and end-to-end total cost of ownership modelling, is rapidly becoming as important to a responsible AI rollout as the safety and compliance guardrails everyone already expects.
