Jian
A hand-drawn ink illustration on a dark ground. A small hooded figure with an empty face stands between a sketched laptop on the left and a server cabinet on the right, with a dotted arc rising from the laptop over the figure to the rack.

Tools · 11 Oct 2026 · 6 min

Hosting an agent is the hard part

An agent needs a machine it can act on freely — a sandbox or a VM. A terminal is only how you aim it, and reaching everyone means moving the machine.

Ask an engineer to run an agent and you get a short list of commands. Ask anyone else and you get an afternoon of installing things.

Imagine ChatGPT had arrived as a terminal command.

Almost nobody would have installed it.

So the question is this: how do we make an agent reachable by someone who will never install a command-line tool? A binary they download is one answer, and it is a nicer install — the agent still ends up on their machine. A website is the other, and it means the agent runs on a machine you keep alive, not one they do. The rest of this post is about that one.

That is the platform: a place the agent runs that the person using it never has to install, own or maintain.

Today: build it yourself first What we want $ npm i -g my-agent $ my-agent login $ my-agent run ./repo a machine you can install on a terminal, open an API key from somewhere a config file nobody sent you agent.example.com Open the agent or Or a download, which still runs on their machine.
The left side is a list of things you have to be able to do. The right side is a link. A download is a friendlier version of the left.

What changes for the person

Hosting an agent is usually described from the inside — a machine, an image, a policy, a bill. What the person using it notices is smaller than that: two things people do on a laptop without thinking, and what each becomes when the agent is somewhere else.

Getting in. On a laptop this is an install: a CLI, a runtime, a version to keep current. Hosted, it is an account and a link, and nothing on their machine to maintain. That account is doing more work than the install ever did: it is how they are known, and how everything the agent does is attributed back to them.

A hand-drawn sketch of a small hooded figure standing beside a tall, unsteady stack of plain boxes, with a thin circular arrow looping around the stack.
One is a thing they install and then keep current. The other is a URL.

Handing it the work. A laptop agent is useful because the machine is theirs. It reads the directory they are standing in and acts as them, with their keys. Its skills come off their own disk, its tools are whatever their $PATH holds, and the MCP servers it talks to are the ones their config file names — over their network, with their credentials. None of that belongs to the agent; all of it belongs to the machine.

Host it, and all of it goes at once. They choose what it may read, they authorise what it may do, and a skill or an MCP server stops being something on their disk and becomes something the platform has to host and let them add.

And the agent stops being them. On a laptop it holds their keys, so it can already do everything they can, and none of that is separately revocable. Hosted, it needs an identity of its own, scoped and expiring — the first time anyone asks what it may do, and the first time any of it can be taken back. That question does not go away once answered: which services it may reach, how much of each, and which actions wait for them. Reading a file and sending a message are not the same permission.

On the laptop Hosted their machine the working copy their mcp config skills/ and tools the agent the image one folder they gave it the agent a skill or an MCP server
On their machine the agent reads what they read, and a skill or an MCP server is something they point it at. In an image there is one mounted folder, and anything else has to be put in from outside.

Neither is a hard job on its own. Together they are what hosted means from the outside — and they are only the visible half.

The trade

A web service does what you wrote; an agent writes the program and then runs it. That is why everything behind those two steps is a system somebody has to build, own and keep running: a sandbox running code nobody reviewed, an identity that is not theirs, an egress policy, a machine thrown away when the run ends.

So it is worth asking: do agents need hosting at all? Anyone with a terminal is better served locally, for the price of a directory and a config file.

What hosting buys is usability for everyone who would never get past the setup. Nobody learns a tool they cannot install — worth an audience you do not otherwise have, and a poor trade for the one you already do.

Bye.

Written with the help of an AI assistant, based on experience and research.

Comments

Discussion lives on GitHub — you'll need a GitHub account to post.