What Happens to SaaS

For most of the SaaS era, the application was the natural unit of enterprise software. It owned a data model. It contained business logic. It executed workflows. It provided the interface. It gathered usage. It created switching costs.

And over time, it became the place where a category of work happened. CRM. Sales engagement. Conversation intelligence. Customer success. Support. Marketing automation. Forecasting. Each category emerged around a software boundary that made technical and economic sense.

AI begins to loosen that bundle. A capability such as Deal Assessment may need CRM data, customer conversations, email, product usage, qualification logic, historical outcomes and management judgement. The work no longer fits neatly inside one application.

At the same time, the user may not need to open the application at all. The capability can appear in Slack, Teams, CRM, a briefing, a chat interface or somewhere entirely new. That does not mean SaaS disappears.

It means we need to ask a more precise question: Which parts of the SaaS bundle remain durable when intelligence and work can operate across applications?

The SaaS bundle

A traditional SaaS application combines several forms of value. First, it stores data. Salesforce stores accounts, contacts and opportunities. Zendesk stores tickets. Gainsight stores customer context. Outreach stores sequences and activity.

Second, it contains business logic. Stages. Rules. Scoring. Permissions. Objects. Automations. Third, it executes workflow. Move this opportunity. Send this sequence. Escalate this ticket. Assign this task.

Fourth, it owns an interface. A salesperson logs into CRM. A manager opens forecasting. A CSM opens customer success software. Fifth, it increasingly owns intelligence. Scoring. Recommendations. Summaries. Forecasting. Insights.

The economic power of SaaS came partly from bundling these things together. The more work happened inside the application, the more data it accumulated. The more data it accumulated, the more useful the workflow became. The more useful the workflow became, the harder the application was to replace. This created a strong reinforcing loop.

AI changes several parts of that loop at once.

Data does not disappear

The easiest mistake is to assume AI makes systems of record obsolete. It does not. Agents still need authoritative information. Accounts need identifiers. Contracts need to be stored somewhere. Payments need to settle. Support tickets need operational ownership. Permissions need enforcement. Transactions need consistency.

The more intelligent software becomes, the more important reliable underlying data may become. What changes is the relationship between the data and the application consuming it.

Historically, if Salesforce owned the opportunity record, it was natural for more sales workflow to remain inside Salesforce. An AI-native capability can treat Salesforce as one source within a broader commercial state.

The record remains important. The application boundary becomes less important. This is a subtle but consequential distinction. The system of record can remain durable while losing some control over the surrounding workflow and interface.

Workflow becomes more portable

SaaS applications also gained power by owning workflows. A sequence belonged inside sales engagement. A renewal workflow belonged inside customer success. A forecast process belonged inside forecasting software. This was natural because workflow logic needed to be configured inside a system that understood the relevant objects and provided the user interface.

AI makes workflow more portable. An agent can use multiple systems. A Skill can define a method independently of the application. A capability can coordinate actions across CRM, email, calendar, collaboration software and internal tools.

The workflow no longer needs to live entirely where the data lives. That changes application leverage. If workflow can move across systems, the application owning one step of the process may have less power over the whole process. The value begins to move upward toward the layer coordinating the capability.

Business logic begins to separate from application logic

This may be even more important. Traditional applications contain business logic because the software needs to know how the process should behave. A CRM has stage definitions. A forecasting platform has risk logic. A customer-success platform has health logic. A sales-engagement platform has sequencing logic.

But company-specific judgement often does not belong naturally to any of them. What constitutes a strong champion? Which accounts should the company prioritise? How should enterprise opportunities be qualified? When does a customer become genuinely at risk? Those questions span systems.

AI-native Memory and Skills give the organisation another place to encode that logic. Now the company can separate: application logic from organisational logic.

That is a major architectural change. The CRM still needs to understand opportunities. But the company’s interpretation of a healthy opportunity does not necessarily need to live inside CRM configuration.

The operating layer can maintain that judgement and apply it wherever relevant. This makes organisational logic more portable. It also makes it more reusable.

Intelligence becomes less attached to the application

The current response from SaaS vendors is understandable. Add AI. Every application gets a copilot. Every workflow gets a summary. Every interface gets a chat box.

This can create substantial value. But it also raises an uncomfortable question. Why should intelligence remain attached to each application?

A salesperson does not need one AI that understands CRM, another that understands calls, another that understands email and another that understands prospecting. The salesperson needs an understanding of the account.

A manager does not need separate intelligence inside every system. They need to know what changed and what deserves attention. The more capable models become, the less natural it feels for each application to maintain an isolated intelligence layer over its own data.

