You Are Now Buying Software for Agents, Not People

You are no longer buying software mainly for people.

That is the line sitting under a Gartner forecast published on 1 July 2026, and it is the most useful way to read it. Gartner puts up to $234 billion of enterprise application software spending at risk from agentic AI by 2030, roughly 20 per cent of all enterprise application SaaS spend. The mechanism has a name: agentic arbitrage. The trade press is reading it as a vendor problem. For a working professional it is closer to the opposite, because the buying test, the contract and the control surface all change, and all three are things you can act on this month. This piece gives you the test, the clauses and the workflow.

What Gartner actually said

Agentic arbitrage is what happens when an AI agent completes a task across several systems at once, so a person no longer opens each application and clicks through its screens. The agent works through the software's API instead, delivers the outcome directly, and the application itself becomes, in Gartner's word, invisible. George Brocklehurst, a Managing Vice President at Gartner, framed the consequence bluntly: "Agentic systems deliver outcomes directly, bypassing traditional user experience-heavy applications and making the software invisible. This breaks the link between user growth and revenue growth for many enterprise software vendors."

That last clause is the whole story for vendors. Most SaaS is priced per seat, per human user. If the humans stop logging in and an agent does the work through the API, the seat count and the revenue riding on it stop tracking the value delivered. Gartner describes the resulting shake-out as a redefinition of "Saaspocalypse", the disaggregation of the legacy SaaS market, and Brocklehurst was careful to add that this is "less an apocalypse and more of a metamorphosis". The $234 billion is spend exposed to the shift over five years, not revenue that disappears next quarter. Most of your software will not vanish. The live question is what you are paying for, and who captures the value.

Why this is a buyer's story, not a vendor's

Start with the buying test. In CIO's coverage of the release, Brocklehurst's practical framing for buyers is that what now matters is whether an agent can do everything through a system's API that a person can do through its screens, and often more. If it can, the application is a candidate to sit behind an agent. If it cannot, if half the useful actions are locked in the interface with no API behind them, you are buying a tool your agents cannot use, at the exact moment agents are doing more of the work. That is a procurement criterion you can apply this quarter, not a 2030 abstraction.

Then the contract. Gartner's buyer-side advice, as reported by CIO, is unusually concrete: scrutinise the contract as much as you scrutinise the technology. Does the licence permit an autonomous, non-human agent to use the system at all, or does the fine print restrict use to named human users and quietly forbid the pattern you are about to build? What may the agent do once it is inside? Brocklehurst's warning, do not grant autonomy implicitly or unevenly, means deciding on purpose what an agent may do in each system rather than letting it inherit a person's full permissions by default. And the question he says buyers miss: who owns what the system learns from you? When an agent runs your workflows through a vendor's platform, the vendor may be learning your process, and ownership of that learning is negotiable before you sign, expensive after.

The API-parity test, ready to run

The test is simple to state and rarely run: list what your people actually do in a system, then check the vendor's API documentation action by action. An AI assistant does the tedious middle of that well, provided you verify what it returns. Here is a prompt you can reuse on any renewal.

You are assisting a procurement or technology lead at [ORGANISATION] to test whether an AI agent could work through [SYSTEM_NAME] via its API. Use ChatGPT, Claude or equivalent.

Context: [SYSTEM_NAME] is used by [TEAM] for [PRIMARY_WORKFLOWS]. The licence renews on [RENEWAL_DATE] and is currently priced [PER_SEAT_OR_OTHER].

Inputs:
1. The ten actions our people perform most often in this system: [TOP_TEN_ACTIONS]
2. Extracts from the vendor's public API documentation: [API_DOC_EXTRACTS]

Task: assess each action against the documentation and mark it API-COMPLETE (fully achievable through the documented API), PARTIAL (achievable with gaps, name the gap) or UI-ONLY (no documented API path). For each verdict, cite the endpoint or documentation section you relied on. Note anything an autonomous agent would additionally need, such as authentication method, rate limits or audit logging. If the documentation does not answer a point, say NOT CONFIRMED rather than guessing. Output a numbered list, one action per line, verdict first.

The output is not the decision. It is a structured gap list that you verify against the documentation yourself, because models can miss an endpoint that exists or invent one that does not. Verified, it changes what a renewal is worth: a system that is API-complete is agent-ready, and a system that is mostly UI-only is quietly ageing, whatever the roadmap slide says.

The three clauses, and a prompt to find the gaps

Three clauses carry the weight of Gartner's contract advice. The checklist below adds two more that bite later. Run it over any agreement before signature or renewal:

