OpenTree DashboardSign in

$ date -I # 2026-07-25

An agent can build the dashboard now. It still has to live somewhere.

Ask an agent for "a page that shows error rate by endpoint for the last six hours" and you get one, correctly, in under a minute. The interesting consequence is not that dashboards got easier to build — it is that they got cheap enough to throw away, which changes what hosting them means.

Build it, read it, discard it

The old economics of a dashboard were dominated by construction: pick a tool, model the data, arrange the panels, maintain it as the schema drifts. When construction is a prompt, the rational move is to build a fresh one per question rather than maintain a general one that answers all of them badly.

Why disposable is the operative word

A permanent dashboard accumulates obligations: it must keep working, its numbers must stay correct, and someone must own it. A dashboard that exists for one afternoon has none of those properties, and pretending otherwise is how organisations end up with forty stale panels nobody trusts. Expiry is not a limitation here, it is the feature.

The step that is still missing

The HTML has to get in front of a human. Pasting markup into a chat is not it, an attachment is not it, and standing up a project on a deploy platform for something that dies tomorrow is definitely not it. What is wanted is one call that returns a link — and a link that stops existing on its own.

End to end, in the loop

The agent already has the data; the publish step is one more tool call:

# in the agent's loop, after it has written the file
publish_html { content: "<html>…</html>", expires_in: "24h" }
# → { url: "https://read.botook.ai/s/…", token: "…" }

# next question, same artifact, same link
update_site  { id: "…", content: "<html>…</html>" }

The reader keeps one bookmark across every revision, and the link closes itself the next day unless someone asks for more time.

When to keep one after all

Some dashboards deserve permanence: the ones an on-call rotation depends on, the ones with an audience larger than the person who asked, the ones whose numbers feed a decision that will be re-litigated later. Pass an expiry of never, or better, rebuild those on a real analytics stack — this is a place to put a document, not a data platform.

What you can tell afterwards

Since the artifact is a deliverable, the useful signal is whether the person you sent it to actually read it: opens, unique viewers, dwell, scroll depth, read-to-end, and where in the page attention landed. If the answer is "opened for four seconds", the dashboard did not fail — the framing did.

Can the dashboard query live data?

Not from here. What is hosted is a document; if it needs to refresh, it has to call something that is up, and the strict CSP means it cannot pull scripts from a third-party origin. In practice the agent re-runs the query and republishes.

What is the default expiry?

Seven days for a keyed publish, twenty-four hours for an anonymous one. Both are overridable per link, including to never.

That is exactly what update_site is for. Same token, new bytes, no history.

How do I stop these piling up?

They expire by default, and the purge deletes the row and the object rather than hiding them. list_sites shows what is still alive.

Keep reading