OpenTree DashboardSign in

$ curl -F file=@report.html

Putting an agent's report somewhere a person will actually read it

Reports are the most common thing agents produce and the least well served by the tools around them. They are too long for a chat message, too formatted for plain text, and too full of real data to sit on a public URL.

The reports that fit

The loop

# generate → publish → send. The middle step is one request.
curl -X POST https://read.botook.ai/sites \
  -H "Authorization: Bearer otr_live_YOUR_KEY" \
  -F file=@weekly-report.html \
  -F expires_in=30d

# next week, same URL
curl -X PUT https://read.botook.ai/sites/SITE_ID \
  -H "Authorization: Bearer otr_live_YOUR_KEY" \
  -F file=@weekly-report.html

Markdown works identically — send a .md and it is rendered to a self-contained HTML document at publish time, so the link is a page rather than a wall of hashes.

Privacy posture

Reports are the category most likely to contain something that should not be public: customer names, revenue figures, security findings. The defaults assume that. Unguessable URL, noindex and noai, no-referrer, a content scan before storage, and an email-domain gate one call away when the readership is "people with a company address".

What it replaces

Mostly three habits: pasting a report into a chat thread where it is unreadable and unsearchable a day later; attaching an HTML file that recipients are right to distrust; and standing up a documentation site for something with a two-week half-life. A link that expires on its own does the job of all three without leaving residue.

Reading it back

A report nobody opened is a process problem worth seeing. Opens and unique viewers say whether it was read at all; read-to-end rate and the attention map say whether the conclusion at the bottom was ever reached. If it never is, move the conclusion.

Can I publish markdown directly?

Yes. A .md file, format: "markdown", or a text/markdown body all render at publish time. Raw HTML inside is escaped rather than executed.

Can a scheduled job publish these?

Yes — it is one authenticated request, so cron, CI or an agent loop all work. Give the job its own API key so revoking it is one call.

As long as it is true. Thirty days suits a weekly; an incident write-up that becomes reference material is a fair case for never.

Can the recipient reply on the page?

Turn on the toolbar with set_agentation and readers can leave notes anchored to a paragraph. You read them with list_feedback and close them with resolve_feedback.

Keep reading