Nanoclaw

NanoClaw's pitch is legibility, and the architecture backs it up. One Node host process routes every message to the right session, writes it to inbound.db, and wakes that session's container; each active session gets its own container with its own message databases. Sessions inside one agent group share that group's workspace and memory, separate groups do not. That is a cleaner mental model than most agent frameworks ship, and the file map in the docs (src/index.ts, src/container-runner.ts, src/router.ts, src/delivery.ts, src/db/, src/host-sweep.ts) means you can trace a message end to end instead of spelunking. Strengths: genuine container isolation rather than application-level checks, which is why bash access inside an agent is defensible — commands run in the container, not on your host. Credential handling is the standout. By default agents never hold raw API keys; outbound HTTPS goes through OneCLI's Agent Vault, which injects credentials at request time and enforces per-agent policies and rate limits. Flexible Isolation V2 gives you a real per-channel decision — dedicated agent for full privacy, shared agent for unified memory, shared session for a merged context. Scheduled tasks run with your chosen provider and message you back, which covers morning briefings and weekly reviews. The Slack work is the most interesting 2026 development: as a launch partner for Slack's Add to Slack, one agent request stands up writer, developer, and designer personas, each with its own sandbox, working in-channel and in a shared Canvas. Agent Templates bundle a persona, scheduled tasks, and a plugin base on the open Agent Plugins standard, so you can package a tuned agent and move it between machines. Weaknesses are structural, not bugs. One container per active session uses more memory and CPU than shared-process designs, which bites on a laptop or small VM. There is no web or mobile dashboard — configuration and interaction run through chat, terminal, and config files. Centralized user management, SSO, and multi-tenant admin are not part of the design, so this is not a fit for a company that needs an admin console. You self-host, so you own updates and maintenance. Model usage is billed separately by whichever provider you configure unless you run local Ollama models. And the skills-over-features philosophy cuts both ways: you install what you need, which means you also install it. Where it fits: a developer or small privacy-conscious team that wants a channel-agnostic agent with inspectable isolation, credential injection, and scheduled jobs delivered into the chat apps they already use. Where it doesn't: anyone who wants plug-and-play, a GUI, or an IT department to manage it for them.