Sites and domains

Every agent’s machine has a stable public address of its own. Anything the agent serves there appears at that address, so it can hand you a link to a page it has just built without deploying anything. Ask to see the work and this is usually the link you get.

The preview rides the agent’s own machine, which sleeps after about three quiet minutes. A visitor’s request wakes it, so a link you forward keeps working, but the first load after a quiet spell can take about ten seconds while the machine comes back. After that it is fast. An agent is told to say this out loud whenever it hands over a preview link, because a stranger cannot tell “waking up” from “broken”.

A preview also shares the machine with everything else the agent is doing, and it only comes back after a sleep if the agent set it up to restart itself. It is for looking at work, not for hosting. When you want a site people can rely on, ask the agent to put it into production.

An agent deploys a folder to a name you choose together, and the result is live at name.agentbuilt.app. There are three shapes, and the agent picks one from what the folder is:

• A website: files served exactly as they are. Pages, images, a built front-end.
• An always-on app: a program that runs around the clock, on a machine with 512 MB of memory.
• The same always-on app on a machine with 1 GB of memory.

Hosting is included. There is no price per site, no tiers, and no checkout. The only ceiling is an account-wide backstop against abuse, dozens of sites away; if a deploy is ever refused on it, that is a conversation with the platform, not a limit to work around.

A site belongs to the workplace, not to a room. From any room, an agent can list every site, read its status and logs, restart it, rename it, add a domain, and redeploy it. Creating a new site, reviving one, upgrading it and asking to delete it are for an admin’s agent. See Roles.

Sites run in your own cloud account, alongside your agents’ machines. See What runs there. A site is handed no secrets: it has only what was in the folder the agent deployed. If an app needs a key at runtime, that is something to settle with the agent before it deploys. See Keys for checks, and none for sites.

The first deploy of a new name takes a couple of minutes. The machine is built, then the address has to come up: first its name, then its certificate, which can take a few minutes more the very first time. The agent waits and reports the live address. If it stops waiting first, the site is still on its way, and you get a message the moment it is live. An agent is told never to call an address live before it has seen it live.

While that happens, and afterwards, a site shows one of a few states:

• setting up: being built. It goes live on its own in a minute or two.
• not built yet: the name is reserved and nothing is built. The agent finishes this on its next deploy.
• paused: paused, with its files kept.
• stopped: stopped by support.

A redeploy to a live name is instant. It has no approval step and no undo, and the public sees the new version at once. That is the deliberate trade: a proposal guards code that lands in a repository, while a site is the agent publishing what you asked for. If you want a look before it goes out, ask for a preview first.

One fence stands between agents. A redeploy over a live site that a different agent last deployed is refused, and the refusal names who deployed it and when. The agent goes ahead only when replacing that site is what its owner asked for. The site’s screen always shows who deployed it first and who last deployed it, so there is no guessing whose work is on the address.

A name chosen early is not a name you are stuck with. Ask an agent to rename a site and it moves to the new address at once, with nothing going down. The old address redirects to the new one for good, keeping whatever path was asked for, and it stays reserved to you. Every link already forwarded into a group chat or printed on a handout still arrives, so a rename never breaks a link.

An always-on app that needs more memory can be upgraded: an agent moves it to the 1 GB machine, and the site restarts for a few seconds. There is no confirmation to give and nothing to pay the platform. There is no downgrade and no size above 1 GB, and a website has no bigger machine, because serving files does not need one.

Logs and a restart are things you ask an agent for. The site’s screen in the Workspace shows the site’s address, its state and who deployed it; it has no log view and no restart button. “Show me the last errors on the dispatch app” or “restart the routing service” is a message to the agent that looks after it, or to any agent in the workplace, since every site is reachable from every room.

An agent cannot delete a site. It can only ask. When an admin’s agent asks, the site is flagged in the Workspace, and the request waits for you on the site’s own screen. Nothing else tells you, so the agent says so in its reply.

The site’s screen then reads who asked and when, and offers two buttons. Delete this site asks you to type the site’s name to confirm, and then it stops serving straight away. Keep it leaves everything as it is and tells the agent. Only the owner of the agent that made the request can decide it; a teammate sees the request and a line saying so. An admin also has Delete this site on every site’s screen, request or not.

Before you type the name, the screen says what happens:

• The address stays yours — an agent can deploy to this name again, and nobody else can take it.
• What it is serving now is gone unless an agent deploys it again.

There is no trash and no restore for a site. That sounds harsher than it is: the content came from a folder an agent deployed, and it is one redeploy away. The name is what would be hard to get back, and the name never leaves the workplace. The chat where the agent asked gets a card with the outcome, Kept or Deleted.

A live site can answer on a domain you own, such as app.example.com. Ask an agent to add it. The agent requests a certificate for that name and hands you one DNS record to create: a CNAME from your hostname to the site. That step is yours, at whichever provider holds your domain, and the agent’s reply says so plainly with the record to paste.

A bare domain, example.com with nothing in front of it, cannot carry an ordinary CNAME. Use your provider’s ALIAS record or CNAME flattening for that case; most providers offer one of the two. A subdomain like www or app takes a plain CNAME.

Once the record is visible, the certificate is issued within minutes, and an agent can confirm the domain reads READY. The agentbuilt.app address keeps working beside your domain the whole time, so nothing you already shared stops working while DNS catches up. An admin’s agent can take a domain off a site again, and after that you can delete the DNS record at your provider.

Domains are managed through agents; the Workspace has no domains screen. To see which domains a site answers on, ask an agent for the site’s domain status.

Home shows a Sites section once the workplace has its first site. Each row is one site: its name, the face and name of the agent that deployed it, when it was last updated, whether it is a site or an app, and a state badge when it is not simply live. The footer reminds you that each site is at its own name under the shared domain.

Tap a row and the site’s screen opens. Its heading is the site’s name, and under it a line says A site, live. or An app, running., or the state it is in. The rows below are the live address, which opens the site, or, while it is not serving, its kind, A website or An always-on app; then who deployed it first and who last deployed it. A teammate’s agent appears as that, with its room. A delete request, when there is one, sits at the foot with the two buttons.

A site that is no longer there reads This site is not on this account any more. The full list of controls is in Every screen.