AgentsBooksMost "WhatsApp AI" you have met is a broadcast tool with a language model
bolted to the send button. It can talk. It cannot listen, cannot hold a thread,
and cannot tell the difference between a customer asking for a refund and a
customer asking for a quote.
A WhatsApp AI agent is a different thing. It reads the inbound message,
decides what to do about it, does the work somewhere else — your CRM, your
calendar, your inbox — and then replies on the same thread, in the same
conversation the human is already looking at. Two-way is not a feature bullet.
It is the whole difference between an autoresponder and a colleague.
This is the operational guide: the two ways to connect, the four decisions that
actually matter, and the failure modes that make an otherwise good agent look
rude on the one channel where rudeness is unforgivable.
Why WhatsApp is the hardest channel to automate well
Email forgives latency. Slack forgives a bot that says "working on it".
WhatsApp forgives neither, because of how people use it:
- It is a synchronous-feeling channel. Two grey ticks and thirty seconds of
silence reads as being ignored. On email, thirty seconds is instant. - There is exactly one thread per person. You cannot open a side channel to
clarify. Everything — the sales pitch, the support escalation, the invoice
chase — lands in one conversation the customer can scroll back through. - The recipient did not opt into a product. They opted into a phone number.
A message that reads as machine-generated damages the number, not just the
campaign. - Read receipts and typing indicators are part of the protocol. Getting
them wrong is worse than not sending them: "typing…" that never produces a
message is a lie the platform tells on your behalf.
Every decision below follows from those four constraints.
Decision 1: gateway or the Cloud API
There are two honest ways to get an agent onto WhatsApp, and the right answer
depends on who owns the number.
The Business Cloud API (Meta's own) is the route for a brand number at
volume. You get template messages, a verified business profile, and rate limits
that scale with your quality rating. You also get template pre-approval, a
24-hour customer-service window outside which only approved templates may be
sent, and a per-message cost.
A gateway on a number you already own is the route for an operator,
consultancy, or agency number — the one your customers are already messaging.
There is no template approval because there are no templates: the agent
participates as that number's client. This is the route we shipped for
AgentsBooks agents, because the number that matters to a service business is
usually the one already on their website — which is exactly why its risk
deserves a plain statement.
Linking a number this way connects it as a linked device, over WhatsApp's
multi-device protocol — the mechanism WhatsApp Web uses — through an
unofficial client that runs in our gateway. It is not WhatsApp's
official Business API, and neither WhatsApp nor Meta approves or supports it.
Automating a personal or business account like this can breach WhatsApp's
terms of service, and WhatsApp may restrict or ban a number it believes is
automated or run through an unofficial client. That risk falls on your own
number: if WhatsApp bans it, the account you lose is yours. Our own setup
screen says the same thing: use a dedicated number you are happy to hand to an
agent, not your personal one.
So the trade-off is "official versus unofficial", and it is also who bears
the risk. On the Cloud API, Meta polices your quality rating on a sanctioned
route. On a linked device, you are the quality rating and your number is the
stake, which means the guardrails below stop being advisable and start being
load-bearing.
Decision 2: what the agent is allowed to spend
An inbound channel is an unbounded cost surface. Nobody plans for this, because
outbound automation has a natural cap: you decide how many messages to send. On
an inbound channel, a stranger decides how many replies you generate — and a
model call is not free.
The arithmetic is unpleasant. One chatty number sending 200 messages in an
evening, against a mid-tier model with 8K of conversation context loaded each
turn, is not cents. It is a number that shows up on the invoice and nowhere
else.
So cap it per number, not per account:
- A monthly or daily budget scoped to each conversation partner.
- A refusal, not a warning, when it is exhausted: the agent stops replying
to that number and tells you, while every other conversation continues. - Context truncation as a first-class setting. Most of the cost in a long
WhatsApp thread is re-reading the thread.
An account-level cap fails in the wrong direction: one abusive number silences
your agent for every real customer. A per-number cap contains the blast radius
to the number that caused it.
What AgentsBooks enforces today is the blunt version of this, and it is worth
being exact about it. Each sender has an hourly message limit — a limit on
messages, not a spend budget — and the agent as a whole has a much higher
ceiling that acts as a circuit breaker. A number that reaches its limit is told
once that it has hit the limit, and then gets silence until the window resets,
while every other conversation carries on. The platform sets those limits; it
is not a per-number budget you configure. The bluntest control is the off
switch. Turn off the WhatsApp channel, the agent, its team or its organization,
and the number goes completely quiet: the gateway drops every message,
strangers included, so nobody gets a reply or the one-line "not authorised"
notice.
Decision 3: which actions need a human
WhatsApp collapses your entire customer relationship into one thread, so the
agent needs a sharper sense of consequence than it would on a marketing
channel. The working split:
| Agent acts alone | Human approves first |
|---|---|
| Answering a product question from your docs | Quoting a price or discount |
| Booking into a free calendar slot | Cancelling or rescheduling someone else's booking |
| Acknowledging receipt, setting expectations | Any commitment with a date in it |
| Collecting the details a ticket needs | Issuing a refund or credit |
| Drafting a reply for review | Sending anything to a number that did not message first |
The last row is the one people skip. An agent that initiates contact is a
different legal and reputational object from an agent that replies. Keep
outbound initiation behind an explicit human action, always — that is the line
between an assistant and a cold-messaging machine, and the platform draws it
too.
On AgentsBooks the WhatsApp channel is conversational today. The agent answers
in the thread from the knowledge you gave it, with no tools on this channel, so
it cannot book, cancel, refund, or message a number that did not write first.
There is no approval step on WhatsApp replies either: each reply is sent as
soon as it is written. Everything in the right-hand column therefore stays with
a human, and the prompt's job is to make the agent hand those requests over
rather than promise them.
If you want the general version of this table rather than the WhatsApp-specific
one, it is the human-in-the-loop approvals
guide.
Decision 4: what the agent says when it does not know
This is the difference between an agent people tolerate and one they trust, and
it is almost entirely prompt design rather than engineering.
Three rules that survive contact with real customers:
- Disclose once, early, without apologising. "You're chatting with our
assistant — I'll bring in a human for anything it can't settle." One line,
at the top of the first conversation. Not in every message, which is noise,
and not never, which is a trick. - Escalate with the context attached. "Passing this to Dana" is useless if
Dana has to read forty messages. The handoff should carry a three-line
summary and the specific unanswered question. - Never invent a policy. The most damaging thing a WhatsApp agent can do
is confidently state a refund window, a delivery date, or a price that your
business does not honour. If it is not in the knowledge the agent was given,
the answer is "let me confirm that and come back to you" — and then someone
actually has to come back.
The four failure modes worth instrumenting
You will not catch these by reading transcripts. Instrument them.
Silent drop. The gateway disconnects, inbound messages stop arriving, and
nothing anywhere turns red — your customers are messaging a number that is
listening to nobody. Alert on absence: if a normally-busy number has received
nothing in an hour, that is the alert. A health check that only reports "the
process is up" cannot see this.
Double-send. A retry after a timeout that already delivered. On email a
duplicate is untidy; on WhatsApp it reads as a malfunctioning robot. Every
outbound send needs an idempotency key tied to the inbound message that
triggered it.
Cross-thread bleed. The single worst outcome on this channel: one
customer's context appearing in another customer's thread. Isolate conversation
memory per number, and test it by running two conversations concurrently and
asserting neither can see the other's history. Do not assume; assert.
Credential leakage into logs. A gateway holds a session that is effectively
a credential for your phone number. If it lands in a run transcript, an error
report, or a screenshot in a support ticket, you have handed over the number
itself. Mask on the way into the log, never on the way out of the viewer.
A 30-minute first build
If you want the smallest thing that is genuinely useful rather than a demo:
- Pick one intent. "Someone asks whether we're open / what our address is
/ what our lead time is." Not "handle support". - Give the agent exactly the knowledge that intent needs — your hours,
your address, your lead time. Nothing else. A narrow knowledge base is why
narrow agents do not hallucinate. - Decide who it answers before you connect anything: an allowlist of the
numbers you are testing with, not "anyone who messages the number". - Route everything else to a human with the summary-and-question handoff.
- Watch twenty real conversations before you widen the scope by one inch.
Step 5 is the step everybody skips, and it is the one that tells you what your
customers actually ask — which is never what the intent list said they would.
Where AgentsBooks fits
An AgentsBooks agent links a WhatsApp number as one of its channels — as a
linked device, through the unofficial route described above, with the ban risk
that comes with it — and holds the conversation two-way on the same thread.
What it has on that channel today:
- Who it answers, set by you. Direct messages from an allowlist, from
anyone, or — the default — a short "not authorised" reply to strangers; in
groups, only allowlisted senders, anyone, or no one, and by default only
when the agent is mentioned (you can turn that off). - Off switches. Turning off the channel, the agent, its team or its
organization each silences the number completely: no replies, and no "not
authorised" notice to strangers. - A message limit per sender, with a higher ceiling per agent, set by the
platform rather than per number by you. - One transcript per conversation. Each number has its own history, and a
group has its own, apart from its members' direct messages. The agent's owner
can read every one, including whether a reply failed to reach WhatsApp. - Knowledge for everyone, private notes only for you. Replies draw on the
knowledge you gave the agent. In your own "Message yourself" chat, and in
direct messages from numbers you mark as yours in the app, replies can also
use what the agent's tasks saved privately. Replies to everyone else use the
knowledge alone. - The credential stays in the gateway. The WhatsApp session is held by the
gateway; the agent and its runs never hold it.
What it does not have: no tools on WhatsApp, no spend budget per number, and no
approval step before a reply goes out. The agent converses; it does not act on
your systems from a WhatsApp thread, and it never messages a number first.
The channel is new; the agent behind it is not — the same identity, the same
knowledge, and the same on/off switch its scheduled runs obey.
Start with one agent, one dedicated number, one intent: build a WhatsApp
agent. If you are evaluating this for a team with
a compliance function, the AI governance
checklist is the 24 questions
your security reviewer is going to ask.
FAQ
Do I need the WhatsApp Business API to run an AI agent?
No, but know what you are choosing instead. The Business API is the official
route, and you need it for template messages, a verified brand profile, and
Meta-managed scaling. A gateway links a number you already own as a linked
device, through an unofficial client: simpler, with no templates, but not the
official Business API and not sanctioned by WhatsApp. WhatsApp may restrict or
ban a number used this way, and that risk falls on your own number.
Can a WhatsApp agent message someone first?
Technically yes; you should make it hard. Keep outbound initiation behind an
explicit human action. Inbound-reply agents are a support and sales tool.
Outbound-initiation agents are a cold-messaging tool, and the platform, the
regulator, and the recipient all treat them differently. On AgentsBooks the
WhatsApp channel only replies: it never messages a number first.
How much does a WhatsApp AI agent cost to run?
The messages are cheap or free depending on your route; the model calls are
the real cost, and they scale with conversation length rather than message
count, because each turn re-reads the thread. Budget per active conversation,
cap per number, and truncate context deliberately.
What happens when the agent gets it wrong?
It should hand over before it gets it wrong — that is what the "never invent a
policy" rule and keeping consequential actions with a human are for. When it
does get something wrong anyway, you want the record: the inbound message, the
reply it sent, and whether that reply was delivered. On AgentsBooks that record
is the conversation transcript, which the agent owner can read. Without it you
cannot fix the cause, only apologise for the symptom.
