Apps were for clicking. Munin isn't.

Every SaaS app I've used for the last fifteen years was, at root, a drawing of a database. Buttons mapped to writes. Lists mapped to selects. The UI was the product because clicking was the only protocol we had. That assumption is quietly ending — not because design got worse, it got better, in ways the industry should be proud of. It's ending because the cheapest operator in the system has stopped being a person.

When an agent can call a tool ten thousand times an hour for a few cents, the act of clicking through a workflow becomes a strange thing to pay a human to do. The form is still there. The reason for it isn't.

Munin is built on the bet that this is more than a productivity story. It's an architectural shift. The next decade of business software won't be designed for the people who used to click "Send" — it'll be designed for the people who decide which sends are worth a human's name at the bottom of them. There are fewer of those people, and the surface they need is smaller, sharper, and almost entirely supervisory.

Why is the user interface no longer the product?

Because the interface was only ever a way to make a database editable by hand, and hand-editing has stopped being the cheap option. When an agent can call a tool ten thousand times an hour for a few cents, a page whose purpose is to collect keystrokes has no economic reason to exist. The UI survives where judgment lives, not where typing did.

The original sin of SaaS was that the screen was the spec. If you wanted to know what the system could do, you opened the app and looked at the buttons. If a workflow wasn't on a screen somewhere, it didn't really exist. APIs were exports of the UI, not the other way around — and the integrations market built itself, profitably, by gluing those second-class APIs back together.

It worked. It worked so well that an entire profession formed around it: the operator who knows where to click. Customer support, sales ops, content production, outreach — these are all professions defined by knowing the menu structure of seven different SaaS apps and which one to open at 10:42 on a Tuesday. The good ones get fast at it. The great ones stop noticing the menus.

The trouble is that the menus were never the actual work. They were the interface to the work — and we'd accidentally let that interface become the canonical description of what the company knows how to do. If it isn't a button, we don't ship it. Anyone who has tried to add a single off-menu capability to a mature SaaS knows what I mean.

Do AI agents use a UI or an API?

An API, every time. Given the choice between rendering a form and reading a function signature, an agent picks the signature — it enumerates a tool catalogue rather than scanning a screen, and it doesn't get tired or distracted halfway through. Munin is built this way round: the tool surface is canonical, and every interface including our own dashboard is a client of it.

The MCP protocol is the boring, correct version of this idea. It's not glamorous. It's HTTP for the new caller. The fact that it's boring is the point — protocols win when they stop being interesting. Munin is MCP-first because we couldn't find a credible counter-argument: every product surface we'd otherwise draw is downstream of a small, stable set of tool calls. Build the tools first; the surfaces fall out.

That's not the same as "agents replace UI". UI is fine. UI is, for the foreseeable, the surface where humans make irreversible decisions and the surface where they catch agents being wrong. What changes is the order of operations: the UI no longer defines what the system can do. The protocol does. The UI is one of several clients.

What does a business application look like when agents operate it?

Three things change. The workflow library moves out of the UI and into the tool catalogue. The number of pages shrinks, because rendering a page is rarely the cheapest way to do anything. And the review queue becomes the product — the place where humans approve, edit, or reject work that agents have already drafted.

In more detail:

• 01The workflow library moves out of the UI and into the tool catalog. What was once "what you can do on the Contacts page" becomes crm_* — a list a person can read in three minutes and an agent can read in three milliseconds.
• 02The surface area of the product shrinks. There are dramatically fewer pages, because there are dramatically fewer cases where rendering a page is the cheapest way to do something. What remains is a small, sharp set of supervisory views.
• 03The review queue becomes the product. Not "the inbox" — the place where humans approve, edit, or reject the work agents have already drafted. That's where the company's judgment lives now.

None of this is hostile to design. It's actually friendlier than what came before. Most of the SaaS dashboards I've used would be better as five screens than as fifty — and would be better still as five screens plus a well-named tool catalog. The pruning that's coming is overdue.

You can watch the third one happen in a single module: the CRM record that fills itself in is a page nobody visits to type into any more, and a queue somebody visits to decide. The same shape governs outreach that drafts overnight and waits for approval.

Which parts of SaaS software survive the shift to agents?

The data model, the identity layer, the audit log, the consent state, and the place where humans approve things. Those were always doing real work. What does not survive is the typing: long onboarding flows, redundant confirmation modals, settings pages that existed only to expose flags. Fewer pages, sharper ones, and one record behind all of them.

Munin's claim is narrow. We don't think every business app should be replaced. We think the apps that touch the customer record — knowledge, conversations, CRM, content, outreach, analytics — should share a backend, expose themselves as tools, and present one supervisory surface to the human team that owns the work. Not because the apps are bad. Because a customer who exists six times over is six chances to be wrong about them.

And we think this should be open. Open code, open protocol. Lock-in at the data layer is the failure mode that turned the last decade of SaaS into a syncing project. We're trying not to repeat it.

If agents do the work, what is left for people to do?

Judgment, and more of it than before. The work moved upstream rather than disappearing: which agent gets which scopes, which workflows escalate to a human, which proposals ship automatically and which wait overnight. That is the role Munin is built around — the operator who got promoted out of the menu and into the decision.

I want to be clear that this is the part I think gets missed in arguments about agentic software. The interesting work hasn't moved out of the company; it has relocated inside it. The interesting work used to be the click. The work hasn't shrunk. It's moved upstream.

The people doing that work are not, mostly, the same people who used to click "Send". Some of them are. Many of them are operators who got promoted out of the menu and into the judgment. The Munin team is built around the assumption that this is the role that matters most in the next decade — and that the tools for it are what we should be building.

Frequently asked questions

Are AI agents replacing business software interfaces? They are replacing the data-entry parts of them. Pages that existed to collect keystrokes lose their reason to exist when a tool call is cheaper. Pages where a human makes an irreversible decision, or catches an agent being wrong, become more important rather than less. Expect fewer screens doing more consequential work.

What does "MCP-first" actually mean in a product? That the tool catalogue is the canonical surface and every interface is a client of it, including the vendor's own dashboard. The alternative — a UI with an agent layer bolted alongside — produces two systems that drift apart. Munin exposes its whole platform at one MCP endpoint, and the dashboard calls the same tools an agent does.

Does an agentic platform still need a UI? Yes, a smaller one. Humans need somewhere to approve irreversible actions, review what agents proposed, and see the state of the record. What they no longer need is a page for every write. The design job shifts from drawing the database to designing the review surface.

What is a review queue? The list of things agents have drafted and not yet done: a merge proposal, an outreach email, a knowledge-base article, a content draft. Cheap reversible work applies automatically; anything irreversible waits for a person. It is the surface where a company's judgment is actually recorded, which is why we treat it as the product rather than a settings page.

Which jobs do agents absorb first? The typing-shaped ones: triaging inbound conversations, tagging and titling threads, enriching a contact from a company site, drafting an answer to a question your team has already answered once. None of it is judgment. All of it is the work that used to happen at 11pm or not at all.

Is this just chatbots bolted onto a CRM? No — the difference is which side is canonical. A chatbot is a widget in front of an app whose real surface is still the UI. Munin's tools are the surface, so an agent does triage, enrichment, and drafting directly against the record, and the human approves what matters.

If you'd rather see a supervisory surface than read about one, Munin Cloud is free to start, and the tool catalogue is the actual product.

Apps were for clicking. Munin isn't.