Software is for Machines. Humans want Outcomes.

In June 1999, when Marc Benioff left Oracle and registered Salesforce.com in a San Francisco apartment, the company’s pitch was printed on t-shirts for its first employees: “No Software”.

It was not a product claim. It was a billing claim. You would not buy a perpetual license on a CD-ROM that your IT department would install on servers you maintain. You would pay a recurring fee, per user, per month, and the thing would simply be there when you logged in, running on someone else’s machines, someone else’s data centers, someone else’s responsibility. The word they chose for this category — and that stuck so completely it defined the entire enterprise software era that followed — was Software-as-a-Service.

Twenty-five years later the companies in this category generated roughly $350 billion in combined revenue in 2024, with hundreds of publicly traded entities whose entire valuation premise depends on that word “Service.” But if you examine what these products actually delivered to the people who paid for them, from the first Salesforce deployment through today’s enterprise stacks, the word was doing almost no actual work.

A service properly understood involves someone doing something for you.

A caterer at an event is a service provider. You do not buy the caterer’s stoves, their recipes, their knife set, and their prep calendar and then consider the problem solved because you have access to instruments. The caterer brings you hot food at a specific time, set on a table, served to guests, and you pay a price that covers a result, not an inventory of equipment. The catering company does not invoice you per chef login. They invoice you based on how many people they fed and how.

This is the difference between selling outcomes and selling access. Every traditional SaaS product — Salesforce, Workday, ServiceNow, HubSpot, Jira, Datadog, Slack, Snowflake — sold access, not the thing that access was supposedly meant to produce.

The CRM does not find qualified leads. The analytics dashboard does not produce a quarterly forecast. And the ticketing system does not resolve escalations or close the deal. All of these products sit passively between screens and human wrists, waiting for someone with a coffee mug and muscle memory to move a cursor from one field to the next. The relationship between the tool’s capability and the outcome the company needed is bridged entirely by human labor — wrists, eyes, attention, institutional memory, and the accumulated institutional knowledge of which buttons produce what when clicked in what order. The software sits in the middle and calls it service.

Benioff understood this, and he could not have built a $300 billion company if he had actually committed to delivering outcomes. Outcomes are heterogeneous, hard to price uniformly, and impossible to guarantee at scale. What is easy to price at scale is a seat. What is easy to sell is an interface a human can learn. What is easy to defend is the fact that your organization has spent three years getting everyone accustomed to exactly where the buttons live and that switching would cost your team six months of ramp-up time and relearning. The moat was never the software. It was the friction required to unlearn it.

The enterprise stack was never integrated. The employee was the integration layer.

The first crack in this architecture appeared well before the AI era, and it came from a direction almost nobody in enterprise software was watching at the time.

In 2011, three developers — Wade Foster, Bryan Helmig, and Mike Knoop — were running a software consulting firm in Missouri called Coco Systems and found themselves building the same glue code for every client: connect the CRM to the spreadsheet, the spreadsheet to the email tool, the email tool to the accounting platform. The software these companies had purchased did not speak to each other. Each one was an island — not by accident, but by design, because each was optimized for a different human workflow optimized by a different product team in a different building. The developers built a drag-and-drop connector that let a non-engineer link App A to App B without writing anything. When a new row appears in Google Sheets, send a message to Slack. When a lead converts in HubSpot, create a ticket in Jira. When a payment clears in Stripe, update the ledger in Xero.

They spun it out as Zapier. It reached an estimated $140 million in ARR by 2021, valued at approximately $5 billion.

But Zapier should never have been a company.

Its entire existence was proof of failure — proof that the SaaS ecosystem, despite twenty years of maturation and billions in venture investment, had not produced interoperable software. Instead, it produced islands, and then paid an intermediary to build bridges between islands that were never designed to connect. But this was not a bug in the SaaS model. It was the model. Each vendor competed on the comprehensiveness of its own feature set, not the quality of its connections to other products. The more features you shipped, the more sticky your product became, because the more of the customer’s work lived inside your walls. Integration was an afterthought — a checkbox in the product roadmap, a paragraph in the FAQ, a promise that an API existed “for developers.”

And when the APIs did arrive, they revealed the architecture problem beneath the UI polish. Current enterprise tools were built for a human being who looks at a screen. Their database schemas reflect what a person needs to see in a paginated table with sortable columns. When a company demanded automation capabilities, the vendor would bolt on an API — usually six to eighteen months behind the UI feature — that translated screen interactions into HTTP endpoints. MCP adapters, published in 2024, are a third wave of this same pattern: a semantic interpretation layer placed on top of an API that was placed on top of a UI that was placed on top of a database schema designed for a person looking at a monitor. Each layer distances the machine further from the data.

