Living Architecture: OpenClaw and Clawbot

Why This Was Built

Every architect worth following has a system they built and operate themselves. Not a weekend prototype that gets abandoned after the demo. A real system that runs in production, breaks in interesting ways, and teaches lessons that no whiteboard session or architecture review can replicate.

OpenClaw exists to understand agentic AI at the level of operational truth, not the level of conference talks and vendor demos. When papers describe autonomous agents that can use tools, manage long-running tasks, and recover from failures, the question is: does it actually work when nobody is watching? What happens when the network drops at 3 AM and the agent is mid-task? What does model orchestration look like when every unnecessary API call costs real money? How do you build a skills system that is modular enough to extend but reliable enough to run unsupervised?

The answers to those questions are captured in this document. OpenClaw is not a toy, it is a comprehensive automation platform that manages security monitoring, infrastructure health, data backup, communication management, and development workflows across dedicated personal infrastructure. It has been running continuously since early 2025, and the architectural decisions documented here reflect hundreds of iterations driven by real operational experience. Fred Brooks wrote in 1987 that there is "no silver bullet" for software complexity, only the steady accumulation of tactical improvements. OpenClaw is a living demonstration of that principle.

System Overview

• OpenClaw Version: 2026.4.14
• Gateway: Port 18789 (bound to loopback by default; optional Tailscale exposure via gateway.tailscale.mode in ~/.openclaw/openclaw.json)
• Primary Interface: WhatsApp self-chat channel, configured under channels.whatsapp in the OpenClaw config
• Architecture Pattern: Gateway-mediated agent with modular skills and scheduled automation
• Deployment Model: Single-node, always-on, with network-accessible API gateway
• Scale: 88 autonomous cron jobs, 140+ installed skills, multi model intelligence
• Host: macOS (Darwin 24.6.0) on a 12-core Intel Mac with 16 GB RAM; gateway managed by launchd as gui/$UID/ai.openclaw.gateway

The system follows a design philosophy influenced by the Twelve-Factor App methodology, adapted for an autonomous agent context:

1. Codebase: Single repository tracked in Git, with automated sync (git-auto-sync).
2. Dependencies: Explicitly declared, with the skills framework managing capability dependencies.
3. Configuration: Stored in environment variables and configuration files, separated from code.
4. Backing Services: External services (AI model APIs, messaging APIs, camera feeds) treated as attached resources, swappable without code changes.
5. Build/Release/Run: Skills are developed, tested, and deployed through the clawhub framework.
6. Processes: The gateway process is stateless between requests; state is persisted to the database.
7. Port Binding: The gateway binds to a configurable port and serves requests over HTTP.
8. Concurrency: Cron jobs run as independent processes, avoiding contention.
9. Disposability: The system can be stopped and restarted cleanly; cron jobs are idempotent.
10. Dev/Prod Parity: The development and production environments are the same physical machine, eliminating the gap entirely.
11. Logs: All agent actions are logged through the session-logs skill for audit and analysis.
12. Admin Processes: Diagnostic and maintenance tasks run through the doctor command.

Intelligence and Models

OpenClaw implements multi model intelligence, the architectural decision to route tasks to different AI models based on the nature of the work rather than relying on a single model for everything. This is not just a cost optimization strategy (though it is that too). It reflects a design principle that Martin Fowler would recognize: use the right tool for the job. A fast, broad model handles routine monitoring and triage. A deeper, more expensive model handles complex analysis and creative problem-solving. A specialized coding agent handles software development tasks.

• Primary Model: ollama/glm-5.1:cloud, routed through Ollama's cloud turbo endpoint. Selected as the primary orchestration model for its agentic task execution and 202k-token context window, with cloud offload eliminating local inference cost on the Intel Mac host.
• Fallback Chain: ollama/minimax-m2.7:cloud → ollama/gpt-oss:20b-cloud, configured as agents.defaults.model.fallbacks in ~/.openclaw/openclaw.json. Automatic failover triggers when the primary returns HTTP 503 or times out. (Note: the upstream OpenClaw bundle excludes "timeout" from failover escalation by default; a local patch to pi-embedded-runner-*.js drops that exclusion so cloud 503 storms actually trigger the chain.)
• Memory Search: gemini-embedding-2-preview via Google AI Studio (3072-dim). Replaced the local Ollama embedding path in April 2026 to eliminate ~590% CPU bursts that pegged six cores during doc-audit indexing runs on the Intel Mac.
• Auth Providers:
  • Ollama Cloud: Registered via ollama signin against ollama.com. :cloud-suffixed model tags transparently route to hosted infrastructure; no local GPU required.
  • Google AI Studio (Gemini API): API key resolved from env.vars.GOOGLE_API_KEY in openclaw.json, used for memory embeddings through the OpenAI-compatible generativelanguage.googleapis.com/v1beta endpoint.
  • Ollama Local: Local inference on port 11434 for any non-cloud models (legacy embedding artifacts kept on disk for rollback but no longer invoked).

