For twenty years, every enterprise software contract has been a polite fiction. The vendor charged you per seat — per person who logged in, per name in the directory, per licence allocated by your IT team. You paid the per-seat number, accepted that this was how enterprise software worked, and knew the unit didn't really match reality. Half the seats your finance team funded sat dormant for most of the year. The other half were used by people who'd happily have shared a login if procurement let them. Nobody really believed seats and use were the same thing. We all agreed to pretend, and the model held because nobody had a better one.

In the last fortnight, four vendors have stopped pretending.

Salesforce launched Headless 360, with co-founder Parker Harris asking the question out loud: why should you ever log into Salesforce again? Microsoft rolled out Agent Mode across Office. OpenAI shipped Workspace Agents. Google used Cloud Next 2026 to fold Vertex and Agentspace into Gemini Enterprise — pitched as the layer that runs your workflows so the humans don't have to. Aaron Levie at Box has been saying for months that headless is inevitable; this is the fortnight the incumbents agreed with him.

That's a lot of product news for a fortnight, and the substance underneath each launch is the same concession. The companies whose entire revenue model depends on humans paying to log in have started building the product that means humans don't log in. That changes what you're buying. And the contract sitting in your shared drive — the one signed at the last renewal — is the wrong document for the conversation that's coming.

Why per-seat stops working

Per-seat pricing only makes sense if seats describe usage. The moment one human can direct twenty agents that each hit your CRM, your ERP and your support tool on her behalf, the seat stops describing anything. You can keep the unit if you like, and the vendor will too, for a while, because it sells the same number of dashboards as last year. You'll be paying for nothing.

Per-seat also created a perverse incentive that has held SaaS in place for years. Vendors got rewarded for the number of people who logged in, not the work being done — which is why most products optimised for daily active users, why dashboards proliferated, why every workflow got its own button to click. The interface was the product because the licence was for the interface.

A headless world inverts that. The interface becomes decoration; the value sits in the API surface, the data the system holds, the actions it can execute on a user's behalf. I covered the broader shift earlier this year in when the application layer is eaten from below, where agents route around software rather than replace it. Intercom made the same bet from the vendor side a few weeks ago, with its CLI signing up for an account without a human ever touching the form (more on that in agent-ready SaaS). What's new this fortnight is that the incumbents have joined them, in public, with launches their own sales teams now have to defend.

Why the procurement playbook breaks

Most enterprise SaaS contracts are written around concepts that have just become inoperative. They count seats. They specify maximum concurrent users. They cap API calls per user. They penalise the customer for sharing logins. They assume the boundary of usage is a human looking at a screen, and they price the relationship accordingly. Your procurement team didn't write these contracts; they inherited them. That's worth saying out loud, because the next renewal is going to need to fight on ground nobody chose.

Picture a renewal meeting that's coming for a lot of buyers this autumn. Finance and IT are both in the room, and the vendor's account exec is on the call. The vendor's audit shows seat utilisation up 40% year on year. Finance is delighted. IT looks suspicious — the utilisation rise is mostly automated API calls from an agent that ten people on the team have started using. Is that one seat or ten? Is it covered by the existing API entitlement, or is it overage? Who's liable if the agent does something it shouldn't with the data? The standard contract has nothing useful to say on any of those questions, and the vendor is about to suggest a new schedule. That's the position most buyers will be in.

The vendor's first instinct, when you next sit down to renegotiate, will be to charge you per agent, per token, per API call, per outcome, or whatever unit the spot-rate market favours that quarter. The vendor will write the new schedule before you do. That's the leverage problem.

There's a quieter problem underneath that one. Most procurement teams haven't really renegotiated a SaaS contract for the agent era yet, because the renewals so far have been near-identical to the originals with the prices adjusted. The vendor sent the same redlines. The buyer ticked the same boxes. The clauses that defined what a "user" is, what a "session" is, what "concurrent" means — those were inherited from the original contract and never updated. They describe a world that has now ended.

What to actually do

If you're a buyer with a renewal due in the next twelve months, here's the list.

  1. Read your current contract for "user" and "seat" definitions — and mark every adjacent clause. It isn't just the user/seat clause that breaks. Audit rights, overage treatment, API-call entitlement, liability for actions taken by automated callers, data-access scope, service levels on API uptime, and any "no automated access" provision were all written for a world where seats and humans corresponded. Mark each one. Each is contested ground at your next renewal.
  2. Ask for the agent pricing schedule now, before you need it. Every major vendor either has one or is drafting one. You'll want to read theirs at your leisure, not at renewal under deadline pressure. The first generation of these schedules will be vendor-favourable and full of language about "consumption units" that nobody has yet defined consistently — better to scrutinise that on your own clock than under a redline timer.
  3. Add agent-readiness criteria to your next RFP. Not "does the vendor have an MCP server" — every vendor will tick that box. The questions worth asking are about authentication for non-human callers, error message structure, audit trails when an agent acts on a user's behalf, how the vendor handles a single user running twenty parallel sessions, who carries liability when an agent acts on bad input, what API uptime guarantees are on offer, and whether the data-access scope is clear enough to put into a DPIA. None of these are nice-to-haves; they're the new procurement basics.
  4. Decide which workflows you actually want behind an agent. Not every workflow benefits from being headless. The conversation with a customer-success manager isn't better with a layer of intermediation. A finance approval that needs a human on the hook needs an interface. Some of your premium-tier value will turn out to be decoration the agent routes around; some will turn out to be load-bearing. Knowing which is which, before the vendor tells you, saves the negotiation.
  5. Pre-empt the licence true-up. If your current contract counts seats and you've handed those seats to agents over the next twelve months, the vendor's audit team will find it. Better to renegotiate the unit while the contract is still being honoured than to discover the cost when year-end reconciliation lands.

What "agent-readiness" should mean in your RFP

"Agent-ready" is about to do for SaaS RFPs what "cloud-ready" did for IT in 2012 — it'll mean everything and therefore nothing, unless you sharpen it on the way in. Here's a narrow definition worth using: a product is agent-ready when an off-the-shelf agent, given the public API and docs, can complete one of your common end-to-end workflows without a human helping it parse an error or guess an endpoint. Anything else is a marketing claim.

A couple of these aren't fully settled yet. Authentication for non-human callers, in particular, is unclear — there isn't a settled industry standard, and I'd be wary of any vendor claiming there is. The questions worth asking are still the same. Are errors machine-readable? Can authentication work without a browser redirect? Does the product expose telemetry that lets you see what the agent did and why? Is the pricing schedule legible when a single user runs ten parallel sessions? Who's liable if the agent does something with your data that it shouldn't? What's the SLA on API availability when your workflows depend on it? These aren't exotic concerns; they're the basics, and most vendors will fail at least one of them today. The point of asking now is to discover which ones, before you sign.

The window that closes

The seat licence was a useful fiction, held in place for two decades because nobody had a reason to challenge it. The vendors have just torn up their side. Whether your finance team and your procurement function tear up theirs in time to negotiate from a position of strength — or whether they wait to be told what the new unit is — will decide who sets the price of the next decade of enterprise software.