The UI of Agentic SaaS
This essay came together while I was thinking through interfaces, value, and surfaces in Bruges.
If you haven't read my previous essay, read it here: The Future of SaaS is Agentic
TL;DR: Agentic SaaS does not need a brand-new interface for every workflow. Operations can happen in surfaces people already use like email, chat, or messaging, while insights, control, and security need purpose-built product surfaces. The winners will not be the companies that reinvent every UI, but the ones that choose the right surface for each responsibility and actually remove work.
Most SaaS still assumes the app is where work happens.
You open the product. You learn its workflow. You click through screens, fill in forms, move data around, and manually push the system toward an outcome. That model made sense when software could only respond to inputs. But once software becomes agentic and can actually perform work, that assumption starts to break.
This is the mistake a lot of people make when they think about the UI of agentic SaaS. They assume the future must look like a radically new app. New product, new screen, new shell, new interaction pattern. But that is the wrong starting point.
Agentic SaaS does call for a radically new UI model. It just does not always call for a radically new interface.
That distinction matters.
The shift is not from forms to chat. It is not from dashboards to copilots. It is not from clicking buttons to typing prompts.
The shift is from software that must be operated to software that can execute.
Once that happens, the role of the user changes. The user is no longer there to drive every step of the workflow. Their job becomes expressing intent, setting constraints, reviewing outcomes, and stepping in where judgment is required. And once the role of the user changes, the role of UI changes with it.
In traditional SaaS, UI exists to help users operate software.
In agentic SaaS, UI exists to capture intent, show progress, surface exceptions, deliver insights, and provide control.
That is the real change.
A lot of builders miss this because they are still thinking in terms of product surfaces instead of value delivery. They assume the interface is the product. It often isnât. The real question is not, âWhat should the UI look like?â The real question is, âWhat is the best surface to deliver value with the least friction and the most trust?â
And in many cases, the answer is not a new app.
If a user already lives in Gmail, Outlook, Slack, Teams, SMS, WhatsApp, or Telegram, those are already operational surfaces. They are where work gets requested, approved, nudged, and confirmed. If an agent can derive real value through those surfaces, then forcing the user into a brand-new interface is often unnecessary friction disguised as product design.
This is the lesson a lot of AI-native products still havenât internalized.
Users do not adopt software because the interface is novel. They adopt it because the product removes real work.
That is why an agent can create enormous value inside a chat surface without needing to invent a whole new shell. If the job is to trigger an action, answer a bounded question, request approval, send an update, or complete a lightweight workflow, existing communication surfaces are often more than enough. In those cases, the agentic leap is not visual. It is operational.
That is also why rebuilding the inbox is usually the wrong ambition.
Superhuman is great, but how many enterprises have abandoned Gmail or Outlook for it?
That is not a knock on Superhuman. It is a reminder of where the real leverage is. Gmail and Outlook already contain years of product work, edge-case handling, trust, and behavior. No enterprise switches because your inbox looks cleaner. They switch when you remove actual work, improve actual outcomes, and fit into the surfaces their teams already use.
But this is where the argument gets more subtle.
Just because operations can happen in existing surfaces does not mean the entire product can.
Enterprise SaaS is not just about helping people trigger actions. It is also about helping them understand what is happening, decide what matters, control how the system behaves, and trust that it operates within clear boundaries.
This is where thinking in terms of a single interface breaks down. Agentic SaaS is not one UI. It is a system of surfaces.
The first surface is operational.
This is where work gets initiated, approved, completed, or escalated. Operational interactions are usually lightweight and episodic. âSend this update.â âApprove this request.â âFollow up with this lead.â âBook this meeting.â âSummarize this issue.â These interactions fit naturally into channels people already use. For this layer, chat, email, and messaging are often enough.
The second surface is insight.
This is where a lot of agentic products become weak. They assume a summary in Slack or a chart screenshot in email is enough. It isnât.
A sales leader does not run a team from a summary message. A finance leader does not understand operational health from a paragraph in chat. A support manager does not diagnose quality issues from a few generated bullet points.
Messages can alert. Messages can summarize. Messages can nudge.
They are a weak place to inspect trends, compare periods, drill into anomalies, build trust in what the system is saying, and actually understand what is going on.
That is why insight surfaces need to be purpose-built. Not because enterprises love dashboards, but because some kinds of value require sustained inspection. They require visual reasoning, comparison over time, contextual explanation, and the ability to move from signal to diagnosis. Chat is a good alerting surface. It is usually a bad analytical surface.
The third surface is control.
This is the layer that turns an interesting demo into a deployable product.
Enterprise buyers do not just want an agent that can do things. They want to define who can do what, what actions require approval, what thresholds trigger escalation, which workflows can run autonomously, and where humans need to stay in the loop. They want guardrails. They want permissions. They want operating logic they can trust.
That cannot live as scattered instructions in a chat thread.
Control is not a feature around the product. Control is part of the product.
The fourth surface is security and governance.
This is where the fantasy of âeverything will happen in chatâ fully breaks.
Enterprises need auditability. They need access visibility. They need data controls, retention policies, training settings, tool permissions, abuse monitoring, and boundaries around what an agent can and cannot touch. They need to know which systems were accessed, which actions were taken, what data moved, and whether anything unusual happened.
A chat window can carry the action. It cannot carry governance.
This is why the UI of agentic SaaS is not one beautiful AI-native interface. It is a layered distribution of responsibilities across different surfaces.
Operations can happen in familiar tools. Insights need purpose-built analytical surfaces. Control needs native product layers. Security needs governance surfaces.
That is what a new UI model actually looks like.
This also clarifies what an intent-oriented UI should be.
An intent-oriented UI is not a blank search box. It is not âtype anything and hope the model figures it out.â And it is not a maze of menus dressed up with AI.
An intent-oriented UI starts with the job the user wants done, gathers only the missing constraints, executes what it can, and returns control where judgment is required.
That is the difference between chat and product.
If the user wants an answer, a quick summary, a lightweight approval, or a bounded action, chat may be enough. But if the user needs persistent state, visual reasoning, policy definition, exception handling, collaboration, auditability, or trust, it stops being just chat and starts becoming product.
A message can deliver an answer.
A product must deliver a reliable outcome.
That is the line.
And this is why the best agentic SaaS products will not start by reinventing UI for the sake of novelty. They will start by simplifying the workflow itself.
Before building a new interface, they will ask: where is value actually created? Which steps are real, and which ones are artifacts of how legacy software was designed? What requires human judgment, and what can be delegated? Which interactions belong in surfaces users already trust, and which ones need native product layers because the job itself demands it?
That is the real work.
Not making software feel more futuristic. Not wrapping old workflows in chat. Not rebuilding Gmail with a prettier AI shell.
The winners in agentic SaaS will be the companies that understand a simple idea: not every job needs a new interface, but every valuable workflow needs the right surface.
That is the UI of agentic SaaS.
Not one app. Not one chat box. Not one dashboard.
A system of surfaces, each designed around a different responsibility: action, understanding, control, and trust.
Subscribe
Or subscribe via RSS.