Build a WhatsApp agent

WhatsApp is where a lot of businesses actually meet their customers, and it is the hardest channel to put an agent on. Both of those are true at once, which is why this guide spends more time on the constraints than on the steps.

Why WhatsApp is different

Telegram has an open bot API: you get a token, you have a bot. WhatsApp does not work that way. A session is tied to a phone number and a pairing, and sessions can drop — which on a laptop means your agent quietly stops answering while you are asleep and you find out from a customer.

Two things follow from that:

• It has to run somewhere that is always up. A persistent volume and a process that restarts cleanly is most of the problem solved. This is the channel where "always-on hosting" stops being a convenience and becomes the requirement.
• Use a dedicated number. Not your personal one. The pairing binds the agent to that number, and you want to be able to hand the number to someone else later without handing over your messages.

Which runtime speaks it

NanoClaw is the answer for a customer-facing WhatsApp agent. It speaks WhatsApp natively, and it runs each conversation in its own container — which for a channel where the conversations are different customers is the difference between a bug and an incident.

It runs on the Plus box at $19 a month; the larger box is not an upsell, it is the smallest machine on which Docker-in-VM plus nested containers behaves.

Hermes also speaks WhatsApp, and is the better pick if the work behind the channel is a process — triage, research, draft, human approval — rather than a conversation. The hosted coding agents list WhatsApp too, but a coding agent behind a customer WhatsApp number is almost never what you want.

Setting it up

1. Get a number you are willing to dedicate. Do this first — everything else binds to it.
2. Describe the agent with the escalation rule in the brief. For a customer-facing agent this is the most important sentence you will write. "If you are not confident, say a human will follow up, and hand me the conversation" is a rule; "be helpful" is not.
3. Deploy, then pair by QR code. A phone is involved once, at pairing. After that the session lives on the VM's persistent volume.
4. Test everything in web chat first. The first WhatsApp message it answers badly is a real customer. Get the tone and the escalation rule right where nobody can see.
5. Add a session health check. NanoClaw can run scheduled tasks, so have it check daily that the channel is still connected and tell you if it is not. On a channel that can drop a session, this is worth more than any feature.

Writing a customer-facing brief

Three rules that hold up in practice:

• Say what it may not promise. Refunds, delivery dates, prices, anything contractual. An agent inventing a delivery date is a commercial problem, not a technical one.
• Make "I don't know" a good outcome. Explicitly. Models default to answering; a customer-facing agent needs permission not to.
• Escalate with context. When it hands over, the human should get the conversation so far, so they pick up mid-thread rather than asking the customer to start again.

The realistic expectation

A WhatsApp agent will not answer everything, and the ones that try are the ones that damage the business. The version that works handles the routine majority — hours, availability, order status, the same eight questions — and routes everything else to a person quickly and with context. That is a large amount of value and a small amount of risk, which is the right trade for a channel your customers already trust.

Watching it

Every agent built here reports to ClawMetry: what it answered, what it escalated, what each conversation cost, and a pause button. For a customer-facing channel, reading the first week of transcripts is not optional — it is how you find the eight questions worth answering and the two it should never have tried.