OPENCLAW

OpenClaw is an agent harness, a framework for running AI agents. I run it on my own hardware as a small team of AI agents, each with its own job. I message the team from a chat app with a goal. The lead agent breaks it into tasks, hands them to specialists, and the results come back to the same chat. Overnight batches end in a morning digest.

The interesting part is not that the agents can act. It’s that they can act without being handed the keys to everything. Credentials sit in the gateway, out of the model’s view. The agents that run code do it inside locked-down sandboxes. Anything that publishes, sends or spends waits in an approval queue for me.

Seven core agents, each with a written role and only the tools that role needs. The reviewers can read and write notes but cannot run commands. The director starts the specialists, and the maker can call in the reviewer. Each agent loads the skill bundles for the task in front of it. There are 17 hand-built bundles covering things like content rules, image workflows, marketplace listings and cost tracking.

The gateway holds the keys. The chat bot token, the gateway’s own token and the model-provider keys live in a team secret store. The config points at them by reference, and the gateway fills them in. A key in the store never becomes part of what the model reads, so no prompt, not even a hostile web page, can talk the model into leaking it.

Sandboxes for the hands. The agents that execute code run every command in their own tightly locked-down container, isolated from the host and from each other. I proved it with a real run: the agent’s command ran as an unprivileged sandbox user inside a throwaway container, not on the host.

Approvals for anything risky. Publishing, sending a message to someone outside, or spending money goes into an approval queue instead of happening. The agents draft and I decide.

Local first. By default the agents run on local open-weights models served from my own hardware. That costs nothing per call and keeps the data at home. Hosted models are a fallback, not a dependency.

I don’t trust “the service is running.” Before calling the team ready, I gave 11 agents a real task each and scored the answers. 10 passed and 1 was partial, with an average quality of 8.5 out of 10. The hostile reviewer scored 10 out of 10 at catching a bad claim. The partial was a sales agent that correctly started a helper agent, but the helper’s results didn’t come back within a single turn. That one is logged, not hidden.

I also keep a plain list of what isn’t finished. The system was designed as a full virtual company, with a CEO layer over CTO, CMO, CIO, CSO and CRO roles talking over message streams. At the last full audit only the CEO and CMO layers did real work; the rest were stubs that acknowledge and log. That line stays on the page until it’s untrue.

Running agents day after day is mostly operations. Three real incidents, and the rule each one left behind:

Built is not armed. New agent work ships switched off. It runs in draft or shadow mode, I look at real output, and only then does it go live. Upgrades follow the same idea: snapshot first, dry run, upgrade, then check real behavior. On the last major upgrade, that check caught a new rule. With several agents behind one chat bot, the bot account now has to name the agent that owns it. The channel stayed down until I added that routing, and the check is how I knew.

A working AI team that lives on hardware I own, answers from my phone, and runs mostly on local models. The guardrails are part of the structure, not a prompt asking the model to behave: credentials in the gateway, commands in sandboxes, risky actions behind an approval.

Measured: 7 core agents, 17 skill bundles, and a smoke test with 10 of 11 passing at 8.5/10 average quality. Revenue from the agents and hours saved are UNMEASURED, so I don’t quote them.