I spent a good chunk of time studying OpenClaw before I started building anything. It used to be called Clawdbot, then MoltBot. It's got 30,000 GitHub stars, persistent memory, connections to WhatsApp and Telegram, and 13,000 community skills. That's an impressive feature set.
But then I looked at the security audits, and it changed how I thought about the whole problem. 512 vulnerabilities. 42,000 instances exposed on the internet. The architecture decisions that made OpenClaw powerful also made it dangerous.
So I started building Coach — not as a reaction, but as an exploration. What would a multi-agent AI platform look like if security and simplicity came first?
What OpenClaw Does Well
It's a self-hosted AI assistant that runs on your machine. Terminal access, email, calendar, smart home. It works with Claude, GPT-4, Gemini, and local models through Ollama. Peter Steinberger built it. Good engineer.
The plugin model is smart — community skills let you extend the system without touching core code. The multi-platform support is real. If you need an AI assistant connected to everything, it's hard to beat the feature coverage.
What the Security Audits Revealed
These aren't my findings. Cisco, Palo Alto, Kaspersky, and Gartner all published reports.
Early versions bind to
0.0.0.0:18789 — open to the internet by default. Researchers found 42,000+ instances exposed. Some in healthcare and government.Authentication was off by default. When enabled, it accepted "a" as a valid password.
API keys, tokens, and passwords stored in plaintext config files. Malware families already know to look for OpenClaw paths.
The skill marketplace had deeper issues. A security researcher found malware within two minutes. One skill called "What Would Elon Do?" had hidden curl commands exfiltrating data. 386 malicious packages from a single attacker.
Prompt injection remains unsolved in their own documentation. Researchers demonstrated attacks triggered by reading a Google Doc. Zero click.
These aren't bugs. They're architecture decisions. A gateway daemon on a network port, a marketplace running unaudited code, plaintext credentials — each one creates attack surface by design.
So that's what shaped my thinking. Not "OpenClaw is bad," but "what would I do differently?"
What I Built
Coach is a multi-agent AI platform that runs locally as a macOS daemon. One process, always running. No server, no open ports. It's provider-agnostic — Claude, GPT, Ollama, or a local model. You can swap the LLM without changing anything else.
The architecture has five layers, and each one is independent and replaceable:
- Providers — the LLM backend. Change one config line to switch models.
- Transports — how you talk to it. Terminal, Telegram, Slack, anything. They all share the same conversation.
- Plugins — domain logic. Each plugin bridges Coach to a specific workflow. Write a Python module, register it in config.
- Agents — workspace-specific instances with their own tools, permissions, and working directories. Deterministic routing (rule-based, no ML) decides which agent handles each request. No LLM needed for the routing itself.
- Scheduler — built-in cron. Jobs run inside the daemon. No separate service.
Underneath all of this sits semantic memory. A local vector database indexes past sessions with temporal decay (older context gradually loses weight), so recent context matters more than old context. Only relevant chunks load per query. 91x compression from raw transcripts.
I currently run it for career management — content publishing, market research, and technical writing. But the platform doesn't know or care what domain it serves. The same architecture could run a codebase assistant, a research tool, or a home automation controller. The plugin is the domain. Coach is the infrastructure.
How It Got Here: Five Iterations
Coach didn't start as a daemon. It started as experiments. The first three iterations were about solving the same problem OpenClaw has — how do you keep one brain across multiple interfaces? The last two were about making the solution production-ready.
Iteration 1: Groq + Llama 3
I started with Groq's free tier for Telegram responses. Fast inference, 2–3 seconds per message. But it hallucinated data — it made up things that didn't exist in my database. For any tool that manages real data, wrong answers are worse than no answers.
Iteration 2: Claude Haiku with Tools
I switched to Claude Haiku through the Anthropic API. Gave it tools to search memory, read files, query the database. Now it could look things up instead of guessing. Better answers.
But it could only read. When I asked it to run a task, it said "switching to Claude Code now." It didn't actually do that. It hallucinated the action. Read-only chatbot. Not what I needed.
Iteration 3: Two Models, One Memory
I thought I could fix this with two tiers. Haiku handles light questions — status checks, quick lookups, chat. Heavy requests get routed to Claude Code for the full toolchain. Both tiers had access to the same files and database.
It still didn't work.
The problem wasn't memory, it was context. Haiku had its own conversation thread. Claude Code had its own. When I asked Haiku about yesterday's work, it could search memory and find the data. But it didn't know the reasoning behind recent decisions. It had summaries, not understanding. Two brains with shared memory isn't the same as one brain. Memory gives you facts. Conversation gives you context.
This is the same problem OpenClaw describes in issue #24832 — "context fragmentation." Their agent "has no awareness of what's happening in its other concurrent sessions." They proposed solving it with shared context blocks, gateway daemons, channel adapters, and a Lane Queue. More infrastructure to keep two brains in sync. I went the other way. I stopped trying to sync two brains and used one.
Iteration 4: One Brain, Scheduled Task
I deleted all the Haiku code, the API calls, the tool routing, the system prompts. About 350 lines removed. Telegram messages went straight to Claude Code CLI through claude --continue --print. One model. One session. Terminal and Telegram both write to the same conversation.
No API keys needed — it uses the local Claude subscription. No webhook — the bot polls outbound every 60 seconds through a macOS scheduled task. Nothing listens for incoming connections. Between messages: zero CPU, zero memory.
But each message spawned a new subprocess. 21 seconds per response.
Iteration 5: Persistent Daemon (Current)
So 21 seconds per response was too slow. The scheduled task became a daemon — a macOS service that runs continuously. Instead of spawning a new process per message, it keeps one Claude process alive. Messages go in as JSON on stdin. Responses stream back on stdout. NDJSON protocol.
On startup or session rotation, the daemon sends a warmup prompt that loads memory context from a local vector database. The agent responds "OK" and the session is primed. No cold start for the user.
A direct API call is faster per message — 2–3 seconds vs 10 seconds. But the tradeoffs matter:
An average session is 429,000 tokens. At API rates, that is $6–15 per session. I run 3–5 sessions a day. $600–2,250 per month. The $100/month subscription is flat rate. No per-token cost. The bill does not scale with usage.
Credentials. The API requires a key in your environment — a credential that can be stolen. The CLI uses subscription auth tied to your machine login. No key to steal.
Infrastructure. The API typically needs webhook infrastructure — open ports. The CLI needs none.
Frequently accessed data — status checks, stats, schedules — bypasses the LLM entirely and queries the database directly. 200 milliseconds.
Session rotation every 50 messages creates a new session UUID. Before rotating, the daemon flushes a checkpoint to the memory store. No data loss, no stale context building up.
What Changed Across Iterations
The first three iterations were about architecture — finding the right model. The last two were about making it production-ready. Security improved at every step, not because I was adding defenses, but because I was removing the things that needed defending.
The simplest architecture turned out to be the most secure. One model, one session, no network daemon.
Design Tradeoffs: OpenClaw vs Coach
Who This Is For
OpenClaw is built for scale. Gateway daemon, marketplace, multi-user channels, plugin ecosystem. If you need an AI assistant for a large team or a customer-facing product, that infrastructure makes sense.
But most people building AI agents aren't doing that. They're one person automating their workflow, or a small team that needs a shared tool. For that use case, the simpler architecture wins.
Coach runs on a $100/month Claude subscription and a MacBook. No server costs. No Docker. No Kubernetes. The database is a SQLite file. Adding a feature means writing a Python module.
If you outgrow this — multi-user access, enterprise auth, team channels — you'll need something else. But starting simple means you can add complexity later. Starting complex means you can't take it away.
What I Took From OpenClaw
Studying OpenClaw shaped several of Coach's design decisions. The ideas are sound — it's the implementation choices where I went a different direction.
Scheduling. Coach has a built-in scheduler. Jobs run inside the daemon process. Same concept, no separate service.
Mobile access. Telegram bot polls outbound. Terminal and Telegram share the same session. No webhook, no exposed ports.
Session memory. Local vector database with temporal decay. Recent context weighs more. Only relevant chunks load per query.
Extensibility. Each plugin is a Python module. No marketplace, no downloading unknown code. You write what you need.
The Takeaway
OpenClaw showed me what a full-featured AI assistant looks like — and what happens when security isn't part of the architecture from day one. Every feature that makes it powerful also makes it harder to secure.
Coach started from the other direction. What's the least amount of infrastructure that still gives you a capable, multi-agent AI platform? The answer turned out to be a Python daemon, a SQLite database, and a Unix socket.
Less to build. Less to break. Less to secure. Hope this helps.
Read the Series
20 years building production systems. From embedded hardware to AI platforms. Currently building multi-agent tools for personal and small-team use.
