I shipped the M365 AI Analyst Agent this year, part of taking our Claude rollout, the one now past 500 active users, beyond engineering and into how the rest of the org works. The agent writes the weekly status report on its own. Ask it how the week went and it reaches into Outlook, into Teams, into SharePoint, and puts the report together right there in the chat. Nobody opens a dashboard to get it, and other teams have picked up the same agent for their own reporting since.
Instead of a new screen, I built a connector and let the assistant be the interface. That is the whole shift this post is about, and once you see it in one workflow, you start seeing it everywhere.
The scene that keeps repeating
The pattern is always the same shape. Someone needs an answer, a status, a number, a summary of what happened this week, and instead of opening the tool that owns that data, they ask an assistant sitting in their chat window. The assistant reaches into Outlook, into Teams, into whatever system holds the record, and assembles the answer on the spot. Most people could not tell you which system technically owns the underlying data, they just got the answer.
What makes this possible is connectors: MCP and the tools like it expose a system of record as something an assistant can call directly, instead of something a person has to click through screen by screen. Every system wired up this way effectively goes headless. The database, the ticketing system, the reporting tool, all of it is still there doing its job, a growing share of the people who benefit from it will just never see its screen.
What dies, and what survives
For a decade, UI stickiness carried most of the moat in SaaS. Get someone to open your app every morning, build the habit, own the login screen, and a lot of the business model followed from that attention. Design teams spent years shaving seconds off flows and adding just enough delight to keep people coming back to the app itself.
That kind of stickiness stops being worth much once an assistant can get the same job done without opening the app at all. If the value your product provides can be extracted through a connector, the interface stops being the reason someone stays.
What survives underneath is what I argued in the opening post of this series: the system of record, the data quality behind it, the contract governing what an agent is allowed to read and write, and the trust already banked with the people using it. None of that lives in the screen. A well-designed interface will not save a product if what is underneath it is thin, stale, or unreliable, because the interface is no longer even in the loop for a growing share of usage.
Discovery moves into the tool catalog
Distribution used to mean the home screen, the browser bookmark, the tab someone leaves open all day, the app icon worn into the muscle memory of someone's thumb. Winning that spot was most of the go-to-market fight for a generation of SaaS products.
The new version of that fight is being present, described well, and reliable in the catalog of tools an assistant can reach for. Discovery happens at the moment an agent is deciding which tool finishes the job it has been asked to do, not at the moment a person is browsing an app store or clicking a link in an email. A machine is making that selection, and it is choosing based on whether it understands what your tool does and whether it can trust the tool to do it correctly every time it is called, not on how the icon looks.
That changes what "findable" means in practice. Machine legibility, whether an assistant can tell what your tool is for and use it without a person translating in the middle, becomes a product requirement instead of a nice-to-have. So does reliability under repeated, unsupervised calls. A person will route around a rough edge out of habit. An agent calling your API in a loop will not.
What to instrument now
Almost every product team I know still measures usage almost entirely through their own front end: sessions, daily and monthly actives, feature adoption inside the app. That is a reasonable way to measure a product when the app is the only door in.
The number worth watching now is the split, what share of your product's value gets consumed through your own front end versus through an agent or an API calling in underneath it. My guess is that ratio moves fast once agents start doing real work on people's behalf inside a company, and most teams have no instrumentation on the agent and API side at all. They will not see the shift happening until it already has, because they built the sensor for the old front door and never built one for the new one.
The practical move here is simple. Look at API and connector call volume against UI session volume. Look at how many jobs get completed by something calling in versus a person clicking through screens. Start tracking it now, the baseline you would want to compare against later does not exist yet if you wait for the shift to become obvious.
Where this goes
The status report that writes itself is where every system of record is headed over the next few years, once this becomes the normal way work gets done inside a company. The teams that come out ahead will be the ones that already know what survives without the screen, because they built for it before it was optional.
This is post 5 of 9 in my Thoughtful interfaces series. The rest lives at hagestedt.com/writing.