messages_in), and every response leaves through an outbox (messages_out). A scheduled task is just a message with a process_after timestamp. There is no separate scheduler, RPC layer, or job system to learn.
Run it
Clone, install, and talk to your first agent.
Coming from v1 or OpenClaw
What changed, what carries over, and the migration skills that do the work.
Make it yours
Add channels, tools, skills, and alternative agent providers to your fork.
How it works
The entity model, session databases, and the inbox/outbox pattern in depth.
How a message flows
Every channel — Telegram, Discord, a webhook, the built-in CLI — feeds the same pipeline: The router resolves who sent the message, which agent group should handle it, and which session it belongs to, then writes the row and wakes the container. The container processes its inbox and writes replies to its outbox; the host’s delivery polls pick them up and hand them back to the channel adapter. Agent-to-agent messages follow the exact same path — an agent’ssend_message is a row addressed to another agent’s inbox.
Why it’s built this way
Container isolation. Agents run in Docker containers and see only what you explicitly mount. Bash and file edits execute inside the container, never on your host. Each session gets its own container, so parallel conversations can’t interfere with each other. Small enough to hold in context. The codebase is ~195k tokens — compact enough for a long-context agent to hold in context. That’s also how you customize it: edit the code, not a config sprawl. Channels are skills, not bundled features. Main ships exactly one channel — the local CLI. Everything else lives on thechannels branch and gets copied into your fork by a skill: /add-telegram, /add-discord, /add-whatsapp, /add-slack, /add-signal, /add-imessage, and several more. Your install contains the adapters you asked for and nothing else. The same mechanism covers alternative agent providers (/add-codex, /add-opencode, /add-ollama-provider).
Agents that work together
An agent can spawn long-lived companion agents withcreate_agent — each with its own container, workspace, and persistent memory — and delegate to them over the same message queue. That’s enough to build real teams: a worker per task, a manager that tracks what’s in flight, a supervisor that pings you for approval. See the multi-agent swarm guide.
Who this is for
- Operators — you want a personal AI assistant on your own machine, reachable from your messaging apps. Start with the quickstart.
- Builders — you want to extend it: new channels, tools, skills, or agent providers in your own fork. Start with extending NanoClaw.
- Evaluators and contributors — you want to judge the design before trusting it. Start with the architecture and the security model.
Source and community
- Source: github.com/nanocoai/nanoclaw (MIT)
- Discord: community server