OpenClaw is getting a lot of attention right now. It’s usually described as an AI assistant. That description misses what it actually is. OpenClaw is an agent runtime.

It connects a language model to tools that interact with real systems. Those tools can read files, write code, run shell commands, and call APIs.

So the right mental model is not: “install an AI assistant.” The right mental model is: “deploy an autonomous process with the ability to operate on my machine.”

Once you see it that way, the real question isn’t how to install it. The real question is how to contain it.

What OpenClaw Actually Does

OpenClaw allows a language model to operate as an agent. Instead of just generating text, the model can decide to invoke tools that interact with the outside world.

Those tools can:

• read and write files
• execute code
• run shell commands
• call APIs
• interact with external services

These capabilities are organized as skills. A skill is a package that describes a capability and exposes tools the agent can use.

Example structure:

skills/
  github/
    SKILL.md
    tools/
      create_pr.js
      list_issues.js

The SKILL.md file explains to the model when and how to use those tools.

You can think of a skill as a capability module that expands what the agent is allowed to do.

Installing OpenClaw

OpenClaw installs through Node and runs as a CLI with a gateway daemon.

Requirements

• Node 22 or later
• macOS, Linux, or Windows (WSL recommended)

Check Node:

node -v

If needed:

nvm install 24

Install OpenClaw:

npm install -g openclaw

Run onboarding:

openclaw onboard --install-daemon

This installs the gateway service that manages agent sessions.

Configure Models

OpenClaw connects to external models through configuration.

Example file:

~/.openclaw/models.yaml

Example configuration:

models:
  primary:
    provider: anthropic
    model: claude-3-opus
    api_key: ${ANTHROPIC_KEY}
  fallback:
    provider: openai
    model: gpt-5
    api_key: ${OPENAI_KEY}

Start the runtime:

openclaw start

At this point you have an operational agent runtime.

Installation Is Easy. Containment Is the Real Problem.

An OpenClaw agent can run shell commands, modify files, and call external services. That means the system should be treated as untrusted automation.

Most tutorials approach this with policy: “Don’t let the agent do dangerous things.” That approach is backwards. You don’t want policies. You want infrastructure that prevents the agent from doing dangerous things. Containment needs to be enforced by the environment.

Three Different Isolation Layers

There are three different isolation mechanisms involved when running OpenClaw. They solve different problems.

Runtime Containerization

The simplest layer is running OpenClaw itself inside Docker.

Example:

docker run -it \
  --name openclaw \
  -v claw-workspace:/workspace \
  openclaw/openclaw

In this setup the OpenClaw gateway runs inside a container. This gives you:

• a reproducible environment
• basic host isolation
• simpler deployment

But this alone does not sandbox the agent’s actions. This protects the host, not the runtime.

OpenClaw Tool Sandboxing

OpenClaw can sandbox tool execution. Instead of executing commands directly, the runtime launches a container for tool execution.

Architecture:

  ↓
OpenClaw Gateway
  ↓
Agent Session → container
  ↓
Tool Execution

Tools that can be sandboxed include:

• shell commands
• file edits
• code execution
• browser automation

Configuration example:

agents.defaults.sandbox.mode: "all"
agents.defaults.sandbox.scope: "session"

Each session receives its own sandbox container.

This isolates agent actions, but the gateway process still runs outside the sandbox.

Docker Sandboxes

Docker recently introduced Docker Sandboxes specifically for AI workloads. A Docker Sandbox runs the agent inside a micro-VM style environment with strict boundaries.

Architecture:

Host
  ↓
Docker Sandbox
  ↓
OpenClaw Runtime
  ↓
Agent Tools

This environment provides stronger isolation:

• restricted filesystem access
• network proxy and allowlists
• external secret injection
• workspace-only file access

Secrets are injected from outside the sandbox rather than being stored in the runtime. Network access can be restricted to specific domains such as model providers or internal APIs. This shifts containment from policy to infrastructure. Instead of telling the agent not to do something, the environment simply prevents it.

The Containment Model That Makes Sense

The safest approach combines these layers.

Docker Sandbox
   ↓
OpenClaw Runtime
   ↓
OpenClaw Tool Sandbox
   ↓
Agent Tools

This creates multiple containment rings.

Ring 1 — Docker Sandbox

Ring 2 — OpenClaw tool sandbox

Ring 3 — tool allowlists

Ring 4 — network restrictions

Ring 5 — human approval gates

Each ring assumes the ring inside it may fail. That’s how you design systems around stochastic components.

Where OpenClaw Actually Becomes Useful

Once it’s contained, OpenClaw becomes a programmable operator. The value comes from defining skills that match the workflows you already run.

Engineering Agent

Skills:

• git
• test runner
• code review
• CI

Tasks:

• review pull requests
• generate architecture summaries
• run test suites
• produce coverage reports

Example:

review this PR and summarize the architectural impact

Research Agent

Skills:

• web search
• summarization
• synthesis
• writing

Typical workflow:

1. gather sources
2. summarize them
3. extract insights
4. draft documents

Operations Agent

Skills:

• email
• calendar
• meeting summarization
• task management

Tasks:

• triage inbox
• extract action items
• schedule meetings
• produce summaries

Product Strategy Agent

Skills:

• market research
• competitor analysis
• financial modeling
• feedback synthesis

Outputs:

• product briefs
• experiment plans
• roadmap drafts

Structuring an Agent Runtime

For larger systems, it helps to treat the runtime as infrastructure hosting multiple agents.

Example:

Runtime
  research agent
  engineering agent
  planning agent
  writing agent

Each agent has:

• its own prompt
• its own skills
• the same runtime environment

The runtime provides infrastructure. The agents provide behavior.

A Note on Maturity

OpenClaw is still early. The capabilities are powerful, but the ecosystem is not hardened yet.

Security researchers are already demonstrating how prompt injection and malicious skills can manipulate agents with broad access. That doesn’t mean the system shouldn’t be used. It means the system should be designed with containment in mind from the start.

The Opportunity

The real opportunity isn’t running a single agent. The interesting direction is combining agent runtimes with orchestration and evaluation systems.

Example architecture:

Agent Runtime
   ↓
Workflow Engine
   ↓
Tool Execution
   ↓
Evaluation Loop

That changes the role of the agent. Instead of being an assistant, it becomes a component inside a controlled operational system. At that point you’re no longer experimenting with AI tools. You’re building infrastructure around them.

Let’s talk about it.

Previous: [Autonomy Without Infrastructure Is Just a Demo]

Next: [Verification Beats Debugging]