Choosing an agent host: a fitting guide for your personal AI stack
We read what people actually say when they set up or switch a personal AI stack. Almost nobody asks which host has more features. They ask how much of a weekend it costs, whose computer it runs on, and whether their setup survives leaving. Here is how to answer those three about yourself, then pick.
TL;DR
Choose an agent host by fit, not by feature score. We searched X for people setting up or switching a personal AI stack, and the pattern is consistent: almost nobody compares capability tables. They talk about how long setup really takes, whose machine the agent runs on, and whether their configuration survives a move. Answer those three about yourself first. On four of the six hosts we have shipped adapters into, installing a single plugin means supervising a long-running background service, which is the cost the five-minute demos leave out. If that sounds like more than you want, that is useful information, and it points at an in-process host like OpenClaw.
When we wrote what to install for a personal AI stack and in what order, we called the host the one decision that is annoying to reverse later, said to pick it deliberately, and then never said what deliberately means. This is the guide we owed you for that sentence.
There is no best ski boot. There is a boot that fits your foot, and the review-winning pair hurts because it was measured against somebody else's. The number that decides it is not on the box. It is on you. Agent hosts work the same way, so before handing you a shelf, we went to find out what people actually measure themselves on.
What people actually ask before they pick
We searched X for posts about installing, setting up or switching a personal AI stack. In the recent window there were 543 of them. A lot is promotional noise, but the substantive posts cluster tightly, and the clusters are not what host comparison tables are written about.
The setup burden, over and over. One developer put it more precisely than any vendor page does:
Most "self-host an AI agent in 5 minutes" demos skip the part that actually takes a weekend. The hard part isn't choosing the model. It isn't writing the prompt. It's everything around it.
The list that followed was SSH and Docker and server setup, API keys and OAuth, permissions and allowlists. Not one item is a capability. Every item is an ongoing obligation.
How much assembly is required. The clearest one-line comparison anyone made was not about what the hosts can do:
Hermes is opinionated and comes with everything setup. OpenClaw is not opinionated.
Whose computer it runs on. This is the live argument, and people frame it as rent versus own. xAI's own account describes the split plainly: Grok Bot is a managed product with a dedicated cloud computer and Grok models only, while OpenClaw is a self-hosted runtime on your hardware, model-agnostic. One person watching search volume noted that "convenience will almost always win", which is probably true and is also not an argument about capability.
Whether you can leave. One reply put the criterion better than we had:
When an OpenClaw setup moves to local models, do agent state, tool permissions, and integrations move cleanly too? That is the portability test that matters.
How you reach it. Several people described the phone as the point of the whole thing, one calling the ability to talk to their agents from a phone the killer feature. Others run theirs through Telegram. Nobody described sitting at the machine the agent runs on.
What it costs to keep running. One person reported an agent box built from a 2012 Mac mini with a new SSD and Linux on it, costing about three dollars a month in electricity, running around the clock.
None of that is a feature comparison. It is a list of obligations, and obligations are what a host actually sells you.
The question before the shelf
Before choosing among self-hosted hosts, decide whether you want a self-hosted host at all. Managed products exist, they are genuinely easier, and picking one is a legitimate answer. What you trade is the thing the same posts keep circling: whose hardware it runs on, which models you may use, and who holds your credentials when your agent logs into something on your behalf.
That last one is not hypothetical. One person in the sample described trying to get an agent to log into a delivery account and fill a cart from a family shopping list, and reported it as either unsuccessful or an extremely painful setup. Whoever operates the runtime is who that credential question lands on.
If you want the agent on your own machine, the rest of this guide is the shelf.
The shelf: six hosts, one line each
These are the six our marketplace adapters cover. Read this as the shelf, not a ranking.
| Host | In one line |
|---|---|
| OpenClaw | Behaves most like an app. Plugins load inside the host process, so there is nothing extra to run. |
| Hermes | Python-native and opinionated. Plugin dropped on a discovery path, holds its own outbound connection. No daemon to babysit. |
| nanobot | Event-bus shaped. Clean if you already think in channels and subscriptions, and you run a daemon for it. |
| IronClaw | Rust, MCP-based. The host spawns your extension per session. Daemon required. |
| Moltis | Rust, MCP-based, same shape as IronClaw with its own config model. Daemon required. |
| ZeroClaw | Rust. Spawns a fresh isolated agent session per wake with a throwaway context. Daemon required, strongest isolation. |
One scope note before you read on
The six-host comparison here is our marketplace adapter tree. Our shopping plugin, SIL, ships on OpenClaw only. Where this guide shows a worked plugin install, that is OpenClaw and SIL. Where it compares six, that is the marketplace side.
The three questions that actually decide it
These are the three from the research, turned into questions about you. You already know all three answers.
- 1
How much of a weekend are you willing to spend, this weekend and every one after?
A long-running daemon under systemd, supervisord or docker, that you notice when it dies. If you have never written a unit file, say no. Saying no is allowed and it is not a lesser setup.
- 2
Which runtime do you already keep alive?
Not which you have installed once. Which one you already update and debug and care about. Node, Python or a Rust toolchain. If the honest answer is none, that is a real answer and it narrows the shelf sharply.
- 3
How will you reach it?
From a phone, from a laptop, from a remote box with no browser. This eliminates nothing, but it decides your registration flow, and it is the question people discover too late.
The fitting matrix
| Host | What it asks you to maintain | Background service? | How a plugin attaches | Fits you if |
|---|---|---|---|---|
| OpenClaw | Node 22+, and its installer brings Node with it | No. Lives in the host process | Native plugin, in-process | You want to install a thing and use it. The default answer for a first stack. |
| Hermes | Python 3.11+ in the Hermes venv | No daemon in the install path | Stub on a plugin discovery path | Python is your home and you want no extra process |
| nanobot | Python 3.11+ | Yes, a long-lived daemon | Event-bus channel subscription | You already run services and think in event buses |
| IronClaw | Rust toolchain | Yes, your own supervisor | MCP server, spawned per session | You want MCP and you are comfortable in Rust tooling |
| Moltis | Rust toolchain | Yes, your own supervisor | MCP server, spawned per session | Same as IronClaw, and you prefer its config model |
| ZeroClaw | Rust toolchain | Yes, your own supervisor | Posted to an agent-spawn API | Isolation matters most: every wake is a fresh session |
That daemon column is the one nobody puts in a comparison table, and it is the biggest single difference in what your week looks like afterwards. On four of these, an install command hands you a binary, not a service. Nothing tells you when it stops.
The reassuring part, since we just made four of them sound heavy
None of the six needs an inbound connection to your machine. No open port, no public URL, no firewall hole. Registration on the Rust adapters is a polling device-code flow with no localhost callback server, which is why they work on a headless box or in a container with nothing but outbound HTTPS. Question three changes your registration flow. It does not close any doors.
Now pick
What you are actually locked into
The portability test above is the right question, so here is our answer to it, and it should make this decision less frightening than it feels.
The host is genuinely expensive to reverse. Your memory, your session history and your installed plugin state live inside it. The runtime and the process model are the host's, not yours. You are right to spend ten minutes here.
Your account and your policies are not. One marketplace identity carries across all six adapters, so running a given host is not a commitment to a marketplace account. Your configuration and policy files sit in your own home directory on your own disk. The Rust register binaries are idempotent by design: re-running one leaves your policies, your buy and sell directories, and every other MCP server entry untouched.
So the thing people fear losing mostly travels. The thing they underweight, the shape of the process on their machine, is the one that sticks. That is also why people do move: one developer in the sample described trying most agent harnesses since January, staying on the same host throughout, and switching anyway when something fit better.
The useful agent is the one you stop having to think about. The host choice is mostly a question about how much you are willing to keep thinking about it.
Install one plugin and see what your host actually asks of you
SIL is the shopping capability for the agent you already run. Built on UCP, Apache-2.0, on OpenClaw today. One install, in-process, nothing to supervise.
FAQ
By fit rather than features, because the capabilities have largely converged and the ongoing obligations have not. Answer three questions about yourself: whether you are willing to run and supervise a background service, which language runtime you already keep alive, and how you intend to reach the agent. On four of the six hosts we ship adapters into, installing one plugin means operating a supervised daemon. If that is not what you want, an in-process host like OpenClaw is the shortest path.