The Service Layer

April 19th, 2026

What happens when your software gets so good at a customer's job that it stops being software? The agent-native model is quietly becoming something the industry has never seen: a services business with software economics.


I want you to think about a consulting firm that has worked with the same client for a year.

They know the client's terminology. They know which stakeholders actually make decisions and which ones just attend meetings. They know the legacy systems, the undocumented workarounds, the unwritten rules. They have accumulated so much institutional context that replacing them would take a new firm months just to get back to baseline.

Now ask yourself: is that firm selling tools, or is it selling outcomes?

Nobody would call McKinsey a software company. But the reason their client relationships are sticky is identical to what I described in The Retention Layer: accumulated, customer-specific knowledge that makes switching painful. The difference is that McKinsey builds that knowledge with human consultants billing $500 an hour. An ACP-powered agent builds it autonomously, continuously, and for a few dollars a day.

Which raises an uncomfortable question for anyone building agent-native software: if your agent has been evolving against a customer's operations for twelve months, is it still software they use? Or has it become a worker that performs their operations?

I think it has become the latter, I think the founders who recognize this fastest will build the most valuable companies of the next decade.

The inversion nobody expected

For twenty-five years, enterprise software ran on a simple deal. The vendor provides the tool. The customer provides the labor. SaaS made the tool cheaper and faster to deploy, but it never changed the fundamental division: the customer bought access, the customer did the work.

AI agents invert this. The agent does not assist an employee in completing a task. The agent completes the task. The employee, if involved at all, reviews the output.

Foundation Capital named this inversion Service as Software, the deliberate reversal of Software as a Service. Their framing is precise: in SaaS, the vendor sells capability and the customer achieves the outcome. In Service as Software, the vendor sells the outcome and the software achieves it. The deliverable changes from access to results.

The numbers behind this are worth sitting with for a moment. The global SaaS market is roughly $300 billion. The global services market is $4.6 trillion. When software can deliver services rather than merely enable them, the addressable market expands by more than ten times. Salesforce generates $35 billion in CRM revenue. Global companies spend $1.1 trillion on sales and marketing salaries. The opportunity for AI that performs sales work, rather than organizing sales data, is a different universe of scale.

The SaaS market is $300 billion. The services market is $4.6 trillion. When software becomes the worker instead of the tool, the addressable market does not grow. It transforms.

The dilemma that eats incumbents

Here is the part that gets uncomfortable for the companies currently dominating enterprise software.

TSIA calls it the cannibalization dilemma, and the logic is brutal. Seat-based pricing assumes more employees using software equals more revenue. AI agents reduce the number of employees needed. When AI makes one person as productive as five, the customer does not need five seats. Revenue per customer drops even as the value delivered increases. The vendor's success becomes its own revenue problem.

In February 2026, approximately $285 billion in market value vanished from software stocks in a single trading session after Anthropic released enterprise workflow automation capabilities. Investors recognized what the industry had been slow to admit: when one employee equipped with AI agents can accomplish the work of five, the per-seat model collapses.

The incumbents are stuck, they cannot ignore agents (their customers are demanding them) and they cannot fully embrace them (doing so cannibalizes their core revenue). They also cannot easily shift to outcome-based pricing because their organizations are built around the seat model: the sales compensation, the customer success teams, the professional services divisions, the financial models. Every layer of the business assumes per-seat economics.

Agent-native companies have none of this baggage. They were born into outcome-based pricing. They have no seats to cannibalize. This structural advantage is more durable than any feature advantage could be.

Four stages, one destination

The transition from software vendor to service provider is not binary. It occurs along a spectrum, and where you sit on that spectrum determines everything about your business.

Stage 1
Tool Provider
Sell access to software. Customer operates it, owns outcomes. Classical SaaS. Pricing is per seat. Most enterprise software lives here today.
Stage 2
Augmented Tool Provider
Embed AI that assists employees. Copilots, auto-suggestions, intelligent defaults. Customer still does the work. This is where Salesforce, Microsoft, and ServiceNow are racing.
Stage 3
Managed Outcome Provider
Deploy agents that execute complete workflows. Customer defines objectives and reviews results but does not perform the work. This is where agent-native startups are.
Stage 4
Service Provider, Software Economics
Full responsibility for delivering outcomes. Customer pays for results. Vendor operates as a service provider but retains software margins because the workers are agents, not humans.

The transition from Stage 3 to Stage 4 is where I think the most interesting things happen. And it is the transition that most agent-native founders are not yet thinking about, even though their products are already making it inevitable.

The retention layer was the service layer all along

This is the realization that changed how I think about everything I wrote in The Retention Layer.

The mechanisms I described for creating customer-specific retention (prompt evolution, tool evolution, memory accumulation) are not just retention tools. Look at them from the perspective of service delivery and they describe something else entirely: a service provider that is getting better at serving this specific client.

The self-evolution loop is not just optimizing software performance. It is building the same kind of client-specific expertise that defines high-value consulting relationships. Except it is doing it continuously, systematically, and at near-zero marginal cost.

