Weekly Editorial, W35
Workday is the only vendor in this market that puts a number on AI revenue, and it raised that number to roughly $600m. [Corrected 2 September 2026: Workday is the only vendor publishing a standalone AI revenue line. It is not the only vendor attaching a number to AI. Rippling disclosed roughly $5m to $7m a month, about $60m to $84m annualised, from Rippling Data Cloud, which bundles Rippling AI, on 25 June.] The same call showed 5,500 customers using its agents and 200 signed to the meter that charges for them.
Theme 01
Workday has disclosed AI revenue for two quarters running. No competitor discloses it at all. This quarter it also disclosed, for the first time, how few customers actually pay.
On 27 August Workday reported total revenues of $2.649bn, up 12.8%, subscription revenues of $2.471bn, up 13.9%, and a non-GAAP operating margin of 31.1%. It raised full-year subscription guidance to $9.94bn to $9.95bn.
The figures that matter were on the call, not in the release: AI ARR of roughly $600m, more than $100m of new annual contract value from AI products, over a quarter of all new ACV, and more than 5,500 customers using at least one first-party agent, up more than 35% in a quarter.
This is the second such disclosure, not the first, and the distinction matters because it makes the trend readable. On its 21 May call Workday reported agentic AI ARR "approaching $500 million" and more than 4,000 customers using an agent. So the sequence is roughly $500m to $600m in a quarter, and 4,000 to 5,500 agent customers. One caution on comparing the ACV lines: May reported that over 25% of expansion ACV included AI, while August reports that over 25% of new ACV came from AI products. Those are different denominators and should not be read as a like-for-like rise.
What is genuinely new is the payment figure. Against 5,500 customers using the agents, 200 signed Flex Credits in the quarter — the consumption mechanism that charges for them, announced in September 2025. That is about 3.6%. Workday's AI ships to customers through that mechanism with no separate licence required, so the agents are overwhelmingly consumed inside the base subscription while the meter runs on a rounding error.
The company used that gap to explain its own caution. Asked directly whether AI adoption is substitutive rather than incremental, management said it was early and that Flex Credits create a lag, and the finance chief pointed at the 5,500 against the 200 as the reason guidance stayed where it did. The contract book agrees from the other end: the twelve-month backlog grew 14.2%, the total subscription backlog 8.0%, so everything beyond twelve months grew about 5.2%, and forward guidance decelerates to about 11% next year. A quarter of new sales is AI and growth still slows.
The scarcity is the durable point. Paycom has said on the record that it does not charge for its AI assistant. Paylocity named its AI platform twice in a full-year release with no figure. Asure, on Tuesday, answered with a count of functions. Checked against their own 2026 disclosures rather than against our own notes, ADP, Paychex, Paycom, Paylocity, Intuit, SAP, Oracle, Xero and Dayforce all discuss AI at length and none publishes an AI revenue line. Paychex states that AI "is already generating revenue" and attaches no number. Oracle's remaining performance obligations are driven by AI infrastructure contracts, which is a different thing from an AI revenue metric. On that evidence Workday is the only vendor in this set that quantifies AI revenue at all, and it is now on its second quarter of doing so. [Corrected 2 September 2026: Workday is the only vendor publishing a standalone AI revenue line. It is not the only vendor attaching a number to AI. Rippling disclosed roughly $5m to $7m a month, about $60m to $84m annualised, from Rippling Data Cloud, which bundles Rippling AI, on 25 June.] Stated method, because the distinction matters: this was verified against the vendors' own disclosures, not inferred from an absence in our files.
CFO buyer. "AI ARR" needs a definition before it enters a business case: nothing in the disclosure says whether it means a separately licensed product, a bundled capability attributed by deal influence, a consumption meter, or the full value of any contract where AI came up. The question worth standardising now, before other vendors arrive with numbers, is what share of the installed base actually pays for the AI rather than merely uses it. Workday's answer is about one customer in twenty-eight, and it deserves credit for making that answerable at all. Platform vs product. The more durable disclosure is the composition: a vendor whose far contract book grows at a third the rate of its near book is signing shorter commitments, whichever way the AI line reads. Multi-regional regulatory operator. AI ran at roughly a third of new sales in Europe, above the group rate, and the company named open-weight models for cost and sovereignty reasons, which is a procurement argument rather than a technical one. Stated limit. The 200 figure is a quarterly flow, not a cumulative total, so the paying base is larger than 200 by an undisclosed amount. AI ARR carries no published definition and no audit.
Theme 02
On 25 August Rippling shipped an MCP server built on the opposite principle to every other one in this market, and published the argument for why. The design is the competitive claim, so it is worth reading in detail.
Start with what everyone else built. An MCP server is the interface through which an outside AI tool acts inside a vendor's system. The prevailing approach is to take the existing API and expose each operation as a named tool: Workable ships 94 of them, and HiBob, BambooHR, Omni and Lattice follow the same shape. Rippling says it tried that and rejected it: "many companies did exactly that: they wrapped their existing APIs as tools and announced their new MCP server. But when we tested this approach, we quickly realized that the architecture was all wrong."
The reason is cost, not capability. An API is built for a human developer, who reads the surface once at build time and then writes code using a fraction of it. An agent has no build time. It re-derives the solution on every request by reading the tool definitions, so a large catalogue is re-read into the model's context every single time. Their example is a question as simple as "is anyone on my team out of the office today", which forces the agent through managers, employees, leave types and leave balances to find what it needs.
What Rippling shipped instead. The server exposes a single tool, called code. Its description lists the typed codemode.* functions the connected user is authorised to call. The model writes a JavaScript program against those functions, and that program runs inside a fresh Cloudflare Dynamic Worker isolate, chaining the calls and processing intermediate data so those responses never enter the model's context. The number of round trips stays fixed however many operations the task needs. The claim: "the same task that once drowned an agent in context now costs 98% fewer tokens."
The permission model is deliberately unchanged, and that is the part to check first. Executing code sounds like a loosening of control. Rippling's answer is that the isolate holds no credential: "the request leaves the isolate to a host that holds the token, and Rippling enforces the same scopes and field-level permissions that govern every other surface." Their summary is the useful sentence — "the model proposes the work, and Rippling decides what is allowed." Two further limits are stated: rate limiting at the edge, and a hard sixty-second budget on every program. The post also publishes a failure its own evaluation harness caught: the agent wrote correct programs that timed out at roughly 69.5 seconds because "nothing told the agent how much time each function costs". The fix was to publish p95 latency per function.
Read it next to Workday's payment problem and a pattern shows up. Rippling had already, on 6 August, disclosed what running AI cost it: token spend growing 80% month over month, projected by its finance chief at 40% of its entire research-and-development headcount budget, with 10 to 15% of employees driving roughly 60% of spend and one engineer at $50,000 a month. It built a console to meter that. So one vendor cannot get customers onto its agent meter, and another has rebuilt its agent interface around cost and is selling a meter for everybody else's AI. Nobody can price an agent by outcome, because nobody publishes a correctness rate. Until this month nobody had published what consumption costs either.
Platform vs product. The published comparison in this category has been the size and scoping of a tool catalogue, and a vendor has now deleted the catalogue. If one code tool over an authorised function list does the same work at a fraction of the context, tool count stops discriminating between vendors, and the buyer question moves from what can your agent do to what does your agent cost per task. No vendor here has been asked to publish a number on that axis. Multi-regional regulatory operator. Code execution is a different audit surface from a fixed tool list, and this is the sharpest question to put to Rippling. A reviewer can enumerate ninety-four tools and write a control around each; nobody can enumerate the set of programs a model might write. That the isolate is credential-free and the permission check happens at the host is the right shape, and it does not fully answer it. CFO buyer. The cost distribution Rippling published is the transferable finding and it is not about Rippling: roughly one employee in eight drove well over half the spend. Expect that shape, and expect it to stay invisible until someone attributes it to a person and a team. Stated limits. The 98% figure is Rippling's own, on its own internal use case, with no methodology and no independent benchmark. The sixty-second ceiling is a real functional limit. No payroll capability is exposed on the server, and no price is attached to either product.
Theme 03
While the agent numbers were being counted, a dated obligation moved underneath UK payroll software, and it is a calculation problem rather than a policy one.
The government consultation on holiday pay compliance and enforcement closes on 22 September 2026. It sets out how the new Fair Work Agency will enforce statutory holiday pay from 2027: investigating underpayments, requiring repayment of arrears and issuing civil penalties, with employment tribunal claims preserved alongside. It consults on the time limit for holiday pay claims, the level of penalties, whether enforcement should be targeted at lower-paid workers, and the use of rolled-up holiday pay.
Two things make it a software date. Since 6 April 2026, employers have been required to keep "adequate" records for six years evidencing holiday and holiday-pay compliance. A six-year retention duty attached to a derived pay calculation is a data-model obligation, not a filing habit. And rolled-up holiday pay, explicitly in scope, is a calculation method a payroll engine either implements correctly or does not.
Multi-regional regulatory operator. This is the second dated UK obligation this quarter to land on retention and calculation rather than on reporting, and an enforcement body with penalty powers changes what a vendor's compliance claim is worth. The question to put to a UK payroll supplier is specific: can it evidence six years of holiday-pay calculation for a worker whose hours varied, and does it implement rolled-up holiday pay as a supported method rather than a workaround. CFO buyer. The exposure is arrears plus penalties across a six-year window, a materially different number from a single tribunal claim, assessed against records the payroll system either holds or does not. Stated limit. This is a consultation, not final policy, and the record-keeping duty is already in force regardless of how it resolves.
Next