Agents do not click, page through results, or need visual hierarchies with breadcrumbs and sidebar navigation. They call endpoints. They transmit structured input and expect structured output. They evaluate the quality of that output against a specification, and if the output fails the specification, they do not file a support ticket. They route to a different endpoint. And so, what was a moat — a learned human interface — becomes a liability when the human is no longer the one using it.

The immediate economic consequence of this is simple. The entity that captures margin is the one closest to the outcome. Not the one manufacturing the hammer. The one hitting the nail.

That’s because a per-seat license has no analog when the buyer is a process. You do not buy Salesforce seats for an agent. You define an outcome, the agent evaluates which tool can deliver it at the required quality and cost, and it routes the work. The vendor does not know who the buyer is because there is no one to know. The buyer is quite simply a specification.

In the old model, a company paid for the CRM, the analytics suite, the communications platform, the ticketing system, the project management tool, the BI dashboard — and then paid humans to operate all six pieces of software and manually stitch their outputs together into something resembling a completed job. You were funding both the tools and the bridges. Zapier made money on the seams between tools because those seams existed by design, not accident.

In the new model, you pay an agent to produce a result, and the agent decides or owns which endpoints to invoke, in what order, at what cost. The tools become line items in a capability specification, not independent purchase decisions. The price the agent pays is the cost of the micro-outcome: a sent message, a verified lead, a completed reconciliation entry. The economic spread is the difference between what you paid the agent for the finished macro-outcome and what the agent paid the endpoint vendors for the components.

This is the distribution inversion. In SaaS, the vendor sold directly to the human user. Distribution meant product-led growth, free trials, viral workspace invites, and the slow accumulation of habitual users who would eventually convince their company’s procurement department to upgrade. In the new outcome-oriented model — the model that arrives when the primary buyer of enterprise software is a process, not a person — distribution is invisible because it happens in routing tables, not onboarding flows. Your agent evaluates a contract specification. If the specification matches the requirement, it routes. If not, it does not.

In SaaS, distribution happened in the browser. In agent economics, distribution happens in the routing table.

The SaaS vendor whose primary defensibility is that humans are accustomed to its interface does not survive this transition. The moat evaporates because the user it was built to trap is gone. This is why incumbents are bolting “AI” onto their existing products so frantically — adding chat interfaces, co-pilot features, automated summaries, dashboard widgets that generate text. They are adding AI to the UI layer because the UI is the layer they can reach.

However, they are all solving for the wrong entity. The buyer that matters is not looking at the screen.

Exceptional Tools

Not every tool dies under agent economics. The separation is clean and the criterion is unforgiving.

If your moat is that humans have learned your interface, you are dead when the human leaves.

If your moat is data or proprietary knowledge that cannot be reconstructed from public information, you survive — but your interface must be rebuilt for machine consumption, and if you do not rebuild it, an agent-native competitor will encode your data into a better behavior contract and bypass you entirely.

Bloomberg is the case study, and it proves both halves of the rule. The Bloomberg Terminal’s interface, famously baroque, survived decades of competitive onslaught not because its UI was loved — it was feared first, then tolerated, then relied upon out of necessity. It survived because fifty years of proprietary data ingestion — real-time quotes, institutional transaction flow, regulatory filings, analyst estimates, supply chain mappings, commodity pricing feeds, corporate action records — created a data asset that no API call to a public source could replicate. The Bloomberg terminal guarantees a behavior contract about financial information that nobody else can guarantee: specific data fields in specific formats with specific latency bounds. That contract is the moat, not the keyboard.

A general-purpose agent will need a Bloomberg-class data source to function in enterprise contexts where financial intelligence is part of the decision chain. It will not care about the keyboard. It will care that the data contract holds under load. And if Bloomberg does not offer an agent-native version of that contract — a clean, machine-specification API with guaranteed latency, output shape, and error handling — someone else will take the public portion of Bloomberg’s data and wrap it in a contract that is good enough for the agent to route through, and Bloomberg will lose its most valuable customer: the agent fleet.

Deep industry-specific tools face the same fork. A healthcare claims processing system with fifteen years of adjudication rules and edge case handling has a data moat. An agent needs that data to function. If the vendor rebuilds on a machine-specification architecture, it becomes an irreplaceable node in the agent network. If it does not, it becomes a legacy UI that the agent layer will replicate from its interaction data and bypass.

The deeper architectural consequence is the one nobody in the current enterprise build-out is planning for: the shift from building products to publishing specifications.

A SaaS product, at its core, is a user interface. The backend exists to serve the frontend. Even SaaS companies that claim to be “API-first” are, in practice, UI-first with an API exposed. You can see it in their release notes: the dashboard feature ships first, the webhook ships later, the rate limit ships when someone complains. The product team is organized around screens, and the engineering resources follow the screens.