This reframing matters because it changes what you are building toward. If you think the retention layer is a defensive feature, you build it as an afterthought. If you recognize it as the service delivery engine, you build it as the core of the business from day one.

Services at software margins

Traditional agencies and consultancies sell human labor organized around client outcomes. Their margins are structurally constrained by the cost of that labor. Revenue scales linearly with headcount. Gross margins sit between 25 and 40 percent. Growth requires hiring, which requires recruiting, training, managing, and retaining people.

The ACP-powered service provider operates in a different economic regime. The workers are agents. The marginal cost of deploying one to a new customer is API inference, not salary plus benefits plus office space plus management overhead. Gross margins can approach 70 to 85 percent while delivering service-level value.

This has never existed before, we have had services businesses (high value, low margins, hard to scale) and we have had software businesses (high margins, scalable, but selling tools not outcomes). We have never had a business that delivers outcomes at software margins. The constraint on growth is not labor availability. It is the quality of the evolution loop and the reliability of the evaluation function.

Think about what this means for the consulting compression. Deloitte, Accenture, McKinsey, and their peers collectively generate hundreds of billions in annual revenue. A significant share comes from customization: making generic software work for specific clients. ACP automates customization through self-evolution. The "implementation consultant" is the SEPL loop. The "configuration specialist" is prompt evolution. The "optimization advisor" is tool evolution.

When these functions run at software margins, the consulting layer does not disappear entirely. Strategic advisory, organizational change management, and novel problem-solving remain human domains. But the large-scale implementation and optimization work that generates the bulk of consulting revenue is precisely the work that self-evolving agents are designed to perform.

You own the outcome now

There is a legal dimension to this transition that most founders are ignoring, and it will catch people off guard.

Mayer Brown published an analysis in February 2026 showing that contracts for agentic AI are already moving from SaaS terms to structures borrowed from business process outsourcing. They identified six areas where standard SaaS contracts fail: service definitions must describe outcomes rather than platform access. Warranties must cover operational performance, not just uptime. SLAs must measure results, not availability. Indemnification must cover the agent's autonomous actions. Governance must define delegation of authority. Data ownership must address knowledge generated through operation.

The legal profession is telling us, in the most concrete terms possible, that agentic AI vendors are becoming service providers. The contract structures follow the economic reality. TSIA captures it in a single sentence that I keep coming back to: "If your AI drives the decision, you own the outcome."

In the SaaS era, vendors could argue that customers owned outcomes because humans made the decisions. The software provided data; the human bore responsibility for what they did with it. When an agent autonomously makes a decision and executes an action, that separation dissolves. If the agent produces the wrong forecast, misclassifies a risk, or drives the wrong workflow, it is the vendor's system that failed.

When your software makes the decision and executes the action, you are not selling a tool. You are selling a result. And you are accountable for it whether your contract says so or not.

This is where ACP's architecture becomes essential for reasons beyond retention. The version lineage is not just a switching-cost mechanism. It is the accountability infrastructure that outcome-based service delivery requires. When a customer asks "why did the agent do this?", the lineage provides provenance. When a regulator asks "how has this system's behavior changed?", the evolution history provides an audit trail. You cannot charge for outcomes without proving you delivered them reliably.

Pricing the future

Gartner predicts that by 2030, at least 40 percent of enterprise SaaS spend will shift toward usage, agent, or outcome-based pricing. The early movers are already experimenting. HubSpot charges $0.50 per customer support resolution. Intercom has shifted AI support to outcome-based pricing. Salesforce is introducing agent-based pricing alongside traditional seats.

For founders building on ACP, I think three models are worth considering. Per-outcome pricing is the purest alignment: charge when a measurable result is achieved. Hybrid base-plus-outcome gives revenue stability while preserving incentive alignment. Managed capacity pricing, where you provide a specified capacity of agent-delivered work like a fractional hire, is the easiest sell to conservative procurement teams.

The key insight is that the ACP retention layer enables all three because it already provides the measurement infrastructure (execution traces), the accountability infrastructure (version lineage), and the performance proof (evolution history) that outcome-based pricing demands.

The graduation

I started writing The Retention Layer because I saw a defensibility gap in agent-native businesses. What I did not expect was that the solution to the defensibility problem would turn out to also be the solution to a much larger strategic question: how do you build a services business that scales like software?

The answer is that you do not set out to build one. You build a self-evolving agent that gets better at each customer's operations over time. The retention follows naturally. And then one day you realize the agent is not software the customer uses. It is a worker that performs their operations. The company providing that agent is not a software vendor. It is a service provider.

The last wave built software companies. This wave builds something that has never existed before: service companies with the economics of software, the adaptability of boutique consultancies, and a scale ceiling that neither has ever achieved.

I am publishing a full paper on the service layer that goes deeper into the competitive dynamics, the pricing models, and the accountability architecture. But the core insight is worth stating plainly: the retention layer and the service layer are the same thing, viewed from different angles. If you have built one, you have already built the other.

The only question is whether you recognize it in time.

The retention layer is the service layer. The company that has already built one has, without additional architectural work, built the foundation for a services business with software economics.

ACP Working Paper Series, April 2026