The user’s problem crosses the applications. Intelligence increasingly needs to do the same. This does not mean application-native AI disappears. Some tasks are highly domain-specific and benefit from local context.

But the strategic question changes: Is the valuable intelligence attached to the software category, or to the organisation’s broader operating context?

In many GTM situations, I suspect the latter becomes more important.

The interface loses some monopoly power

The SaaS application has historically owned the user’s attention because the user needed to enter the application to access its functionality. AI changes this relationship too.

If a capability can be invoked through chat, delivered in Slack, surfaced inside CRM or embedded into a meeting workflow, the underlying software does not necessarily own the interface. A user might interact with five systems in a day while consciously opening only two. Agents can operate the rest.

This changes one of the most important forms of software distribution. Historically: own the workflow → own the interface → own the user. AI creates another possibility: own the operating context → orchestrate the workflow → surface the capability wherever the user already is.

Interface still matters. Great UX still matters. Trust still matters. But the dominant surface may separate from the application performing or storing parts of the work.

That creates pressure on software whose primary defensibility came from owning the user’s daily navigation.

Some applications become tools

Consider email. An agent may read email. Draft email. Send email. The email system remains essential infrastructure. But the user may spend less time operating it directly for certain workflows.

The same pattern can apply elsewhere. CRM becomes a tool through which the operating system reads and writes commercial records. A prospecting database becomes a tool for sourcing external evidence. A conversation platform becomes a tool for accessing customer interactions. A calendar becomes a tool for understanding and scheduling time.

This does not make these products low value. Infrastructure can be extraordinarily valuable. It changes their role. The application moves from being the complete environment in which work occurs toward becoming a component used by a broader system.

Some companies will embrace this position. Others will try to own the operating layer themselves. That strategic choice will shape the next generation of enterprise software.

Some applications become sources

Other software may become primarily valuable because of the evidence it uniquely produces or owns. Conversation intelligence is a useful example. Recorded customer conversations are exceptionally rich commercial evidence. The organisation needs them.

But the highest-value interpretation of those conversations may increasingly occur elsewhere. A call can change Deal State. It can inform Coaching. It can affect Forecast. It can change Customer Risk.

The conversation platform remains an important source. The operating layer decides how the evidence relates to the broader organisation.

This creates a distinction between: owning evidence and owning the interpretation of the evidence.

Those were often bundled in SaaS. AI can separate them.

Some applications become surfaces

The reverse can happen too. An application with strong distribution and user trust may remain valuable as a surface even when intelligence comes from elsewhere. CRM is an obvious candidate. Salespeople already live there. A Deal Risk capability generated by an external operating layer can surface inside the CRM.

Slack can become another surface. Teams. Email. Calendar. The browser. The same capability can appear in different places depending on role and context.

This suggests that the future software landscape may not be a clean replacement of old applications with new platforms. It may be a more fluid composition of: systems of record, sources, tools, operating layers, capabilities, and surfaces.

That is a more complicated market structure than “AI replaces SaaS”. It is also more plausible.

The stack becomes less vertically integrated

The classic SaaS application is vertically integrated. It owns several layers of the experience. Data. Logic. Workflow. Intelligence. Interface.

AI-native architecture allows those layers to be supplied independently. A company might use: Salesforce for records. Gong for conversation evidence. Stripe for billing. A specialist model for certain reasoning tasks. Revenue Labs for commercial State, Memory and capability orchestration. Slack as an important user surface. The capability composes them.

This creates a paradox. The user experience can become more integrated while the underlying infrastructure becomes more modular.

That is an important idea. Historically, integration often required buying a larger suite. AI can create integration at the intelligence layer without requiring every underlying component to belong to one vendor. This could strengthen best-of-breed infrastructure in some categories while weakening standalone application boundaries in others.

Suites have an obvious advantage

This is where incumbent SaaS vendors should not be underestimated. Large suites already possess: distribution, customer trust, data, permissions, integrations, workflow ownership, and enormous installed bases.

They can add intelligence across multiple existing applications. That gives them a natural path toward broader operating layers. Salesforce can reason across more of the Salesforce estate. Microsoft can operate across communication, productivity, identity and enterprise data. HubSpot can connect multiple parts of SMB GTM.

The incumbent advantage is real. But there is also a constraint.

Incumbents are economically and architecturally organised around existing application categories. A new operating layer may require crossing boundaries those businesses historically benefited from maintaining. It may also require accepting that parts of the existing interface become less important.

Disruption often occurs where the architecture that created incumbent strength becomes a constraint on adopting the next one. That does not guarantee disruption. It creates the possibility.

AI-native entrants have the opposite problem

New companies face a different challenge. They can design around the new architecture from the beginning. Shared State. Memory. Skills. Capabilities. Agents. Decision Traces. Cross-system execution. No legacy application assumptions.

