Resolution as a Service (RaaS) is the pricing and architectural model in which enterprise software is priced on problems solved rather than the number of users who log in. Microsoft’s Windows 365 for Agents announcement confirms, at the infrastructure layer, that the per-seat model does not extend to an agentic workforce. It also reveals, with equal precision, the gap between consumption-based compute pricing and outcome-based resolution pricing, and why that gap is where every seat-based SaaS vendor’s urgency argument now lives.
Read the announcement carefully before drawing the conclusion most vendors will reach.
Microsoft Confirmed the Ghost Seat Thesis at the OS Layer
Windows 365 for Agents is a pool-based, consumption-billed Cloud PC infrastructure product designed specifically for AI agents rather than human users. The billing architecture is the structural tell: license-based pricing for humans, consumption-based pricing for agents. Microsoft has shipped a product that formally bifurcates compute pricing along the human/agent axis.
This is not a hedge. It is a shipping product with explicitly different commercial architecture for the two categories of worker now operating inside enterprise environments.
A Ghost Seat is a software license paid for but no longer actively used because AI has absorbed the underlying workflow. Microsoft is not pretending the per-seat model applies to agents. They built a separate product class because it does not. That is infrastructure-level validation of a thesis the market has been pricing into enterprise software valuations since February 2026, when the SaaSpocalypse erased approximately $1 trillion in enterprise software market capitalization as capital markets concluded that AI agents do not need seats.
Analyst projections can be disputed. A product SKU is harder to dismiss.
Consumption Pricing and Resolution Pricing Are Not the Same Argument
Here is where precision matters, and where most vendors reading this announcement will make an error.
The consumption model Microsoft is deploying charges for agent runtime. An agent can run for 40 minutes, consume Cloud PC resources, and resolve nothing. Microsoft still bills for that runtime. That is compute consumption pricing. It is not outcome-based resolution pricing, and treating them as equivalent is the framing error most likely to lead a seat-based vendor to the wrong conclusion from this announcement.
Results-as-a-Service is the framing gaining traction among enterprise AI vendors. It treats the pricing transition as an outcome billing problem: replace seat invoices with consumption or activity-based invoices, and the transition is complete. Microsoft’s agent compute model sits in that adjacent territory. Pay for what agents actually use rather than for provisioned headcount. The instinct is directionally correct.
Resolution as a Service says the transition is a structural architecture problem, not a billing model problem. The distinction is this: under a consumption model, the customer absorbs utilization risk. An agent that runs without resolving anything is still a billable event. Under a resolution model, the vendor absorbs utilization risk, because billing is indexed to outcomes delivered rather than runtime consumed. That accountability transfer is not incidental. It is the entire argument.
Microsoft priced how long agents run. Resolution as a Service prices what agents accomplish. Every seat-based SaaS vendor sitting between those two models is now carrying a gap that a CFO will eventually name.
For every dollar of AI infrastructure and compute spend, a RaaS vendor must capture at least four dollars of Resolution Value to sustain the 75% gross margins that institutional investors require. That ratio, the 1-to-4 Rule, cannot be managed without knowing what each resolution type actually costs to serve at the resolution level. Consumption billing does not produce that data. Resolution billing requires it.
The Stack Has Fractured, and Your Application Layer Is on the Wrong Side
Consider what the Windows 365 for Agents announcement means structurally for every SaaS vendor running above it.
The compute substrate beneath your application now formally distinguishes between human and agent workloads and prices them on separate commercial architectures. Every seat-based SaaS vendor running on that substrate is now visibly misaligned with its own foundation. The compute layer is priced by consumption. The application layer is priced by headcount. Those two pricing architectures are moving in opposite directions. The infrastructure layer has already acknowledged that agents do not have heads to count. The application layer is still billing as though they do.
Seat-based pricing adoption in enterprise software fell from 21% to 15% of SaaS companies in a single year. Companies clinging to pure per-seat models experienced churn rates 2.3 times higher than those on hybrid or outcome-based billing. Those numbers were established before the infrastructure layer moved. Windows 365 for Agents is not a new force. It is the existing force confirming itself at the substrate level.
The sequence that follows is not speculative. An enterprise customer deploying AI agents on consumption-billed Cloud PC infrastructure while paying a seat-based SaaS vendor a per-headcount license has already lived inside the contradiction. They may not have named it in those terms yet. They will name it at renewal, and they will name it to the application vendor first, not to Microsoft.
The Evidence Base Just Got Harder to Dismiss
The urgency argument for the RaaS transition has rested on pricing theory, market cap data from the SaaSpocalypse, and vendor-level behavioral evidence from the earnings transcripts of the eight major enterprise software companies documented in the research brief. Windows 365 for Agents adds a category of evidence those sources cannot provide: infrastructure-layer formal acknowledgment from the world’s largest enterprise software company that the human/agent billing distinction requires a separate product class.
The SaaSpocalypse was a market verdict. Windows 365 for Agents is an infrastructure verdict. They are pointing at the same structural reality from different directions. The seat-based application layer sitting between them is the last holdout. Analyst projections describe where the market is going. A shipping Microsoft SKU describes where it already is.
The question of what it means institutionally when an infrastructure vendor formally separates human and agent compute into distinct product classes, and what accountability structures that bifurcation creates or eliminates, runs deeper than commercial contract design. The governance dimensions of that architectural decision are examined at middlewayinai.com, where the argument centers on what conditions make accountability for autonomous systems enforceable rather than merely contractual.
Prescription
The immediate intervention: Identify the enterprise accounts in your portfolio where AI agent deployment is already underway on the customer side. Those are the accounts where the infrastructure/application billing gap will surface first. A customer running agents on consumption-billed infrastructure while paying your company a per-seat license has already experienced the contradiction in practice. Start the Phase 1 Revenue Audit there, not at the accounts with the lowest Ghost Seat Rates.
Then test your candidate resolution types against the three Atomic Resolution criteria: verifiable (a problem solved, not attempted), attributable (traceable to your platform’s AI execution rather than a human override or an external process), and finite (a clear endpoint that prevents open-ended agentic loops from consuming unlimited compute under a fixed resolution fee). If you cannot satisfy all three criteria for at least three resolution types in your current product, Phase 2 instrumentation is your immediate priority. Not a repricing conversation.
The full architecture, including the 1-to-4 Rule diagnostic, the High-Fidelity Repository build roadmap, and the Phase 2 instrumentation requirements, is in the RaaS Vendor Transition Playbook at crownpointadvisorygroup.com.
The Socratic question: When your largest enterprise customer’s procurement team realizes that the compute layer beneath your product already runs two separate billing models for two categories of worker, what will they ask about the application layer sitting above it?