The Dashboard Isn't Dying. It's Changing Jobs.

A software founder I follow posted something last week that I haven't been able to put down. He said his users kept telling him: "I rarely go to your dashboard anymore." His team had spent years polishing that dashboard. His conclusion was that the same energy now needs to go into the machine-facing side of the product — and that everyone should go ask where their users actually touch the thing today, because the answer has probably moved. (Zeno Rocha, on X.)

It's an uncomfortable observation if you build software. It's a more uncomfortable one if you build software for an industry that runs on screens.

But the replies were where it got genuinely interesting, and they landed on something better than "the UI is dead."

First, why this lands hard in promo specifically

Our screens are where the re-keying happens.

That's not a criticism of any one platform, ours included — it's just what this industry's software has historically been for. A quote lives in one place, an order in another, artwork in a third, and the dashboard is where a person moves information between them by hand. I've written before about the hidden cost per order that creates, and why more stores shouldn't mean more work.

So when someone says users have stopped visiting the dashboard, the promo version of that question is sharper than it looks. If the daily work moves to an agent, what was the dashboard actually doing? And the honest answer, for a lot of screens in a lot of platforms, is: hosting labor that shouldn't have existed.

The reply that reframed it

The best response in the thread argued that the dashboard doesn't disappear — it changes jobs. It becomes the audit and recovery surface. Fewer screens, but much better ones: permissions, history, undo, and a clear answer to "why did it do that?" The machine side handles daily use. The interface is where trust gets repaired when something goes wrong.

I think that's exactly right, and it's a much more demanding brief than the one most dashboards were built to.

Daily use moves to the agent. The screen becomes where you check, correct, and understand.

Because notice what's now load-bearing. If an agent placed the order, the interesting screen isn't the order form — it's the record of what changed, who or what changed it, and whether it was allowed to. Those used to be the boring tabs. They just became the product.

"The UX didn't disappear, it moved down a layer"

The other line from the thread I keep repeating, because it's the one builders need to hear: the user experience didn't go away. It moved underneath. Schemas, permissions, tool errors, latency, retries — that's the new interface. And once agents are the user, bad tool semantics feel exactly like bad UX.

That reframing does a lot of work. It means "make the agent side good" is not a backend chore you delegate; it's a design discipline with the same standards as the visible one. A tool that's ambiguously named, or silently fails, or needs three calls to do one obvious thing, is the machine-facing equivalent of a confusing form. Nobody sees it. Everybody feels it.

Someone else in the thread asked the question I don't think anyone has a great answer to yet: how do you measure quality on that layer the way we learned to measure dashboard UX? Is there an equivalent of session replay for agent calls? I don't have a satisfying answer. I notice that we all developed a rich vocabulary for evaluating screens over twenty years and have roughly none for evaluating tools. That gap is going to matter.

What this means for what a platform has to have

Take the audit-surface idea seriously and it produces a concrete checklist — one that's worth applying to any platform you're evaluating, including ours.

Permissions that are real, and scoped. Not "the integration has access." Which operations, on which data, for which accounts. If an agent can do anything a login can do, you haven't granted access, you've handed over the keys.

Every write on the record. An agent's change should land in the same reviewable path as a human edit or an API call — with a diff of what it wanted to change, before it goes live. This is the part I'd refuse to compromise on. An action without a trace isn't automation, it's an unexplained event you'll be reconstructing later.

History on the thing itself, not in a log file. Every record in Brikl carries its own activity timeline: what was edited, who edited it, when, and the reference number of the thing it happened to. That was already the right design when only humans were editing. It becomes the answer to "why did it do that?" when they aren't.

Undo, and a way back. Archive rather than delete. Drafts rather than commits. This turned out to matter more than we expected while building v3.0 — nearly everything you create arrives as a draft, and nothing goes live because you clicked once. That was a decision about human confidence. It reads differently now.

And an owner. Every catalog, store, order, discount and card has a person attached to it. When something needs explaining, "who do I ask" should not be a research task.

The honest counterpoint

There was a dissent in that thread too, and I don't want to skip it: someone pointed out that they'd just shipped a new version of their UI and users responded immediately and warmly. For plenty of people, in plenty of moments, a good screen is simply the best way to do the thing.

I believe that, and we act like it. This release, most of our effort went into the visible surface — records that open beside the list instead of replacing it, a store editor where you change the storefront by clicking the thing you want to change, and a create panel that makes any record in a couple of picks. None of that is agent work. All of it is a person, moving faster.

Which is the same conclusion I reached in the second piece of the AI series, arriving from the other direction: the screens don't go away, and intent becomes a second way in. Optionality isn't a hedge. It's the design.

The question worth stealing

The provocation in that original post is the part I'd pass on, because it survives whatever you conclude about dashboards.

Ask where your users actually touch your product today. Not where you'd like them to. Not where the roadmap assumes they do. For a distributor's clients, is it your store, or an email? For your own team, is it the console, or a spreadsheet next to the console? For the buyer with an AI client of their own, is it your platform at all, or a PDF you sent them?

The answer probably moved. It's worth knowing where to.

Brikl for AI, which lets you run the business from your own chat, is coming soon — it ships after v3.0. The reachability argument behind it is in the third piece of the series; what ships now is in what's new in v3.0.