When AI becomes the interface, what does SaaS become?
As AI changes how people interact with software, the enduring product may be the trusted capabilities, rules and business state beneath the interface.
By Rico Solo
For decades, the interface and the product have been treated as almost the same thing. We bought software, logged into its interface and learned its particular way of working.
AI is beginning to separate those ideas.
A person may still open the product itself. But they might also ask an embedded assistant to do something, work through a company-wide agent, or use an interface generated for a particular task. The intent can begin somewhere else entirely while the product remains responsible for the work underneath.
That changes the design question. It is no longer only what should this screen look like? It becomes what must this product reliably know, decide and do, regardless of where the interaction begins?
This is not simply a move from graphical interfaces to chat. It is a shift in the shape of software, and it requires systems thinking.
The interface is detaching from the product
Traditional SaaS products tend to bundle several things together: the data, the business logic, the workflows and the interface used to access them.
AI weakens that bundle. A model can interpret a goal expressed in ordinary language, discover the relevant capability and coordinate work across several systems. The user no longer needs to know which menu contains the action, or sometimes even which product performs it.
Consider a request such as:
“Show me the invoices due this week, explain anything unusual and prepare the payments that are safe to process.”
The useful part is not the chat box. The useful part is the system's ability to understand the request, retrieve the correct records, apply the right business rules, identify anomalies, respect permissions and prepare an action without prematurely committing it.
The conversation is one possible interface to those capabilities. It is not the product architecture.
What remains underneath
As interfaces become more fluid, the durable part of SaaS increasingly looks like an authoritative capability layer.
It holds the trusted state of the business. It encodes the rules that determine what is valid. It understands permissions, relationships and persistent context. It exposes meaningful actions that can be used through a human interface, an embedded assistant or an external agent. And it records what happened so that consequential actions can be understood and audited.
This is sometimes described as “headless SaaS”. I find that framing useful, provided it does not imply that the human experience becomes unimportant. The interface still matters enormously. What changes is that it is no longer the only place where the product exists.
The deeper product is the combination of:
- Authoritative business state
- Deterministic rules and calculations
- Permissions and approval boundaries
- Capabilities that can be safely invoked
- Context that persists across interactions
- A record of decisions and actions
The interface becomes a considered expression of that system for a particular person, task and moment.
The model can be probabilistic. The business state cannot be.
This distinction becomes critical in finance and other consequential domains.
A model can be excellent at interpreting an ambiguous request, deciding what information to retrieve, explaining a result or adapting how it presents that result. Those are probabilistic activities. There may be several useful ways to understand or communicate the same situation.
But the ledger balance cannot depend on how the model feels today. Tax calculations, transaction status, access rights and approval limits need an authoritative answer. The underlying system must determine what is true and what is allowed.
The safest architecture uses each layer for what it does best:
- The model interprets intent; the product validates the requested action
- The model explains an anomaly; deterministic services calculate the underlying figures
- The model proposes a payment; permissions and approval rules determine whether it can proceed
- The model adapts the experience; the audit trail records what actually happened
This also protects continuity. A new conversation should not create a new version of the business. The context can be reinterpreted, but the source of truth must remain stable across sessions, people and interfaces.
Tool design is interaction design for machines
If agents are going to use a product, its capabilities need to be legible to machines as well as people.
An action named update_record may be technically functional, but it tells an agent very little. What kind of record can it change? What information is required? What rules apply? Is the action reversible? Does it need approval? What will the user see afterwards?
Designing these capabilities involves many of the same concerns as designing a good human workflow:
- Clear language and purpose
- Sensible defaults
- Constraints that prevent invalid outcomes
- Useful error states and recovery paths
- Visibility of consequence before commitment
- A clear distinction between preparing and executing an action
Protocols such as MCP can make capabilities available to agents. They do not remove the need to design those capabilities well. A technically available tool is not necessarily an understandable, safe or useful one.
This is why I see tool design as a new form of interaction design. The immediate user may be a model, but the outcome still affects a person and their business.
One product, three experience surfaces
For many SaaS products, I expect three surfaces to coexist rather than one replacing the others.
The human interface remains essential for exploration, detailed review, comparison and tasks where people want direct control.
The embedded AI experience helps people express intent, coordinate multi-step work and understand the product without leaving it.
External agents allow the product's capabilities to participate in a wider workflow that may span several systems.
These are not three separate products. They are three routes into the same underlying model of capabilities, rules and trusted state.
The design challenge is coherence. A permission should not behave differently because an action began in a chat. A figure explained by an agent should reconcile with the one shown in the interface. A prepared action should be visible wherever a person goes to review it.
Brand must survive outside the interface
When an experience is mediated by an agent, traditional visual branding may be reduced or disappear entirely. That does not make brand less important. It makes brand more behavioural.
Brand is expressed in what the product is willing to do, when it asks for confirmation, how it communicates uncertainty, how it explains a financial result and how it helps someone recover when something goes wrong.
For a product responsible for consequential business information, trust may be conveyed through behaviours such as:
- Showing where a figure came from
- Separating a suggestion from a confirmed fact
- Making approval boundaries explicit
- Preserving a clear audit trail
- Using consistent language across every surface
- Knowing when the system should stop and ask
A generative interface should be able to adapt without making the product feel inconsistent or unreliable.
Generative UI needs deterministic grounding
Generative interfaces create a useful possibility: instead of navigating a fixed information architecture, a person can receive an interface assembled around the task at hand.
That flexibility still needs boundaries.
The system needs to know which components are permitted, which data can appear, which actions can be combined and when a human decision is required. Accessibility, language, interaction states and visual hierarchy cannot become optional because an interface was generated at runtime.
This is where design systems begin to act as governance systems. They can provide machine-readable rules for how an experience is assembled, not only reusable components for a designer to place on a canvas.
Coherence becomes the design problem
In this model, discoverability takes on a different meaning.
Historically, teams have worked to make features visible inside a product. In an agent-mediated world, a capability may also need to be understandable and selectable outside that interface. Its name, description, inputs, permissions and consequences influence whether an agent can find and use it appropriately.
There are still open questions here. How should products communicate the relative value of similar capabilities? How should an agent choose between providers? How do we prevent commercial incentives from compromising a user's intent? What does meaningful consent look like when several systems participate in one action?
These are not just technical integration questions. They are product, commercial and experience questions, and they need to be considered together.
The answer cannot be another set of isolated screens. It requires shared principles that govern the whole system: what the product knows, what it can do, how it behaves, where authority sits and when human judgement must remain visible.
Designing beyond the screen
None of this makes interface craft less valuable. Clear hierarchy, thoughtful interaction, accessible components and precise language remain essential.
But the designer's object of attention is expanding.
We need to understand the relationship between model behaviour and deterministic systems. We need to design capabilities as carefully as screens. We need to make actions understandable to both people and machines, define where autonomy ends, and ensure that every surface remains connected to the same trusted state.
The opportunity is not to put a conversational layer over the software we already have. It is to reconsider what the product becomes when the interface is no longer fixed.