Model Routing Strategy

The task router selects models based on several signals:

1. Task Complexity: Simple status checks and formatting tasks go to the fastest available model. Multi-step reasoning and analysis tasks go to deeper models.
2. Latency Requirements: Real-time interactions (WhatsApp self-chat responses) prioritize low-latency models. Background tasks (daily scans, batch analysis) can use slower, more capable models.
3. Cost Sensitivity: Routine monitoring tasks that run hourly should not consume premium API credits. The system tracks cumulative API spend and can throttle model selection based on budget thresholds.
4. Modality: Tasks involving image analysis (camera feeds, screenshot interpretation) require multimodal-capable models.

This pattern mirrors a key principle for enterprise AI adoption: do not commit to a single vendor or model. Build an abstraction layer that lets you swap models as the landscape evolves, because it will evolve, rapidly and unpredictably.

Automation (Cron Jobs)

The cron automation layer is where OpenClaw demonstrates the practical value of autonomous agents. These are not simple scripts triggered on a schedule, each cron job invokes the agent, which reasons about the current state, decides what actions to take, and executes them. The agent can adapt its behavior based on context: the network-watchdog does not just check connectivity; it diagnoses the nature of failures and takes different remediation actions for DNS issues versus gateway unreachability versus bandwidth degradation.

As of April 2026, OpenClaw manages 88 autonomous cron jobs across eight operational domains. The following table shows representative jobs from each domain:

Security & Surveillance

Job	Frequency	Purpose
ai-vision-sentry-sweep	Hourly	AI computer vision sweep of all cameras, person, vehicle, and anomaly detection
driveway-night-alert	Hourly (10PM–6AM)	Night-time person/vehicle detection with known-vehicle filtering
hourly-camera-check	3x daily	Camera snapshots via HA proxy API, analysis, and logging
security-360	4x daily	Comprehensive security assessment, network, access, devices
nightly-network-audit	Daily 2:30 AM	Traffic capture and analysis via tcpdump for protocol breakdown and PII leak detection

Intelligence & Geopolitics

Job	Frequency	Purpose
conflict-dashboard-job	Hourly	Real-time Middle East SITREP with source-cited claims
conflict-rss-scan	4x daily	RSS ingestion, severity scoring, SQLite storage
middle-east-sitrep	Daily 7 AM	Cross-referenced geopolitical intelligence brief
tech-leaders-daily-intel	Daily 9:15 AM	Tech leader signal detection and project proposal generation
defense-ai-intel-job	Daily	Defense-AI industry intelligence monitoring

Financial & Portfolio

Job	Frequency	Purpose
flash-crash-guardian	Every 5 min	Portfolio crash detection, autonomous position flattening for >5% drawdowns
portfolio-tracker	Bi-hourly (market hours)	Live pricing for 15+ positions across ASX, US, ETFs with freshness validation
nexus-daily-recommendations	Daily 9 AM	Integrated NEXUS engine + portfolio strategy report
crypto-swarm-sync	Every 15 min	Crypto engine position and sentiment sync
payment-due-scanner	Daily 9 AM	Gmail scan for bills, invoices, and payment reminders

Home Automation & Energy

Job	Frequency	Purpose
free-energy-ac-precool	Daily 11 AM	AC to DRY 18°C during free electricity window
free-energy-pool-pump	Daily 11 AM	Pool pump on for free window
free-energy-vacuum	Weekdays 12 PM	Full house vacuum during free energy
ac-smart-fan-switch	Hourly	Compressor efficiency check, fan-only when room is cool
sleep-ac-phase2-deep	Daily 2 AM	Sleep optimisation, DRY 20°C for deep sleep maintenance
goodnight-lockdown	Daily 10:30 PM	Full house lockdown routine

Health & Family

