protocontent.com

01 The problem

Agents now emit single-file HTML constantly — plans, dashboards, diffs, reports. The format is right (see §02). The distribution is broken. The artifact lands as a local file:// path, and a path is not a link. Three concrete failure modes:

Every path leads to the same primitive: a real URL, hosted off your machine — and, importantly, on an origin that can't reach back into your stuff.

02 Why HTML

The premise comes from Thariq Shihipar's "The Unreasonable Effectiveness of HTML". The argument, compressed:

The post nails the generate half and leaves distribute as a hand-wave: "as long as you upload it…" — but never says how. protocontent is that missing verb.

03 The concept

Your agent already writes files. protocontent is the same primitive — write a file — except it lands at a shareable URL instead of in your repo. It's the home for everything an agent produces that isn't meant to be committed: plans, prototypes, dashboards, screenshots, generated images, scratch notes. We start with HTML because it's the richest format, but the model is content-agnostic — a remote scratch filesystem for the agent's non-repo output. Three properties define it:

Mental model: publish(file, name) is a remote write_file — cheap, idempotent, throwaway. Call it again with the same name to overwrite; many files accumulate in the session's one live directory page (§10).

04 Architecture

The load-bearing idea is ①: the agent pushes the HTML to the control plane. Nothing depends on the agent's machine being reachable — which is precisely why cloud and mobile work. The control plane never serves the artifact itself; it writes to storage, and a separate content origin renders it and pushes live updates to viewers (§08, §10).

05 Publish flow

tool call · from the agent

// Agent calls the MCP tool with the artifact it just generated
publish_html({
  path:  "./plan.html",                     // bridge reads the file (or a folder) — no blob in context
  name:  "plan",                            // optional, readable; becomes the path
  ttl:   "7d"                              // optional, default 7d
})

response · back to the agent (and the human)

{
  "url":        "https://amber-canyon-7f3.protocontent.app/plan",
  "space_url":  "https://amber-canyon-7f3.protocontent.app/",   // the live session page
  "markdown":   "[plan ↗](https://amber-canyon-7f3.protocontent.app/plan)",
  "edit_token": "et_9f3a…",   // re-publish same name to update in place
  "expires_at": "2026-06-12T20:00:00Z"
}

Re-running publish_html with the same name overwrites the page at the same URL — the "it just gets updated" behavior. The agent surfaces the pre-formatted markdown link inline (a tappable title where the UI renders it, a clean …/plan URL where it doesn't), and drops space_url into its closing summary.

06 Key decisions

07 Tool API

URL scheme — try it

A random subdomain is the session (and the capability); the readable name is just the path. Drag the controls:

08 Security model

The original instinct — "off the URL so that you aren't able to access your shit" — describes the single most important rule in this space: untrusted, agent-generated HTML must not share an origin with anything that holds your identity. Defense in depth, outermost first:

09 Prior art

Every mature system converges on the same intersection: push to a store → random subdomain on a dedicated origin → sandbox + CSP → no viewer account → optional TTL. protocontent is that consensus — packaged cross-agent, with a live session page.

10 Beyond HTML

The primitive — push bytes → sandboxed capability URL + TTL — doesn't care that it's HTML. HTML is the wedge; the category is an ephemeral host for everything an agent makes and never commits: images, markdown plans, data, screenshots, several linked HTML files.

The session space = the unbundled artifacts panel

The unlock is grouping. Give each agent session a space, and everything it publishes shows up as a live, auto-generated index at one URL — the Claude.ai / ChatGPT artifacts panel, but hosted, portable, and openable on your phone. The index is itself an unreasonably-effective HTML page — meta again.

// one space per session — every publish lands in it
https://amber-canyon-7f3.protocontent.app/        ← live index of the whole task
  ├── /plan            updated in place
  ├── /schema.png      native render, no sandbox
  ├── /before-after
  └── /notes           rendered server-side

Stance: build the general primitive, expose a narrow surface. Storage and serving are MIME-agnostic from day one; a new type only ships when it clears the bar "is viewing this painful today?" — images clear it instantly, arbitrary files don't. The per-session space is what turns a pastebin into something worth the "Dropbox for agents" comparison — without having to claim it on day one.

11 MVP & stack

The whole MVP exists to prove one 20-second moment: kick off a cloud agent, open the session URL on your phone, and watch artifacts appear as it works. Everything below is in service of that. Every component is a first-party Cloudflare primitive — one vendor, one wrangler deploy.

Stack — every need → a Cloudflare primitive

All comfortably inside Cloudflare's free / low tiers at MVP scale. No niche SaaS, no bare metal — one account, one dashboard, one bill.

Build phases

12 Decisions