NanoClaw

You will like this if you want an assistant in WhatsApp, Telegram or Slack and a huge codebase with root on your laptop keeps you up at night. The daily trait is the container: each agent group runs in its own Docker container and sees only the folders you mount, so the agent with your Obsidian vault and the agent in the family chat never meet. Setup is one script from a fresh machine.

Where it hurts is that it assumes Claude Code is installed for customising and debugging. Pick it for a personal assistant you can audit in an afternoon. Pick OpenClaw for the full feature list.

The risk is the upgrade. The project rejects configuration files on principle; wanting different behaviour means editing the code in your own fork, usually via Claude Code. The v1-to-v2 migration script therefore has a step called fork-customisation replay, handed to Claude Code because it needs judgment. Every future major version inherits that step, and every user's fork drifts a little further from trunk, which only accepts security and bug fixes.

The consequence: keep your customisations small and listed, or you will re-derive them each release. What it does right: scheduled tasks can carry a script gate that checks for work before waking the agent, so a quiet morning costs nothing.

The architecture is small enough to state fully. 1. A single Node host routes each message user to messaging group to agent group to session. 2. It is written to the session's inbound.db and the container is woken. 3. Inside, a Bun runner on the Claude Agent SDK polls inbound.db, works, and writes to outbound.db. 4. Each file has exactly one writer, so there is no IPC. 5. A sweep every sixty seconds detects stale sessions and fires due tasks.

Verification is absent; the agent's word is final. The observation: replacing a message broker with two files and a poll is correct at one user, and the design admits it.

The website banner does the work: NanoCo, the maintainers, raised $12 million to give every member of your team a professional assistant. That is the pivot announced in advance. A forkable personal agent becomes a team product, and the prebuilt hardened image that already asks for a free account and an email is the first funnel; a hackathon is the second.

Moat: smallness is a feature, not a moat, and forks are encouraged. Pricing power: unknown until the team product ships. Likely acquirer: a chat platform that wants an agent per person, or Anthropic, whose SDK it is built on. Position: long, small, and watch what the team tier costs.

The demo is a WhatsApp message that becomes a morning briefing. For sixty seats the software is free and the meter is Anthropic, and there is one genuinely good page for the security questionnaire: agents never hold raw API keys, because outbound requests go through OneCLI's Agent Vault, which injects credentials at request time and enforces per-agent policies and rate limits. The rest is harder. It needs Docker Desktop on every laptop, anonymous setup diagnostics are sent unless NANOCLAW_NO_DIAGNOSTICS=1 is set, and there is no SSO or audit log.

Slack provisions one app per agent, so sixty engineers is a lot of Slack apps. Not yet.

MIT, and the philosophy is mine: you make your own fork, and trunk is only registry and infrastructure. Channels live on a channels branch and providers on a providers branch, pulled in by /add- skills, so my copy carries WhatsApp, Ollama and nothing else. /add-ollama-provider is per agent group, so one agent runs local and another runs Claude. ANTHROPIC_BASE_URL and ANTHROPIC_AUTH_TOKEN in .env point the default provider at any compatible endpoint, and templates bundle instructions, MCP tools and skills without secrets.

The grudge: the customisation path runs through Claude Code, a closed tool at the centre of an open one. I can edit TypeScript without it. I will.