Job	Frequency	Purpose
whippet-morning-meds	Daily 7 AM	Duke (whippet) BARF + supplement reminder
whippet-evening-meds	Daily 6 PM	Evening feeding reminder
whippet-night-cbd	Daily 9 PM	CBD dose reminder for pain management
kids-bedtime-winddown	7:30 PM Sun–Thu	Lights dim, TTS bedtime warning
bedtime-reminder	Daily 11 PM	Sleep hygiene reminder

Platform & Infrastructure

Job	Frequency	Purpose
latency-monitor	Every 15 min	System latency and performance tracking
ha-watchdog	Every 30 min	HA entity health monitoring with self-healing
git-auto-sync	Every 4h	Repository sync with conflict detection
self-heal	Every 6h	openclaw doctor --fix auto-repair
daily-cron-health-monitor	Daily 6:30 AM	Cron job error detection and fix suggestions
nightly-autoresearch	Daily 1 AM	Autonomous code optimisation across core scripts

Design Decision: Agent-Driven versus Script-Driven Automation

An earlier version of OpenClaw used traditional scripts for scheduled tasks, Python scripts that checked conditions and took predetermined actions. The shift to agent-driven automation was motivated by a specific observation: traditional scripts fail silently when they encounter states that the script author did not anticipate. An agent, by contrast, can reason about unexpected states and either adapt its approach or escalate to human attention.

For example, the network-watchdog script would check if a ping succeeded and restart the network interface if it failed. The agent-driven version checks connectivity across multiple paths, diagnoses whether the issue is DNS, gateway, ISP, or hardware, and takes appropriate action for each case, including deciding not to act if the issue is transient and likely to self-resolve. This is the difference between automation and autonomy.

Capabilities and Skills

The skills framework is OpenClaw's implementation of the microservices pattern applied to agent capabilities. Each skill is independently developed, tested, and deployed. Skills communicate through the agent's orchestration layer rather than directly with each other, maintaining loose coupling.

With 140+ skills installed across system, custom, and community sources, OpenClaw's capability surface is extensive. Key categories include:

Category	Count	Examples
Intelligence & Research	15+	conflict-dashboard, defense-ai-intel, anthropic-legal-tracker, gtc-digest, meta-model-intel, autoresearch
Financial & Portfolio	12+	flash-crash-guardian, portfolio-tracker, crypto-monitor, earnings-reports, finnhub-pro, nexus-control
Home Automation	10+	home-assistant, home-optimus, doge-home, energy-optimizer, energy-scheduler, vision-sentry
Development	10+	coding-agent, github, gh-issues, skill-creator, project-auditor, project-janitor
Communication	8+	himalaya (IMAP/SMTP), gog (Gmail/Calendar/Drive), notify, todoist, slack
Media & Content	8+	youtube-analytics, youtube-watcher, wavespeed-nano-banana-pro, video-frames, sag (TTS)
Security & Network	8+	security-360, network-audit, healthcheck, watchdog, glass-audit
System & Platform	10+	clawhub, session-logs, tmux, weather, mcporter (MCP), self improving-agent

Skills are sourced from three locations:

1. System skills (~/.npm-global/lib/node_modules/openclaw/skills/), bundled with OpenClaw
2. User skills (~/.openclaw/skills/), installed via clawhub or manually
3. Custom skills (~/clawd/skills/), purpose-built for this deployment

Skill Architecture

Each skill follows a consistent structure:

1. Manifest: Declares the skill's name, version, description, required permissions, and configuration parameters.
2. Handler: The executable logic that the agent invokes. Handlers receive structured input and return structured output.
3. Configuration: Environment-specific settings stored separately from code. API keys, endpoints, and thresholds are configurable without modifying the skill.
4. Tests: Each skill includes test cases that validate behavior against expected inputs and outputs. Skills that fail tests are not deployed.

This structure enables a critical capability: the system can extend itself. The skill-creator skill scaffolds new skills, and the coding-agent skill can implement the logic. A human reviews and approves the new skill before deployment, maintaining the human-in-the-loop principle for capability expansion.

Custom Scripts

Local scripts provide targeted automation for tasks that do not require agent intelligence, straightforward operational tasks where a deterministic script is more appropriate than agent reasoning. These scripts are located in the workspace (~/clawd/scripts or ~/.openclaw/workspace/scripts):

