Your agent built a dashboard. Here is where to put it.

The throwaway dashboard pattern

Ryan Carson put the pattern plainly in a post on 29 June 2026: every time you think you need a dashboard, stop. Ask your agent to make sure the data you need is actually stored in the database, ask it to write a skill to gather that data, then ask it to run the analysis and build a temporary, throwaway HTML dashboard that answers the questions you have. His reason: every dashboard he had built got less use over time and decayed, so it is better to make sure the agent can get the data and answer questions on demand.

The word doing the work is throwaway. The page is single-use: once you have read it, it has done its job. Keeping it around brings back the problem the pattern is meant to escape, a pile of stale views where nobody is sure which one is current. Anthropic's Live Artifacts, which Claude builds inside Cowork and which re-query your connected apps when you open them, come from the same instinct on the model side: the agent builds the view, and you stop maintaining it.

The step the agent leaves you with

The pattern works, but it stops one step short. The agent produces a block of HTML, and HTML on its own is not something you can send. Someone has to open it, often away from your terminal: a colleague, a client, or you on your phone later that day. That means the page needs a URL.

That is the only gap, and it is small. The page has to be hosted somewhere that hands back a link. The question is just which host, because the obvious ones are built for a different job.

Why generic hosting is the wrong shape

You could drop the HTML on GitHub Pages, Netlify, or an S3 bucket. They will serve it. But their defaults are built for publishing a public website and keeping it up: the page is public, often indexable, and permanent unless you go and delete it. An agent-built dashboard is usually the opposite of all three. It tends to carry real data the agent pulled in, it is meant for specific people, and it is single-use. So the generic host leaves you manually setting access you do not have, and manually cleaning up pages that were obsolete an hour after they were built.

The shape this use case wants is private by default, gateable per link, and disposable on a timer. That is a different host, not a different bucket.

The private, disposable fix

Full disclosure: we build Stacktree, so read this as us describing where we fit. Stacktree takes the agent's HTML and publishes it to a private link with three properties that match a throwaway dashboard specifically:

• Private by default. The URL is unguessable and the page is served with a search and AI opt-out header, so it is not indexed and not discoverable by guessing. A page with client numbers stays between you and the recipient.
• 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 disposable is the default, not a chore.
• Gateable per link. Add a password, or restrict to a client's email domain with magic-link verification, when the page leaves your team.

The trade is that Stacktree hosts static HTML, so the page is a snapshot, not a self-refreshing dashboard. That is the right shape here: a throwaway dashboard is a snapshot by definition. If you need a standing view that re-queries live data for many viewers, that is a real dashboard tool's job, not this.

How an agent does it in one step

Because the publish step runs over MCP, the agent can finish the job without you leaving the conversation. It calls publish_html with the rendered page and gets back a private URL, setting an expiry in the same call so the page is disposable from the start. For a client, it adds a password or an email-domain gate. If a follow-up changes the view, update_site replaces the page in place at the same URL, so a link you already sent stays correct. We package this as an agent-run-report skill so the gather, render, and publish steps run as one move, but the primitive is just the publish call.

When to keep a standing dashboard

The pattern has limits, and the loudest version of it overreaches. Dashboards are not dead. Keep the governed, recurring views that many people read and trust: the revenue board, the reliability dashboard, the numbers a team lines up on every morning, backed by a semantic layer and agreed definitions. Those are guardrails. Swapping them for an agent improvising a fresh page each time trades consistency for novelty.

The throwaway pattern is for the long tail: 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 building a dashboard you would abandon, or doing it by hand. Now the agent builds the page on demand, and all it needs from you is somewhere private to put it for as long as it matters.