OpenClaw

OpenClaw is an open-source framework for running persistent AI agents on your own hardware. It provides the conversational and agent-native layer of my always-on setup.

What It Does

Unlike interactive tools such as Claude Code or Codex, OpenClaw runs continuously. My primary instance lives on a Mac Mini and handles work such as:

  • Attention briefings — triaging email, Slack, X, Basecamp, and the tasks I have planned for the day
  • Infrastructure monitoring — checking operational services and surfacing only actionable problems
  • Customer support — drafting replies and triaging support requests
  • Research and monitoring — following specific topics and reporting meaningful changes
  • Shopping workflows — guiding repeat purchases and product research
  • Code and operations work — dispatching implementation, review, maintenance, and deployment tasks
  • Fleet maintenance — detecting and safely rolling out agent-runtime updates across multiple hosts

Results can be delivered through Telegram, email, Basecamp, files, or local logs. Jobs are silent when there is nothing worth reporting.

Architecture

OpenClaw provides:

  • A gateway that manages sessions, tool access, and model routing
  • A workspace system with identity, memory, and tool configuration
  • Multi-provider routing with primary and fallback models
  • Plugins and MCP integrations for email, calendars, tasks, Basecamp, browsing, files, and operational services
  • Messaging channels such as Telegram and Slack

The gateway runs as a system service (systemd or launchd) and maintains session state across restarts. OpenClaw itself is not the sole source of truth: the constitution and project context live in Obsidian, while shared skills, job definitions, credentials, wrappers, and model policy live in a synchronized runtime hierarchy.

Jobs and Skills

I now separate scheduled work into three classes:

  • Deterministic jobs — ordinary scripts that do not need model judgment and should run directly under the host scheduler
  • Agent-native jobs — work involving judgment, writing, triage, or tool use, run by OpenClaw or Hermes
  • Infrastructure services — long-running gateways, dashboards, and watchers kept alive by the operating system

A reusable skill defines how to do something. A job defines a specific deployment of that skill: owner, schedule, executor, delivery route, mutable state, and model role. Keeping these separate makes automation portable and auditable.

Delegating to CLI Tools

A key architectural decision is that the persistent agent delegates substantial implementation and review work to specialized CLI tools rather than doing everything inside one conversation. Claude Code, Codex, and additional independent reviewers are available on the same host for:

  • Code implementation and refactoring
  • Independent pull-request review
  • Large-context analysis and multimodal verification
  • Long-running mechanical or operational tasks

Model selection is policy-driven. Jobs and workflows refer to semantic roles, such as frontier coding or peer review, and a central policy resolves the current provider and model. This lets models change without copying fragile versioned identifiers into every prompt and scheduler.

Hosting for Others

I've also deployed OpenClaw instances for other people on Hetzner VPS instances. The setup is straightforward:

  1. Provision a small VPS with enough memory for the runtime and tools you plan to use
  2. Install Node.js and OpenClaw
  3. Configure the model provider and Telegram bot
  4. Set up as a system service
  5. Configure SSH key-only access (no passwords)

Each instance is isolated by credentials, runtime, and ownership boundary. Some are reachable over Tailscale for maintenance, but they do not share credentials or operate as identities inside my personal runtime. Their owners interact with them through their own messaging channels.

What I've Learned

Persistent context has to be engineered. Continuity comes from shared constitution, identity, memory, and project files, plus a bootstrap that loads the right context. It should not depend on a model somehow remembering an earlier conversation.

Fallback must be observable. A system that silently switches provider, billing source, or trust boundary may appear healthy while doing the wrong thing. Primary and fallback behavior needs explicit monitoring and recovery alerts.

Identity boundaries matter more than convenience. Each agent, person, company, and service scope has explicit credentials and ownership. Shared tooling is useful; shared identity is dangerous.

Fleet maintenance is its own discipline. Updates are detected, release-gated, backed up, applied serially, health-checked, and smoke-tested. A healthy process on the wrong version is still a failed rollout.

Domain-restricted browsing is essential. Giving an AI unrestricted web access is a security risk. OpenClaw supports domain allowlists, letting you precisely control what URLs the assistant can fetch. I maintain this list in documentation and sync it to the config.