Stacktree
By · Founder, Stacktree · Last updated
concept

One URL. Every revision. That's agent-loop hosting.

When an agent iterates 30× in a session, you don't want 30 URLs. Agent-loop hosting is a publishing model where the URL is stable, the content swaps underneath, and the viewer's bookmark always shows the latest version.

Get started free

What is agent-loop hosting?

Agent-loop hosting is a static-HTML publishing model designed around the way AI agents actually work: by revising the same artifact many times in a single session. The hosting service guarantees that the URL stays stable across revisions, so the link a human bookmarked at minute 1 still shows the latest version at minute 30. Stacktree exposes this as one MCP tool call: update_site.

The loop, by the numbers

The problem in three lines

  1. An AI agent writes a 600-line HTML report.
  2. The agent revises that report 12 times in the next 30 minutes — adding sections, fixing numbers, restyling.
  3. Twelve new URLs is twelve broken bookmarks for the teammate you're sharing it with.

The "send the latest link in Slack" workaround is what teams do today, and it's exactly the kind of friction that should be a primitive instead of a habit. The right answer is: one URL, all twelve revisions, viewer refreshes when they want the latest.

Why every other host gets this wrong

  • Tiiny Host, Pastebin, ngrok shares. Each upload is a new URL. Replace-in-place is paid or impossible.
  • GitHub Pages. The URL is stable, but the rebuild lag (30 s – 5 min) breaks the iteration cadence, and the unit of update is a commit.
  • Vercel preview URLs. Brilliant for CI, but every deploy is a distinct preview URL by design. The "production" alias is stable, but it's a heavy primitive for a five-minute artifact.
  • Notion / Linear / GDocs. URL is stable, but the content has to be expressed in their flavour of rich text. Agent-emitted HTML rarely survives the round-trip.

What Stacktree does

Stacktree exposes update_site as a first-class verb in its MCP server and HTTP API. The agent calls: 

PUT /sites/{slug}
Content-Type: text/html

<!doctype html>…

The R2 object is replaced atomically, the edge cache is purged, and the same URL serves the new content on the next request. No new slug, no new token, no new "see V3" message in Slack.

The viewer-side contract

The deal with the viewer is: this URL always points to the latest version. They bookmark once. They refresh when they want the current state. If the artifact has been deleted or expired, they see a clean 404 — never a stale cached page silently. That's the contract that makes agent-loop hosting actually trustworthy.

When you shouldn't use it

  • Compliance-archived artifacts. If you need to prove what V7 looked like in March, you want an immutable URL per revision. Stacktree can do this too — just call publish_html for each new revision instead of update_site.
  • Public marketing pages. Real CDN, real DNS, real cache-control headers. Stacktree handles small-to-medium static loads fine, but a viral homepage is not its job.
FAQ

Frequent questions

What is agent-loop hosting? +
A hosting model where the URL is stable across revisions. The agent calls one tool to publish, then calls a second tool (update_site) every time it revises the artifact. The viewer's bookmark always shows the latest version.
Why does this matter? +
Because agents iterate. A 30-message session might revise the same spec 12 times. If every revision is a new URL, your teammate has 12 stale bookmarks. If the URL is stable, they have one that always works.
How is this different from a normal static host? +
Most static hosts treat each upload as a new artifact (Tiiny Host on free tiers, S3 pre-signed URLs, Pastebin). Some hosts let you replace the file but force a redeploy that bumps cache (GitHub Pages, Vercel). Agent-loop hosting is purpose-built for the case where the URL must not change.
Does the agent need write access to keep the URL stable? +
Yes — the same slug + an authentication token. Stacktree's MCP server handles this automatically: it stores a token at ~/.stacktree/credentials and binds the slug to the account on first publish.
How does this play with caching and CDN? +
Stacktree pushes new content to its edge cache on every update_site call. End users see the new version on the next request; there's no manual cache-bust step.
Can multiple agents update the same site? +
Yes — they just need to share the slug and an API token. Useful when one agent generates the data and another renders the report.
Keep reading

Related guides

References

Sources and further reading

Give every revision the same URL.

Install the MCP server. The agent does the rest.

Sign up free →