When you ask an AI agent to publish your site, it does not go looking for the best host. It reads a handful of files a service leaves at fixed addresses, written for machines rather than for you, works out which way in it can use, and stops at the one decision it is not allowed to make: your permission.
This is for people who have watched that happen and wondered what the agent was reading. No setup commands, because the connection guides have those.
Your agent is not shopping for a host
Most people describe a search: the agent surveys the options, weighs them, picks the best. The real answer is duller.
There is no catalogue and no registry. No index of publishing services, no ranking, no agreed way for a service to announce "this is what I do" in a form every agent understands. Google, announcing its own attempt at fixing that in June 2026, put it plainly: "Today, there is no standard way to answer those questions across organizations." Its proposal puts a catalogue file at a fixed path on your domain, one proposal among several.
So an agent arrives at a service in one of three ordinary ways. You named it. It is already connected, because you set that up once and forgot. Or you handed it an address and it read what was there. That is the whole list.
Which means the interesting question was never how an agent chooses between hosts. It is what happens once it has an address.
"Where to deploy an agent" usually means where the agent program itself runs: a server, a container, a managed runtime. This runs the opposite way, your agent finding somewhere to put the website it just built.
What a machine reads at a fixed address
Three things, all plain text.
The first is an index at the root of the site. Ours sits at /llms.txt: a short file saying what the service is, who it is for, and how to connect. Where that file comes from and whether anyone reads it is a separate article. What matters here is that a person wrote it for a machine.
The second describes how to ask permission, and it is a requirement rather than a
convention. The Model Context Protocol's authorization specification states that a server
"MUST implement the OAuth 2.0 Protected Resource Metadata (RFC9728) specification to indicate the locations of authorization servers."
In practice the agent makes a request with no credentials, receives an HTTP 401, and the
refusal itself carries the address of a small metadata document. Failing that it falls
back to a fixed path, and ours answers at /.well-known/oauth-protected-resource. Either
way it learns where to send you before it has been granted anything.
The third is the list of tools the connection declares once open: named actions, each described in ordinary English. What that protocol is is a longer story. What matters here is that the descriptions are prose, and the model reads them as prose.
None of this requires an agent to know about us in advance, which is the point of fixing addresses by convention.
The choice is not "which host" but "which way in"
So the agent has an address and has read what is there. Now the only real choice in the sequence, and it is not between services.
The same split decides what a chat-bound builder can hand over at all. A page built in Gemini Canvas has to be copied out of the panel by a human before any agent can publish it, because nothing in that tab can reach your files. Some vendors answer that by hosting the result themselves, which is what ChatGPT Sites does.
Some tools can read and run things on your computer. Some cannot, because they live in a browser tab. That single difference decides how a connection has to work, and our index asks an arriving agent to sort it out for itself:
There are two ways in. Pick by what you can do, not by what you are called: if you can read and run things on the owner's computer, use the local connection; otherwise use the hosted connector.
A real line from the file, written by hand for a reader that is not human. "Not by what you are called" does the work: a tool cannot reason usefully about whether it counts as a chat or a coding agent, and it does not need to, because it can answer a question about its own capabilities in one step.
The two answers lead somewhere genuinely different. A tool without file access gets a connector address and works on a draft, writing files into it one at a time, then publishing it by number and handing you the live address together with that version's own page for remarks. A tool with file access starts a connection on your machine and works with whole folders: it names the folder, the connection uploads the contents, and nothing gets pasted through the conversation.
Both are MCP connections. If your tool also supports Agent Skills, that is a different layer, instructions rather than tools.
There is a third branch most instructions forget. A tool might read all of this and still be unable to act, having no shell and no access to its own settings. The file says what to do then, as an instruction rather than a hope: do not stop, do not hand the problem back, tell the owner exactly which screen to open and what to paste, and carry on once they confirm. Failing usefully is a behaviour you have to ask for. Left alone, a stuck agent apologises.
Where the agent stops and you start
Up to here the agent acted autonomously. This is where that ends.
The first request that touches your account is refused. Not delayed, not queued behind an approval, refused, and the refusal comes back carrying a confirmation link and a short code. The agent hands you the link.
You sign in with a one-time code sent to your email. The page tells you which connection is asking and what it will be able to do: your projects, and publishing sites in your name. You approve or decline. Then the agent tries again, and it works.
Nothing travels back the other way: no key to copy, no token to paste into the chat, nothing to keep safe. A tool connecting from a browser follows the same shape.
That is the two-level decision in full. The agent decided how to connect. You decided whether it may.
Why a refusal is better than a queue
The refused request is not run for you afterwards. Once you approve, the agent has to make the call again, which looks like a wasted step and is deliberate.
Permission applies to what happens next, not to what something tried while you were not looking. If approval could reach backwards and release an earlier request, the thing you approved and the thing that ran would be two events joined by an assumption. Keeping them apart costs one repeated call and buys a straight answer to "what did I agree to".
We learned the second half the hard way. The rule about which connection suits which tool used to live on our landing page, as a question we asked you to answer before showing you anything. It was a question about our architecture wearing the costume of a helpful choice, and it belongs in a file machines read. The same admission, pointed at you rather than at the tool, is that you should never have been asked.
What this still gets wrong
Three things, none close to solved.
A tool can read the instructions and still get stuck. That is why the fallback text exists, and it is a request rather than a guarantee.
More tools means worse choices. Measured, not folklore. The RAG-MCP paper (Gan and Sun, May 2025) reports tool selection accuracy of 13.62% against a full catalogue, rising to 43.13% when candidates are filtered first, with prompt tokens cut by more than half. Both numbers are bad. A good argument for connections that do one job with a short named list of actions.
Nobody has to read any of this. The root index is a proposal, not a standard. The one mandatory piece is the authorization metadata, and only for services that speak the protocol. A service that publishes nothing is not doing anything wrong, just invisible to an agent nobody told about it.
We also cannot tell you how well it works for us. We do not measure requests to the index, and a number we have not collected is not one we will quote.
The short version
The mechanics are boring on purpose: text files at agreed addresses, a refusal that carries an address, a capability question with two answers. The shape is what matters. An agent can carry a site from an idea to a live address, and there is exactly one door in that corridor it cannot open. Removing that door for a smoother demo takes away the only guarantee you have.
Let your tool work out the rest
Paste one line into the tool you already use. It connects itself, you approve access, and it publishes. Or describe the site in Birta's chat and its own agent publishes it.