Build your own OpenClaw-style AI agent

What OpenClaw actually is

OpenClaw is a self-hosted personal AI agent. You run it on your own server, connect it to the chat apps you already use, and it can run shell commands, control a browser, read and write your files, and act on the messages you send it. It is MIT-licensed, local-first, and has over 380,000 GitHub stars as of mid-2026, which makes it one of the most-starred projects on the platform. Under the noise it is a fairly small set of parts wired together in a sensible way. This post walks through those parts so you understand how a tool like this is built, and where the sharp edges are.

One warning up front, because it shapes every design choice below. In March 2026 OpenClaw had nine security issues disclosed within four days, including a critical privilege-escalation flaw rated 9.9 out of 10 (CVE-2026-32922). The project is designed to be hardened by you, the operator. An agent that can run any command is only as safe as the box it runs on and the limits you put around it. Keep that in mind as you read.

The gateway daemon: one process, kept private

At the center is a single long-running process, usually called the gateway. It is the control plane. It receives messages, decides what to do, runs the tools, and sends replies back. Everything else plugs into it.

The most important fact about the gateway is where it listens. By default OpenClaw binds it to the loopback address, 127.0.0.1, so it is not reachable from the internet unless you go out of your way to expose it. Leave it there. This is the single process that runs commands for a living, so an exposed gateway hands anyone who finds it a remote foothold into your server. When you need to reach it from your laptop, do it over a VPN or an SSH tunnel rather than opening a port. Nobody can attack a port they cannot reach.

Channel connectors: getting a message in and a reply out

A personal agent is only useful if you can talk to it from the apps you already use. That is what the channel connectors do. Each one speaks to one platform, such as Telegram, WhatsApp, Slack, or Discord, using that platform's bot API or webhooks.

The shape is the same for all of them. The connector registers a bot with the platform, receives your incoming message (either by polling the platform or by receiving a webhook the platform pushes to it), hands that message to the gateway, and posts the gateway's reply back through the same API. The connector is a thin translation layer. It converts "a Telegram message arrived" into "here is text for the agent" and back again. Building your own is mostly a matter of reading one platform's bot documentation and mapping its message format onto the gateway's.

The brain and the tool loop

Inside the gateway is the part that makes it an agent rather than a chatbot. It is a loop.

A message arrives. The gateway sends it to a language model along with a list of tools the model is allowed to use. The model reads the message and decides: answer directly, or call a tool. If it calls a tool, the gateway runs that tool, captures the result, and sends the result back to the model. The model looks at the result and decides again. This repeats until the model has nothing left to do and produces a final reply.

That loop is the whole idea of an agent, and it is the same loop whether the agent lives in a chat app or a terminal. For how tools get connected to that loop in a standard way, connecting tools through the Model Context Protocol is a good next read, and for the model side, running the model itself on your own hardware fills in the other half.

The tool set is the point, and the danger

The tools are what make OpenClaw powerful. A tool that runs a shell command, a tool that drives a browser, a tool that reads and writes files. Give the loop above access to those, and it can do almost anything you can do at a keyboard. That reach is the entire product, and it is also the entire risk.

An agent that can run any command, acting on instructions that arrive from a chat app, is a large attack surface. A bad instruction, a prompt-injection attack hidden in a web page the browser tool visits, or a bug like the March 2026 flaws can turn "read my calendar" into "delete my files." So the limits are not optional extras. Run the agent as a dedicated, unprivileged user with no sudo, so a compromise cannot escalate. Gate the dangerous tools behind an approval step so the agent asks before it does something destructive. Sandbox tool execution so a runaway command is contained. Isolate the model's API key so a leak does not hand an attacker your account.

Before you expose anything that runs shell commands, work through the basics deliberately. Generate a checklist for your own box here, then follow it top to bottom:

The unprivileged-user piece is covered in depth in running services as an unprivileged user, and the full safe-setup walkthrough for the real project is in running OpenClaw safely on a VPS.

Memory as plain files

Most people expect an agent's memory to live in a database. OpenClaw's does not. It stores memory as plain Markdown files on disk, and that choice is worth copying.

Files are simple. There is no schema to migrate, no service to keep running, and no query language to learn. They are inspectable: you can open the folder and read exactly what the agent believes about you, correct a wrong note by editing a file, or delete a memory by removing one. And they are portable, because moving the agent to a new server is a matter of copying a directory. For a single-user personal agent, a folder of text files is enough, and it keeps the whole system easy to reason about.

Skills: a portable way to add abilities

Beyond the built-in tools, OpenClaw uses a portable skill format so the community can extend what it can do without changing its core. A skill is a self-contained bundle of instructions and, sometimes, code that teaches the agent a new task. The agent loads a skill when the task calls for it.

The value of a format like this is that abilities become shareable. Someone writes a skill for a specific job, publishes it, and others drop it in. If you build your own agent, defining a small, clear extension format early saves you from hard-coding every capability into the core later.

Bring your own model

OpenClaw is model-agnostic. It does not ship its own language model. Instead it connects to one you choose, which can be a hosted API or a model you run yourself.

That split matters for cost, privacy, and control. A hosted API gives you the strongest models with no hardware to manage, at a per-token price and with your prompts leaving your server. A self-hosted model, served with something like Ollama, keeps every message on your own box and costs only the hardware and power, at the price of running a smaller or slower model. Many people mix the two. If you want to keep an agent fully private, self-hosting the model on your VPS is the piece that closes that last gap, and Hermes Agent is another self-hosted agent worth comparing against.

Should you build one?

You can build all of this. The parts are not exotic: a daemon, a few chat connectors, a model-and-tools loop, a folder of Markdown, and a plugin format. Understanding them is genuinely useful, because it demystifies every agent you will use and it tells you exactly where the danger lives.

But for most people the honest answer is to run the real thing and harden it rather than reinvent it. OpenClaw already solved the connectors, the loop, and the skill format, and it has had real security scrutiny. Your effort is better spent on the part that is actually yours to get right, which is the setup and the hardening on your own server. Build a small one to learn. Run and lock down the real one to use.

The general foundations sit in building your own AI agent on a VPS, and building an agent with Claude shows the same ideas with a specific model as the brain.

FAQ

Is it hard to build an agent like OpenClaw?

The individual parts are not hard. A gateway process, a chat connector, a model-and-tools loop, and a folder of files are each straightforward on their own. The hard part is doing it safely. An agent that runs shell commands from chat messages is a serious security surface, and getting the sandboxing, permissions, and unprivileged-user setup right is more work than wiring the features together.

Why does OpenClaw store memory as Markdown files instead of a database?

Because for a single-user personal agent, files are enough and much simpler. There is no database service to run, the memory is easy to read and correct by hand, and moving the agent to another server is just copying a directory. A database earns its place at larger scale, not here.

What is the most dangerous part of a personal AI agent?

The tools that let it act: running shell commands, controlling a browser, and writing files. Those are the reason to build it and the reason it can hurt you. OpenClaw's March 2026 security event, nine issues in four days including a 9.9-rated critical, is the clearest argument for treating the tool layer with care: run as an unprivileged user, gate destructive actions, and sandbox execution.

Do I need my own language model to build one?

No. Agents like OpenClaw are model-agnostic, so you connect one you choose. That can be a hosted API for the strongest models, or a model you run yourself for full privacy. Self-hosting with Ollama keeps every message on your own server at the cost of running a smaller model.