← Back to home

/openclaw

My OpenClaw setup

This page documents my real OpenClaw operating model: how I structure agents, route channels, and plug in tooling I build for production automation. It is intentionally public-safe and excludes secrets.

Architecture snapshot

  • Single control plane on my VPS

    OpenClaw runs as the operator layer alongside my Docker services and reverse proxy. Gateway access is kept private-first, with explicit auth and trusted ingress only.

  • Channel routing by agent role

    Discord and Telegram traffic is mapped to specific agents instead of a shared general bot. Each channel lands in the right specialist context from the first message.

  • Tool boundaries per agent

    Agents use allow/deny tool policies so code, ops, comms, and research workflows each run with only the capabilities they need.

  • Model and reliability strategy

    Primary/fallback model routing, periodic heartbeats, and scheduled backups are baked into the setup so failures degrade gracefully instead of failing open.

Agent topology

  • Core operator agents

    main, DevBot, OpsBot, WorkBot, DocsBot, ResearchBot, CommsBot, MediaBot

    These handle day-to-day coding, operations, documentation, web research, communications, and media workflows through dedicated channel bindings.

  • Workflow lanes

    bug-fix/*, feature-dev/*, security-audit/*

    Each lane is split into explicit roles (planner/setup/implement/verifier/reviewer/pr) so larger tasks stay deterministic and auditable.

  • Specialized domains

    External and heartbeat automations

    Special-purpose agents run in separate workspaces with their own prompts, cadence, and tighter tool constraints.

Tools I built into this stack

  • Infrastructure

    CLI Proxy API ↗

    Proxy layer that normalizes provider CLIs behind a stable API surface for production agent workflows.

  • Security

    AWS InfraSec MCP Server ↗

    MCP tooling for AWS security posture analysis and remediation-oriented reporting used in my audit workflows.

  • Networking

    Go TUI Port Scanner

    Interactive network diagnostics utility used when agents need fast operator-grade service visibility.

  • Internal ops

    Workstream CLIs

    Custom CLI integrations for Microsoft 365 workflows and osTicket operations that are routed through WorkBot channels.

Operational notes

  • Channel-specific prompts and tool scopes are versioned and updated as operational needs change.
  • Automation surfaces are separated by concern (dev, ops, docs, comms, media) to reduce cross-context drift.
  • Heartbeats and status channels provide regular visibility into runtime health and delivery queues.
  • Public-facing documentation intentionally omits internal identifiers, secrets, and private routing metadata.