The life of a dashboard
It begins with a real need. Somebody in a meeting says they wish they knew how many people finished setup last week. Somebody else says that could be a dashboard. Everyone agrees, in the way people agree when it means the meeting can end.
Two weeks later it exists. It has a title, a date picker that defaults to the last seven days, and eleven other charts that nobody asked for but which were easy to add. The link goes round on Slack. There is a small round of approving emoji. It is, genuinely, a handsome thing.
In the third week, four people open it. In the fifth, one does. By the second month, the link lives in a message nobody will scroll back to, and the dashboard carries on in the background, refreshing its numbers for an audience of nobody, like a lighthouse on a canal.
Nobody decides to stop looking at it. There is no meeting where it is retired. It simply becomes one more thing that is technically running, and the monthly bill for the tool that hosts it continues to arrive.
Who opens it
I have built a few of these myself, so I say this with affection. The person who most often opens a dashboard is the person who made it, and mostly to check that it still works. The second most common visitor is whoever has been asked a question in a meeting and would like to look prepared.
There is also a quieter pattern. When a number matters, someone takes a screenshot of the dashboard and pastes it into a document, with a sentence of explanation. The sentence is the useful part. The dashboard was a delivery vehicle for a screenshot.
I will admit that every company I have run has had a dashboard that looked fantastic and was consulted about as often as the fire exit plan. Which is a fine thing to have, and a strange thing to build a morning routine around.
Asking is quicker than looking
The reason for all this has changed, and it is worth being plain about what changed. You can now just ask. How many teams signed up this week, and did any of them stall during setup? An agent can go and find out, read what it needs and give you the answer in a sentence, with where it came from.
Compare that with looking. To look, you must know which dashboard, find the link, wait for it to load, pick the date, work out which of the twelve charts is the one you meant, and then interpret it. The question you actually had was a single sentence. The dashboard answers a slightly different question, which is the one its builder guessed you might ask.
There is a small cost to the guessing, too. Each new question someone has turns into a request to add a chart, and someone has to build it, and by the time it exists the moment has gone. Meanwhile the old charts stay, because removing one feels like a decision and keeping one feels like nothing. Dashboards only ever accumulate.
A dashboard can only show what was anticipated. A question can be about anything, including the thing nobody thought to chart until yesterday.
Where the answers have to live
There is a condition, and I do not want to skip it. Asking only works when the answer lives somewhere the agent can read. A dashboard is a picture of data that sits elsewhere. If the only copy of your numbers is inside a chart, the agent has nothing to read except the chart, and that is a poor way to do arithmetic.
A practical example. A team keeps its weekly signup export in a folder, next to a notes file where someone writes down what changed that week: a new onboarding step, a pricing test, a bad day for the email provider. Someone asks why signups dipped on Thursday. The agent reads the export, reads the notes, and finds the line about the email problem. No chart could have told you that, because the explanation was never in the numbers.
What agents are good at is files. Logs, exports, notes, spreadsheets saved as CSV, the Markdown page where someone wrote down what happened in the incident. All of that is the data itself, in a form that can be searched and quoted. Put the export in the shared folder, keep the notes next to it, and the question about last week has somewhere to go.
This is a change in where you spend your effort. Less on drawing the thing, more on making sure the underlying material is written down somewhere that people and agents can both reach.
What dashboards are still good for
I would be a poor critic if I did not give dashboards their due. Some of them earn their keep every day. A wall display showing whether the service is up, in a room where people will see it without trying, is worth a great deal. So is a screen that shows what is on fire during an incident, when a dozen people need the same picture at the same moment and nobody has time to type a question.
They are good for shape. A line going up for six months tells you something faster than a paragraph does, and an agent describing a trend is not a substitute for seeing it. They are good for numbers that need to be shared and agreed, so that a team argues about what to do rather than about what the figure is.
What they are bad at is being the default way to find something out. Treat them as a wall and they are fine. Treat them as the front door and you get the tab nobody opens.
What agent-first means in practice
We have tried to build Baseseat the other way round. Agent-first sounds like a slogan, so here is what it means as a list of decisions. Everything is reachable through the API, MCP, the CLI and the Python SDK before anyone thinks about a page. Skills teach agents how to use the product, so the instructions live where the agent works rather than in a help centre it will never visit.
There is a console, because some things a person should click themselves. Inviting a teammate. Paying the bill. These are decisions with consequences, and I would rather a human made them with their eyes open than an agent made them on a good day.
What there is not, deliberately, is a screen you are meant to keep open. A product should not need a person on watch. If something needs you, it should tell you, and say what it needs. Otherwise it should get on quietly with it, and you should be able to ask how it went.
For the same reason, the things a person might otherwise have to watch are written down as files and logs an agent can read. If you want to know what happened overnight, ask, and the answer comes from the record rather than from whoever happened to be looking at the right screen at the right time.
The tab test
The test I use is crude and works well enough. If a task would require someone to keep a tab open and watch it, we have probably built it wrong. A long import should finish and say so.
So the next time a new dashboard is proposed, I would ask two things. Who will open it in a month, by name. And would they get the same answer faster by asking.
If there is a good answer, build the wall. Some numbers deserve one. If the honest answer is that the person who will open it is the person proposing it, put the data somewhere an agent can read it and close the tab.
I do realise that a post arguing against dashboards will probably be read, by some of you, on a tab you meant to close an hour ago. Consider it a small exercise. Close it when you have finished. The number you were going to check will still be there, and you can always ask.