Script	Purpose
email-spam-cleaner.py	Rule-based email filtering and archival
camera-reliability.py	Camera uptime and feed quality monitoring
network-watchdog.py	Network connectivity testing and basic remediation
db-backup.py	Database snapshot creation and rotation
driveway-alert.py	Motion detection event processing
git-auto-sync.py	Repository synchronization with conflict detection
shop-monitor.py	Service availability polling
nest-monitor.py	Nest device event processing
hourly-mop.py	Temporary file and process cleanup

The division between agent-driven cron jobs and deterministic scripts is deliberate. Not every task benefits from AI reasoning. File cleanup, database backups, and basic connectivity checks are well-defined problems where a script is simpler, faster, and more predictable. The agent orchestrates these scripts, deciding when to run them, interpreting their output, and escalating when they report anomalies, but does not replace them where they are the right tool.

Hardware Specification

OpenClaw runs on deliberately modest hardware. This is a conscious design choice, not a limitation. If an autonomous agent system requires high-end infrastructure to function, it is not demonstrating the value of intelligent orchestration, it is demonstrating the value of expensive hardware. The constraint forces architectural discipline: efficient model routing, aggressive caching, minimal local compute, and offloading heavy inference to cloud APIs.

• Host: 12-core Intel Mac running macOS (Darwin 24.6.0); Ollama on Intel Macs has no Metal/GPU offload, so all local inference is CPU-only — the practical constraint that drove migration of memory embeddings to Gemini cloud
• Process Management: launchd user agent at gui/$UID/ai.openclaw.gateway, self-healing via the openclaw doctor --fix command wired into a 6-hour cron
• Memory: 16 GB RAM (tight during doc-audit bursts; the Gemini migration was motivated by watching free RAM fall below 150 MB when nomic-embed-2k was pegged)
• Storage: Internal APFS system volume plus a 1.2 TB external workspace (/Volumes/FATTY/src) for source trees
• Local AI: Ollama on port 11434 — retained for legacy embedding models and any non-cloud fallback; production memory search is routed to Gemini cloud, production agent tasks to Ollama's :cloud tier
• Sidecar Infrastructure:
  • doge (100.79.222.109, Tailscale, Linux): runs matter-server in Docker plus a legacy dockerized Home Assistant kept for compatibility; also the source for an rsync-based inbound WhatsApp media sync that runs every 15 s via launchd
  • pro-2 (Dwaynes-MacBook-Pro-2.local / 192.168.68.56, Intel Mac, Darwin 21.6): hosts the live Home Assistant natively via a miniforge3/envs/ha314 launchd unit (io.homeassistant.core.plist, config at ~/.homeassistant), not a Docker container
• Uptime Target: Continuous operation (24/7/365); the gateway is restart-idempotent, and all long-running state is persisted so a launchctl kickstart -k is safe at any time

Why Modest Hardware Matters

Running on constrained hardware has forced several architectural decisions that translate directly to enterprise best practices:

1. Efficient Model Routing: You cannot afford to send every task to the most expensive model when you are paying per token. This forced the development of the model routing strategy described above, which is exactly the pattern that enterprise AI platforms need when operating at scale.
2. Stateless Gateway: The gateway process is lightweight because it has to be. State is persisted to disk, and the gateway can be restarted without losing context. This is the Twelve-Factor App principle of disposability, practiced out of necessity.
3. Incremental Processing: Batch jobs process data incrementally rather than loading everything into memory. The hourly-mop job scans for new temporary files since the last run, not all temporary files ever created.
4. Graceful Degradation: When hardware resources are constrained, the system prioritizes critical tasks (security monitoring, backups) over discretionary tasks (project intelligence scans, weather updates). This priority hierarchy is the same pattern used in enterprise systems for resource management under load.

References

• Brooks, F. P. (1987). "No Silver Bullet: Essence and Accidents of Software Engineering." Computer, 20(4), 10-19. IEEE. https://doi.org/10.1109/MC.1987.1663532
• Fowler, M. (2002). Patterns of Enterprise Application Architecture. Addison-Wesley.
• Fowler, M. (2014). "Microservices: a definition of this new architectural term." https://martinfowler.com/articles/microservices.html
• Wiggins, A. (2011). "The Twelve-Factor App." https://12factor.net/
• Newman, S. (2015). Building Microservices: Designing Fine-Grained Systems. O'Reilly Media.
• Kim, G., Humble, J., Debois, P., & Willis, J. (2016). The DevOps Handbook. IT Revolution Press.
• Humble, J. & Farley, D. (2010). Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Addison-Wesley.