An agent builds it. Somebody opens it.
An agent builds something in a folder, deploys it to a live URL in seconds, and real people use it from their phones. You get a page you can send to someone, not a transcript you have to explain.
Set yourself up on Super Artifacts: read https://superartifacts.app/s/K7M2QXVB and follow it.Your dashboard mints the code. It is single-use, it expires in ten minutes, and every redemption shows up as an agent you can revoke.
How it works
Three moves, and only the first one involves you.
Pair an agent
The agent fetches its own instructions, introduces itself, and gets back a key. You never install anything and never copy a credential by hand.Paste this at the agent you already use Set yourself up on Super Artifacts: read https://superartifacts.app/s/K7M2QXVB and follow it.It deploys what it built
A folder of files becomes an address. The bytes the agent sends are the bytes that get served — there is no bundler, no framework convention, and nothing to configure.One request, no build step curl -sS -X POST https://api.superart.page/deploy \ -H "Authorization: Bearer $SUPER_ARTIFACTS_KEY" \ -d @deploy.jsonYou decide who can open it
A fresh deploy is readable by you and nobody else. Name the people who should see it, or make it public on purpose. Either way it is a decision you took, not a URL that got forwarded.
What it does
Five things the platform does that an agent writing HTML on its own cannot.
- DeployOne request turns a folder of files into a URL somebody can open on a phone.
- VersionsPublishing moves a pointer. Rolling back and rolling forward are one operation.
- AccessPrivate by default. Sharing is a grant you make, never a URL that leaked.
- AnalyticsWhether anyone read it, on what, and whether it threw an error while they did.
- AgentsOne line pairs an agent. It fetches its own instructions and deploys on its own.
The platform runs no inference
You write the artifact. Every byte of it comes out of your agent’s model, on your tokens, in your environment. Super Artifacts stores the files and serves them at a URL — that is the whole of what it does.
There is no endpoint here that takes a prompt and returns a page, and there is not going to be one. It is stated this plainly because it is the single most expensive assumption available: an agent that expects the platform to generate the artifact will post a prompt and get back an empty page.
Addressed by id, served from our own edge
An artifact lives at superart.page/{id}/ — a UUID the server assigns, not a subdomain and not the name you gave it. That is an access-control decision: a hostname per artifact is its own origin, and an origin the platform cannot set a cookie on can only ever be protected by “know the URL”.
Version history is a pointer rather than a redeploy. Publishing an earlier version moves the pointer at an immutable record that was never deleted, so rolling back and rolling forward are the same operation and neither is a one-way door.
What is not built yet
The product’s full shape is that data an artifact collects flows back to the agent that built it. That half is not shipped. There is no endpoint an artifact can post a survey answer or a tracker entry to, and no way for an agent to read responses back over MCP. An agent told otherwise ships a survey that silently discards every answer, so the craft guidance refuses to describe it.
Two smaller gaps, named for the same reason: there is no per-artifact analytics report yet — the view and error pipelines are live and the gallery shows counts, but the page that breaks them down is not built — and there is no super command-line tool, only the HTTP endpoint it would wrap.