That gives them conceptual freedom. What they lack is equally important. Distribution. Historical data. Trust. Systems-of-record status. Enterprise permissions. Existing workflow adoption.

AI-native architecture can be superior and still lose if the incumbent owns the environment into which it must be introduced. This means the competition is not simply: old software vs new software. It is a race between: incumbents moving upward from applications and AI-native entrants moving downward into enterprise infrastructure and distribution.

The strategic position of each category will depend on where those paths meet.

The scarce layers determine value

This suggests a useful way to analyse the market. Software value tends to accumulate around scarcity. When storing data was difficult, systems of record were valuable. When specialised workflow software was difficult to build and distribute, SaaS applications captured value. When proprietary datasets were scarce, data vendors gained leverage.

AI makes some things much less scarce. Generic generation. Basic analysis. Simple workflow logic. Natural-language interfaces. Potentially some forms of application-specific intelligence.

Other things remain scarce. Authoritative data. Deep workflow integration. Permissions. Trust. Distribution. Company-specific Memory. High-quality State. Decision history. Outcome data. Proprietary Skills. Organisational adoption.

The value of enterprise AI will likely migrate toward these scarcer layers. That is why access to a frontier model alone is unlikely to create durable enterprise advantage.

Models are extraordinarily important. But the surrounding system determines how much of their intelligence becomes organisational capability.

The seat becomes a stranger pricing unit

The architecture also puts pressure on one of SaaS’s most durable economic conventions. The seat. Seat-based pricing made sense when a human logged into an application and used it to perform work. One employee. One licence. One software surface.

AI makes that relationship less stable. A capability may run overnight without a human user. One manager may consume output created from thousands of machine actions. An agent may operate across several applications. A single RevOps architect may create a Skill used by hundreds of employees and agents.

Who is the user? What is the seat? The software is increasingly doing work rather than merely enabling a human to do it.

Pricing will have to move closer to the underlying value. Usage. Records. Capabilities. Actions. Compute. Commercial assets managed. Outcomes.

Different products will choose different models. But the assumption that human headcount maps cleanly to software value becomes weaker.

This matters because pricing models tend to reinforce product architecture. A company paid per seat naturally optimises for more human users. An AI-native company may optimise for less human interaction. That creates economic tension for some incumbents.

The UI becomes a cost as well as an asset

There is another subtle consequence. SaaS companies spent decades building increasingly sophisticated interfaces because humans had to operate the software. Menus. Dashboards. Settings. Views. Tables. Filters. Admin panels.

These remain necessary in many contexts. But every interface also creates cognitive load. The user needs to understand where information lives and how the application works.

Agents reduce some of this burden. A person can express an objective. The operating layer can determine which tools and workflows are required. The interface can become thinner.

That does not mean everything becomes chat. Chat is excellent for some interactions and poor for others. Visual representations remain valuable. Builders need control surfaces. Managers need structured artefacts.

The deeper point is that users may need to learn less about the underlying software architecture. The system handles more navigation. The UX increasingly represents intent and outcome rather than application mechanics.

Systems of engagement may become systems of interruption

This has an interesting consequence for attention. Every SaaS application wants engagement. Daily active users. Notifications. Dashboard visits. Feature usage.

AI-native software may sometimes create value by doing the opposite. Do not make the manager inspect the dashboard. Do not make the salesperson open another app. Do not notify the user if nothing meaningful changed. Operate quietly. Surface the exception. Request judgement only when necessary.

This creates a different design philosophy. The best software may have high organisational usage and low human interaction. That is unusual relative to traditional SaaS metrics.

It also aligns with the economics of attention we have been developing. A successful operating layer should not maximise engagement with itself. It should minimise unnecessary engagement with the operating system.

Applications may become APIs to agents

At the limit, some software may increasingly be designed for machine consumption. Agents become an important user class. The product needs: reliable APIs, clear permissions, structured semantics, strong identity, auditability, predictable actions, machine-readable pricing, and tool interfaces.

The human UI remains. But the API becomes strategically more important. This could shift product development priorities.

For the SaaS era, companies asked: How do we make humans use our software more effectively? Increasingly they may also ask: How do we make our capability the best tool for intelligent systems to use?

That could create entirely new forms of distribution. The agent chooses the tool. Software competes for machine selection. Reputation, reliability and interoperability matter in new ways.

Categories may collapse at the intelligence layer

GTM provides a useful example. Why are Prospecting, Sales and Customer Success separate software categories? There are good organisational reasons. Different people. Different processes. Different data. Different budgets.

