Build a NanoClaw agent

NanoClaw exists for two situations: you need the agent on a channel the other runtimes do not speak, or you need every agent run boxed off from every other one. It is the only runtime here that does both.

The channel list is the headline

Look at the fact card above and note what is on it that is not on the other runtimes: WhatsApp, SMS, Microsoft Teams, Google Chat, iMessage, WeChat, plus GitHub and Linear as first-class channels rather than integrations you wire up yourself.

That list is the reason most people end up here. Plenty of businesses have customers who will happily message a WhatsApp number and would never open a support portal; plenty of teams live in Teams and are not going to move to Slack for an agent. If the channel is the constraint, the channel decides the runtime, and NanoClaw is usually the answer.

GitHub and Linear being channels rather than tools is a subtler win: the agent participates in an issue thread the way a person does, instead of you building a webhook that pokes it.

Container isolation, and what it actually buys

NanoClaw runs each Claude agent in its own container. On this platform that container sits inside your own Firecracker micro-VM, so there are two boundaries stacked: hardware-level isolation between you and every other tenant, and container isolation between one agent run and the next.

The second boundary is the one people underrate. A single agent process handling many conversations is one bug away from letting context leak across them — and if those conversations are different customers, that is not a bug you want to discover in production. Per-run containers make the blast radius of a bad turn one conversation.

This is also why NanoClaw needs the larger box. Docker-in-VM has a real footprint, and each nested container wants memory of its own. The plan in the fact card is not us upselling — it is the smallest box on which this architecture behaves.

Building one

1. Lead with the channel. "Answer customer questions on WhatsApp" is the brief. The channel is the hard constraint and it should be the first thing the builder hears.
2. Decide the escalation rule before you deploy. A customer-facing agent needs an explicit answer to "what does it do when it does not know?" — the good answer is almost always "hand to a human, with the conversation attached."
3. Deploy, then pair the channel. WhatsApp pairs by QR code, which means a phone is involved once; the rest are tokens.
4. Test in web chat first. Get the tone and the escalation rule right somewhere no customer can see, because the first WhatsApp message it answers badly is a real person.

WhatsApp specifically

WhatsApp is the hardest channel to run well and it is worth knowing why before you commit to it. It is not an open bot API like Telegram's — the session is tied to a number and a pairing, and sessions can drop. On a laptop that means an agent that quietly stops answering while you are asleep; on an always-on micro-VM with a persistent volume the session survives restarts, which is most of the problem solved.

The rest of the problem is people: use a number you control and are willing to dedicate to this, not your personal one. There is a fuller guide to the WhatsApp path if that is the channel you came for.

Scheduled tasks

NanoClaw can run recurring jobs itself, which means a customer-facing agent can also do the unglamorous half of the work: a daily summary of what came in, a weekly digest of what got escalated, a nightly check that the channel is still connected. That last one is more useful than it sounds for a channel that can drop a session.

When to pick something else

If your channels are Telegram, Slack, Discord or IRC and you do not need per-run containers, OpenClaw does more per dollar on a comparable box — deeper skills, sub-agent fan-out, a fuller scheduler. If you want the cheapest always-on bot and none of this applies, PicoClaw runs on a fraction of the machine.

Pick NanoClaw when the channel list or the isolation is the reason. Those are good reasons; "it sounded more secure" on its own is not, because every agent here already runs in its own micro-VM.

Is NanoClaw the right pick?

Not sure? Describe the job rather than the runtime — the builder's solutions engineer reads the same capability matrix this page does and will argue for a different one if it fits better.