Why AI agents need a publish primitive.

The granularity mismatch

The hosting tools engineers reach for today were built for products: long-lived, versioned, deployable. Vercel, Netlify, GitHub Pages, Cloudflare Pages — each starts with a project, ties it to a Git remote, builds it through CI, exposes it at a stable URL. That model works beautifully when the unit of work is "a thing my team maintains for a year."

It works terribly when the unit of work is "a thing an agent wrote five minutes ago and you want to send to one person." The setup cost — project + Git + DNS + CI — is larger than the artifact's entire lifecycle.

Where AI agents make the gap acute

Three forces compound:

1. Volume. A single Claude Code or Codex session can emit a dozen HTML files: a spec, a perf report, a tiny editor, a diff viewer, a request-shape inspector. None warrants a project. All warrant a URL.
2. Iteration. Agents revise. The same artifact gets eight versions in an afternoon. If each version is a new URL, your teammate's bookmark is stale before they open it.
3. Privacy. Agent output frequently embeds real data — API responses, customer rows, prompt context. Public-by-default is no longer a defensible baseline.

What a publish primitive looks like

Concretely, the primitive needs four properties:

• One call. No project to create, no build to run, no DNS to point. The agent calls a tool; the URL exists.
• Replace-in-place. The same URL across every revision of the same artifact. Bookmark survives.
• Private by default. Unguessable URL as the baseline; optional password or email-domain gate per link.
• Deletable. Auto-expire by default; agent can also delete on demand. Short-lived artifacts shouldn't clutter forever.

Why this can't just be "a feature" of an existing host

It could be — and a few hosts are starting to bolt it on. But the project model isn't a feature you remove, it's an architectural decision. A host built around projects will keep nudging artifacts toward project-shaped behaviour (folders, dashboards, branch previews, environment variables) because that's where the rest of the product expects them to live.

A primitive built for one-off artifacts can stay small. Seven verbs is enough. Anything more is a workflow you didn't need.

What changes when the primitive is right

The agent loop tightens. Specifically:

• The agent calls a tool the same way it'd write a file. No procedural switch.
• The URL is a stable handle the agent can hand back into the next message context.
• The team bookmarks once and treats Stacktree links like Notion links — they auto-update.
• Privacy gates live at the link layer, not the org layer, so a developer can prove value before involving IT.

Where the primitive isn't the right answer

Some artifacts deserve the project model: anything you ship to customers, anything that must be archived forever, anything that needs A/B testing or branch previews. The publish primitive isn't a replacement for those — it's a complement for the long tail of agent output that doesn't need any of it.

The bet

If agents continue to emit HTML at the rate they currently do, the publish primitive becomes as load-bearing as the file-write primitive was for IDEs. We're betting it does. Stacktree is the bet.