The throwaway dashboard still needs a home.

The shift: build it, read it, throw it away

The advice doing the rounds is blunt: every time you think you need a dashboard, stop. Ask your agent to make sure the data is actually in the database, ask it to write a skill to gather that data, and then ask it to run the analysis and build a temporary, throw-away HTML view that answers the question you have right now. The reasoning is one most people recognise: every dashboard you build gets used less over time and quietly decays, so it is better to make sure the agent can fetch the data and answer the question on demand than to maintain another wall of charts nobody opens.

It is not just one post. The broader version, sometimes labelled the death of the dashboard or agentic analytics, is that agents are moving from rendering static reports to assembling the answer when you ask. The canonical example making the rounds is a small marketing agency that retired its reporting dashboard: when a client asks how their campaign is doing, an account manager asks the agent, gets a written analysis with the numbers, and forwards it. No standing dashboard in the middle.

We have a foot in this already. Anthropic shipped Live Artifacts, dashboards Claude builds inside Cowork that re-query your apps and refresh when you open them, which is the same instinct from the model side: the view is generated and current, not hand-built and frozen. The direction is set. Agents build the view; you stop maintaining it.

Why throwaway is the operative word

The interesting word in all of this is throwaway. The whole point of the pattern is that the page is single-use. You needed an answer, the agent built something to show it, and once you have read it the page has done its job. Keeping it around is the exact problem the pattern is trying to escape: standing dashboards accumulate, go stale, and clutter the place until no one trusts which one is current.

That has a direct consequence for where these pages go. If a page is disposable by design, the host should treat it that way and let it expire on its own, rather than leaving you with a growing pile of links to dashboards that were already obsolete an hour after they were built. Disposability should be the default behaviour of the page, not a tidy-up chore you are supposed to remember. This is the one detail most generic file hosts get wrong for this use: they are built to keep things forever, when the job here is to forget them on schedule.

The missing step: it still needs a home

Full disclosure: we build Stacktree, so read this as us describing where we fit. The pattern as usually told stops at the agent building the HTML. But HTML is not a link. Someone has to open it, often someone who is not at your terminal: a colleague, a client, your own phone later in the day. So there is an unspoken final step between the agent rendering a page and a human reading it, which is hosting it somewhere private.

That is the slot we fill, and only that. Stacktree takes the agent-built HTML and publishes it to a private, unguessable URL, where the URL is the credential, so the viewer needs no account and does not have to belong to any workspace. Three things make it fit the throwaway dashboard specifically rather than generic hosting:

• It expires. Put an expiry on the page so a single-use dashboard removes itself. Anonymous publishes already default to a 24-hour expiry, so throwaway is the default state, not a setting you have to apply.
• It is private by default. The page is not indexed and not guessable. A client report or an internal number is not something you want a public link or a search result for.
• It can be gated. Add a password, or restrict to an email domain with magic-link verification, when the page leaves your team. The dashboard your agent built for a client opens only for that client.

The trade is honest: Stacktree hosts static HTML, so a published page is a snapshot, not a self-refreshing dashboard. That is the right shape here. A throwaway dashboard is a snapshot by definition. You built it to answer one question at one moment; if you want a fresh read tomorrow, the agent builds tomorrow's.

How an agent does it end to end

Because the publish step runs over MCP, the agent can do the whole thing without you leaving the conversation. The loop is: gather the data with a skill, render the HTML, publish it, hand back the link.

In practice the agent calls publish_html with the rendered page and gets back a private URL. It can set an expiry in the same call so the page is disposable from birth. If the dashboard is for a client, it can add a password or an email-domain gate. And if you ask a follow-up that changes the view, update_site replaces the page in place at the same URL, so the link you already sent stays correct. We package this as a status-dashboard skill so an agent runs the gather-render-publish loop as one move, but the primitive is just the publish call, and any agent wired to Stacktree over MCP can do it.

The result is the pattern completed. The agent does not just build a dashboard that lives on your machine; it builds one and hands you a private link that someone else can open and that tidies itself away. The throwaway dashboard becomes something you can actually pass to a person, which is usually the reason you were building it.

When to keep the dashboard

It is worth being straight about the limits of the pattern, because the loudest version of it overreaches. Dashboards are not dead. The ones worth keeping are the governed, recurring views that many people read and trust: a revenue board, a reliability dashboard, the numbers a team aligns on every morning, backed by a semantic layer and agreed definitions. Those are guardrails. Replacing them with an agent improvising a fresh page each time would trade consistency for novelty, and the analytics teams pushing back on the death-of-the-dashboard framing are right to.

The throwaway pattern is for the other ninety percent: the long tail of one-off questions that never justified a permanent dashboard, the client report you assemble once, the quick look you needed on a Tuesday and will not need again. That work used to mean either building a dashboard you would abandon or doing it by hand. Now an agent builds the page on demand, and the only thing it needs from you is somewhere private to put it for as long as it matters, and not a minute longer.