But at the operating-layer level, they share many primitives. Accounts. People. Relationships. Conversations. Commercial history. Company Memory. Capabilities. Signals. Outcomes.

The account researched during prospecting becomes the opportunity managed by Sales and eventually the customer managed by Customer Success. The application stack treats these as transitions between systems. A commercial operating layer can treat them as changing states of a connected entity.

This does not necessarily collapse the departments. It may collapse some of the intelligence boundaries between their software. That creates an opportunity for systems spanning more of the customer lifecycle. Not because “platform” is inherently better. Because the underlying commercial reality is continuous even when application categories are not.

Value can move without revenue disappearing

This is another point worth making carefully. A category can lose strategic control while remaining economically large. Systems of record may continue generating enormous revenue.

Infrastructure remains important. Companies keep paying for critical applications. But the layer determining: what matters, what happens next, where attention goes, and how work is coordinated may move elsewhere.

That is value migration. It does not require immediate revenue destruction. A database can remain essential while another layer captures more of the intelligence. A payment rail can remain essential while another product owns the customer relationship. A cloud provider can remain enormous while application value sits above it.

Understanding AI’s impact on SaaS therefore requires separating economic persistence from strategic position. Many SaaS products will persist. The interesting question is whether they remain the place where the organisation’s judgement and work are organised.

Where categories are most exposed

Not every software category faces equal pressure. Categories appear more exposed when: their core value is primarily workflow coordination, their data is available elsewhere, their actions can be reproduced through APIs, their intelligence is generic, their interface is the main point of differentiation, and their workflows naturally span other applications.

Categories appear more durable when they own: authoritative transactions, unique proprietary data, deep infrastructure, regulatory complexity, high switching costs rooted in real operational dependencies, or specialised capabilities difficult to reproduce elsewhere.

These are not absolute rules. But they give us a way to reason about displacement more carefully. The question is not: Can AI perform this feature? It is: Which scarce asset allows this application to retain control of the workflow when intelligence becomes portable?

That is a much better strategic test.

The operating layer creates a new aggregation point

If the application boundary weakens, something else can become more important. The system maintaining cross-application context. The operating layer knows: what is happening, what changed, what the company believes, which capability should run, which tools are available, which agent should act, which human requires attention, and what happened afterwards.

This creates a new point of aggregation. Not necessarily aggregation of all raw data. Aggregation of commercial understanding and action.

That is strategically important because aggregation tends to attract value. The layer closest to the decision can influence: which data matters, which tools are used, which surfaces receive attention, and which capabilities are invoked.

This is why the operating-layer opportunity is much larger than “AI assistant over CRM”. It sits at a different point in the architecture.

But operating layers need to earn trust

There is a major challenge. The more central the layer becomes, the more consequential its mistakes. A CRM field can be wrong. That is inconvenient.

A shared operating layer can interpret the field incorrectly and propagate that interpretation across several capabilities. That can be much worse. So operating layers need: strong provenance, observable State, governed Memory, versioned Skills, permissions, Decision Traces, evaluation, and clear human intervention.

The architecture that gives the operating layer leverage also creates a much higher responsibility. Trust becomes infrastructure. This is why simplistic agent wrappers are unlikely to become the enduring operating systems of large enterprises. The bar is substantially higher.

The future stack looks different

The commercial technology stack of the future may therefore look less like a list of applications and more like several interacting layers. At the bottom: authoritative systems, proprietary data and operational infrastructure.

Above them: tools and interfaces through which actions can be taken. Across them: a maintained representation of commercial State.

Within the operating layer: organisational Memory, Skills, capabilities, agents, governance and Decision Traces. Above that: surfaces adapted to different roles.

And around the entire system: feedback from outcomes that improves how the organisation operates. Some vendors will span several layers. Some will dominate one. Some existing categories will expand. Others will narrow. New categories will emerge.

The boundaries are not predetermined. But the architecture is becoming easier to see.

SaaS is not dead. Its bundle is changing.

The most useful way to think about this transition is therefore not SaaS versus AI. AI is becoming part of software. The deeper question is what happens to the integrated application bundle that defined the SaaS era.

Data can separate from workflow. Workflow can separate from interface. Organisational logic can separate from application logic. Intelligence can span multiple systems. Capabilities can operate above application boundaries. Surfaces can appear where the user already works.

The application remains. But it is no longer necessarily the place where all of these forms of value need to come together. That changes how software is built. How categories form. How products are priced. How distribution works. And where durable value accumulates.

The SaaS era organised the enterprise around applications. The AI-native era may organise much more of it around shared context, capabilities and outcomes, with applications becoming components inside that broader system.

That is not the end of SaaS. It is the unbundling of the assumptions that made SaaS look like the final form of enterprise software.