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 fact, 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.

The screen used to be the spec

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.

Agents don't click

The shift that finally breaks the screen-as-spec model is that agents — Claude, Cursor, whatever your favorite runner is this month — don't click. They call. Given the choice between rendering a form and reading a function signature, they pick the function signature every time, and they don't get tired or distracted halfway through. When the operator is an agent, the cheapest surface to design is the one that exposes tools, not pages.

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.

The shape of what's left

If you take this seriously, three things happen to the shape of a business application:

• 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.

What survives

The parts that survive are the parts that were always doing real work: the data model, the identity layer, the audit log, the consent state, the place where humans approve things. The parts that don't survive are the ones that were doing typing exercises — the long onboarding flows, the redundant confirmation modals, the "settings" pages that were really just exposing flags.

Munin's claim is narrow. We don't think every business app should be replaced. We think the five apps that touch the customer record — knowledge, conversations, CRM, content, outreach — 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 the customer is one person. The record should be too.

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.

The work between

I want to end with the part that I think gets missed in arguments about agentic software, which is that the interesting work hasn't moved — it has just relocated. The interesting work used to be the click. Now it's the choice of which agent gets which scopes, which workflows escalate to a human, which proposals get shipped automatically and which sit in a queue overnight. 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.

Apps were for clicking. Munin isn't.