What is it like to build with a self-hosted agent like OpenClaw? Two things are genuinely different, and everything else is the same as any other agent. First, you choose the model, which means the quality and the cost of a session are yours to tune rather than someone else's product decision. Second, you drive it from wherever you already talk, so the barrier to asking is a message rather than a terminal. Both of those are real advantages, and both of them have a matching failure mode worth planning for. ## The advantage: you own the loop Self-hosting means the agent runs on your infrastructure with your model of choice and your extensions. Practically, that buys three things: - **Model choice per task.** A cheap fast model for mechanical edits, a stronger one for the change you are nervous about. - **Your code stays where you put it.** For some teams this is the entire reason, and it is a legitimate one. - **Extensions you control.** If your workflow needs a capability, you add it rather than waiting. ## The matching risk: capability varies The honest version of "you choose the model" is "you can choose badly". A weaker model on a plumbing-heavy task produces exactly the [plausible-looking wrongness that is hardest to catch](/blog/what-your-agent-should-not-build): a webhook that does not verify signatures, a query missing its account filter. There are two defenses, and you want both. **Do not put the risky work in scope.** If sign-in, payments, email, and customer data separation already exist and are tested, then no model choice you make can get them wrong, because they are not being written. This is the strongest available mitigation and it is structural rather than behavioral. **Make verification non-optional.** One command that runs the tests, the linter, a security scan, a dependency audit, and a secret scan, and a rule that nothing is done until it exits clean. A weaker model with a strict check is far safer than a stronger model with no check. ## The other advantage: asking from anywhere Kicking off work from a message thread genuinely changes what gets done, because it changes what gets started. The ideas that would have waited for you to sit down often just happen. ``` add a "share" button to bookmarks that copies a public link ``` That is a whole request, typed on a phone. ## The matching risk: short requests are ambiguous requests The same convenience that gets more done produces the vaguest prompts you will ever write. The example above does not say whether a shared link should work for signed-out visitors, whether it should expire, or whether the owner can revoke it. Those are three product decisions, and the agent will make all three for you. Two habits fix most of it: - **Say what you do not want.** It is shorter than specifying what you do, and it prevents the over-building that vague prompts reliably cause. - **Ask for a plan before a change** when the request is loose. A two-line summary of what it intends to do costs seconds and catches the misunderstanding before there is a diff. ## What the codebase has to provide Independent of which model you point at it, the agent needs the same three things: 1. **A guide file** stating the rules. With a self-hosted setup you may be switching models between sessions, which makes written conventions more important, not less: the file is the only thing that is constant across them. 2. **A worked example** to copy, so structure is found rather than invented. 3. **One verification command**, treated as the definition of done. ## Where it goes wrong **Silent capability drops.** Change the model and the character of the output changes without any announcement. If a session feels off, check what it is running before debugging the prompt. **Extensions that bypass the checks.** The flexibility that makes self-hosting good also makes it possible to build a workflow that skips verification. Whatever else your setup does, make the check step the one thing that cannot be routed around. **No paper trail.** Work started from a chat thread can land with no review. Decide where changes get reviewed, and keep that place, even when the request came from a message. ## The summary Self-hosting moves the quality and cost dials into your hands. That is worth having, and it means the structural safeguards matter more than they do elsewhere: a base where the dangerous parts are already built and tested, a written set of conventions, and a check that cannot be skipped. Get those three right and the model you pick becomes a tuning decision rather than a risk. That is most of [what a starter kit is for](/blog/what-a-starter-kit-is). The same loop with other agents: [Claude Code](/blog/building-with-claude-code), [Codex](/blog/building-with-codex), [Cursor](/blog/building-in-cursor), and [Hermes](/blog/building-with-hermes).