• Agent access. The licence expressly permits autonomous software agents acting on your behalf to access the system. Watch for definitions that limit access to named human individuals.
• Autonomy scope. What an agent may do is defined per system, deliberately, rather than inherited from a human user's full permissions.
• Learning ownership. You retain ownership or control of what the vendor learns from your workflows: usage data, telemetry, and improvements derived from your process.
• Change notice. The vendor must give notice of API changes or deprecations that would break an agent workflow, on a defined timeline.
• Exit. Your data and configuration are exportable through the API on termination, so leaving does not depend on the interface either.

To triage an agreement quickly before it reaches formal review, use this prompt:

You are assisting a procurement, legal or governance professional at [ORGANISATION] to triage a software agreement before legal review. Use ChatGPT, Claude or equivalent. Paste licence and use terms only, not commercially sensitive pricing.

Agreement extract: [LICENCE_AND_ACCEPTABLE_USE_CLAUSES]

Review the extract for three things. 1. Agent access: do the definitions of user, authorised user or access restrict use to named human individuals, and would an autonomous software agent acting on our behalf breach them? 2. Autonomy scope: is there any term governing what an automated integration may do, or is scope silent? 3. Learning ownership: do any clauses give the vendor rights over usage data, telemetry or improvements derived from our workflows?

For each: quote the exact clause text, state whether the agreement is silent, permissive or restrictive, and draft one plain-English negotiation point. Mark anything you cannot support from the extract as UNCERTAIN. This output goes to [ROLE] for review and is not legal advice.

A worked example, end to end

Situation: a governance lead at [ORGANISATION] has a per-seat renewal of [SYSTEMNAME], a case management platform, due on [RENEWALDATE]. The operations team wants an agent to draft routine correspondence using data held in the system, so the renewal is worth more or less depending on whether an agent can actually work through it.

Prompt used: the API-parity prompt above, loaded with the team's ten most common actions and extracts from the vendor's public API documentation.

What came back: seven actions marked API-COMPLETE with endpoints cited, two PARTIAL (bulk document export needs an interface step, and a supervisor approval exists only on screen), one UI-ONLY (scheduled reporting).

What the human verified and decided: the lead checked all three flagged items against the documentation directly. One PARTIAL was wrong, because the export endpoint existed under a different name, which is exactly why the verification step exists. The genuine gaps went into the renewal negotiation as a request for an API roadmap, the agent project was scoped to the seven confirmed actions only, and the five-clause checklist went to the owner of the contract with agent access flagged as the clause to raise before signature. Total effort was about two hours, most of it verification.

Do this Monday

1. Open your contract register or finance system and list the software renewals due in the next two quarters. Pick the two largest.
2. Ask each system's team lead for the ten actions their people perform most often in it. Fifteen minutes per system.
3. Find each vendor's public API documentation and paste both inputs into the API-parity prompt in ChatGPT, Claude or equivalent.
4. Verify every PARTIAL and UI-ONLY finding against the documentation yourself before you rely on it.
5. Send the five-clause checklist to whoever owns each renewal negotiation, with agent access flagged as the clause to raise before signature, not after.
6. If any agent will act on a system that supports critical work, log it in your change and supplier-risk process before it goes live, with least privilege and logging decided at the agent layer.
7. File the results next to the renewal date, and re-run the test at every renewal from now on.

The Australian angle: the controls move with the work

For regulated Australian work there is a governance flip hiding inside this shift. A mature SaaS application is not just features. It is a controlled surface: role-based access, an audit trail, approval steps, a permissions model your risk team has already signed off. When an agent bypasses that surface and acts across systems through APIs, you do not automatically inherit those controls. You inherit the agent's controls, which may be a good deal thinner.

So the practical Australian reading is that an agent acting directly on a core system is a change, not a convenience. Under APRA's CPS 230 an arrangement that supports a critical operation is a material one, and swapping a person-driven, audited application for an agent working through its API is precisely the kind of change that belongs in your change and supplier-risk process, with a tested fallback. It is also a data question. Who owns what the system learns from you is, in Privacy Act terms, a use, disclosure and retention question under APP 6, and an offshore-disclosure question under APP 8 if the agent or its model sits outside Australia. None of this is a reason to avoid agents. It is the reason to keep the control surface deliberate once the application stops being the place the control lived.

The hype check

This is a 2030 forecast, and forecasts of software's death have a poor track record. Gartner's own research is the counterweight: the same firm predicted that more than 40 per cent of agentic AI projects will be cancelled by the end of 2027, mostly on cost, unclear value and weak controls. The $234 billion is spend exposed to arbitrage over five years, not revenue that disappears next quarter, and metamorphosis rather than apocalypse is Gartner's own hedge. The mistake is not ignoring the shift. It is over-rotating, ripping out working systems for agents that cannot yet clear the tests above.

The headline number is a vendor's problem. The sentence underneath it is yours: you are buying software for agents now, so buy, and govern, accordingly.