An agent-native product is a behaviour contract. It has no interface by default because no one is looking at it. What it has is a specification: the shape of input it accepts, the shape of output it produces, the latency envelope it guarantees, the cost per invocation, the failure modes and how it handles them. The engineering effort focuses on keeping the specification true under conditions the vendor cannot predict. The “user experience” is whether the contract was fulfilled, not whether the dashboard was beautiful.

This is a fundamentally different discipline. It inverts the resource allocation of a typical enterprise software company. The dashboard team becomes the optional team. The specification engineering team — the people who define, test, and guarantee the behavior contract — becomes the core. Quality assurance shifts from “does the screen render correctly on Chrome, Safari, and Safari iOS” to “does the contract hold under 10,000 concurrent invocations with sub-200-millisecond latency.”

Highly specialised and complex tools, especially if coupled with data mining and refinement capabilities, will still have a moat.

A New Kind of Company: Do Many Things Well

The bundling consequence follows directly.

In SaaS, bundling was considered dangerous — the old orthodoxy of “build one thing, do it well, do not dilute your product by trying to be everything” was correct for a world where every product needed to earn a human’s limited attention. An agent does not have attention. It has coordination constraints. An agent that can invoke only one tool is a calculator. An agent that can invoke thirty tools designed to work together, with consistent contract specifications and known inter-tool failure modes, is an organism.

So the companies that will win this market will not be the ones building the single best tool. They will be the ones building a deep capability stack — many tools, each mediocre if offered independently on a per-seat license, but defensible when woven into an integrated specification that an orchestration layer can rely on. The individual tools would be bad SaaS businesses standing alone. Together, they form a moat: not of user familiarity, but of coordination reliability.

Vertical integration, dismissed as bloated and unfocused in the SaaS era, becomes rational again. Not because it is efficient to vertically integrated in a static sense. Because the orchestration quality depends on controlling the interfaces between tools, not just the tools themselves. You cannot optimize the data flow between two tools you do not own when neither vendor will share their performance telemetry or guarantee their failure modes. The orchestrator that owns the stack sees the complete signal chain and can optimize it end to end. The orchestrator that depends on third-party APIs is blind to what happens inside the vendor’s boundary.

When the buyer is a process and the product is a specification and the tools are coordinated rather than chosen, the economics compress into a form that SaaS companies have never needed to model because it did not exist.

The more tools an Agent Service Provider has, the faster, more effective and productive the Agent will be, resulting in superior outcomes for the client.

The human does not disappear. The human moves upstream, from operator to spec-writer and auditor.

The interaction shifts from “click the button that generates a report” to “deliver a qualified candidate shortlist by Friday that meets these constraints,” with the feedback loop being whether the candidates met the actual criteria, not whether the report was formatted correctly. Training disappears. Onboarding disappears. Documentation disappears. You do not learn to use an agent product the way you learned Salesforce. You learn to state your requirements more precisely — which is to say, you learn to think more clearly about what you actually need. The software handles execution, the human provides intent.

This is where the data flywheel appears: every agent invocation generates structured telemetry about what was asked, what was returned, how long it took, whether it matched the spec, what the cost was, and whether the agent routed to a different vendor on the next cycle. This telemetry trains the orchestration layer to make better routing decisions over time. It trains the vendor agents to handle edge cases they have not seen before. It generates synthetic data from failure modes, which the system can use to improve before the next real invocation. The flywheel is: more invocations produce more telemetry, which improves routing, which produces better outcomes at lower cost, which attracts more volume, which generates more telemetry. Each cycle compounds.

Incumbent SaaS vendors with their UI-first architectures cannot participate in this flywheel. They measure clicks, page views, time on screen, feature adoption rates. These are signals about human behavior inside an interface. They are not signals about whether the vendor delivered the outcome the buyer needed. They are measuring the wrong entity and the wrong metric. The vendor that cannot see agent telemetry is operating blind in the new market.

The naming reveals the territory. Software-as-a-Service was never service. It was a billing model that dressed itself in a word it did not earn for twenty-five years. The correction is not a rename, but a market structure that does not exist yet, and the companies that are building toward it look nothing like the companies that built the SaaS era.

They have no onboarding flow. They have no pricing page with per-seat tiers and enterprise contact forms. They have a specification endpoint and a latency guarantee. They bundle internally because composition is the product, and the orchestrator that depends on them is the customer, not the human at the keyboard. They look like infrastructure companies that happen to sell outcomes, or outcome companies that happen to own infrastructure. Both descriptions are correct because the line between infrastructure and outcome does not hold when the buyer is a process.

The companies that internalize this will look wrong to SaaS investors, to SaaS analysts, to SaaS founders, to everyone whose mental model of enterprise software was formed in the era of per-seat licensing, product-led growth, and dashboards as products. They will look wrong until they become the market.

We called it a service because it was billed like one, and we mistook the billing model for the substance. We were buying tools and calling it service. The agents will not make that mistake.