WhatsApp AI agents in production: eight failure modes and the fixes that work

A WhatsApp AI agent is a language model wired to a WhatsApp number or group that reads messages, decides what to do and acts through tools: answer from a knowledge base, open a ticket, update a CRM, or hand the conversation to a person. The demo takes an afternoon. Keeping it from embarrassing you in front of a client takes considerably longer.

We run several of these. An agent that keeps a CRM up to date from a partner’s WhatsApp group. An intake flow that reads per-client WhatsApp groups and proposes support tickets. A draft assistant on a support inbox that writes private notes a human sends. A team requests agent that answers from our company wiki and publishes nothing without approval. And ChatWise, our support chat product, which answers on a website widget and WhatsApp from a business’s own content and hands off to a human when it should.

The failure modes below share one trait: the agent does something the prompt explicitly says it must not do. That is the main lesson, so here it is up front: a rule that only lives in the prompt is not a rule. Each section covers how the failure happens, why, and the fix that holds in code.

1. The echo loop in a shared group

How it fails. An agent posts a reply in a WhatsApp group it shares with other people. WhatsApp delivers that message back to the agent as a new incoming message, with the group as sender rather than the agent’s number, so a naive “is this us?” check misses it. The agent answers itself. If the harness also runs tool calls in parallel and the “already sent” flag is set after sending, a single turn can publish several times.

What it costs. A burst of messages in front of everyone in the group, plus side effects the prompt forbids. For example, meetings written to the CRM that nobody scheduled, or a follow-up closed that nobody asked to close.

The fix.

• Treat “sender is the group itself” as the agent’s own message.
• Reserve the single send slot atomically before sending: one send per turn, enforced in code.
• A circuit breaker: the inbox rejects anything past 8 messages in a rolling 60 seconds, so a loop burns out in seconds instead of minutes.
• Do not give the agent a tool that closes records. Let the agent add; make a human close.

2. The agent finds the answer and tells nobody

How it fails. The agent reasons correctly, writes the answer as plain text and ends its turn. In a terminal that is an answer. In a WhatsApp integration it goes to a log nobody reads.

The fix. Every turn must end with one of two explicit tools: reply in the group or no reply needed. If the model ends a turn without calling either, the harness nudges it once, guarded by a flag so the nudge cannot loop. Lost turns are logged under their own label so they can be counted.

3. A due date years in the past

How it fails. Ask an agent to log a pending invoice with a reasonable due date and it can set one years in the past. Models do not know today’s date; they guess from training data.

The fix. Prefix every message the agent sees with the real date, the weekday and the local timezone. With that in place, “call them on Monday” resolves to the correct Monday. It is one line of code and it belongs in every agent you build.

4. An ID that does not exist

How it fails. The model reports a plausible ID instead of the one the tool returned. Say the agent creates follow-up 4 and then confirms to the group that it created “follow-up 14”. Plausible, wrong, and now in writing in front of everyone in the group.

The fix. The tool layer records every ID that tools actually returned during the turn. The reply tool rejects any message that cites an ID outside that set. Record permissively and match tightly: a false rejection leaves the agent unable to answer, which is worse than it sounds when someone is waiting.

5. Right client, wrong conversation

How it fails. One client can have several WhatsApp groups. A report arrives in the second group, and an intake that matches by client attaches it to an open ticket from the first group. It takes the “follow-up” path, and if follow-ups do not send an acknowledgment, the client hears nothing.

The fix. Match by channel, not only by client. The general rule: whenever an identity can have several channels, scope every lookup to the channel the message came from.

6. Hiding the agent’s messages hides a human’s too

How it fails. The obvious fix for echoes is to drop every message sent from the agent’s own number. But people often write from that same number by hand. The agent loses the context of a human reply, reads the next message on its own and acts on it, for example by creating a client with tax ID “1”.

The fix.

• Messages from the shared line reach the agent as labelled context instead of being dropped.
• The agent’s own posts are written to a sent ledger before sending, so an echo can never arrive before the record of what was sent. The ledger is what tells “the agent said this” apart from “a human said this”.
• People are identified by phone number, never by display name.
• The create-client tool rejects names of group members and tax IDs shorter than six characters.

7. A prompt is not a sandbox

What to watch for. This applies to any chat agent, on WhatsApp or a team chat. If a third-party bridge passes its posting key into the agent’s environment and the agent runtime has a shell, any instruction the model follows, including one hidden in a message, can reach that key.

The fix. Isolation at the operating system level: the agent runs with no inherited environment, a read-only filesystem and a network allowlist. The key lives with a separate service user, and the agent reaches it only through narrow tools over a local socket. Use a harness that enforces a tool allowlist itself instead of trusting the model to respect one.

8. “We already notified the team” when nobody was notified

How it fails. This one is universal: any agent that acts and then reports, on WhatsApp or anywhere else. Say an agent merges a client’s change, pushes it, and only then builds the site. The build fails. The agent still tells the client “we notified the team”, and nothing was sent. Changes queued behind the broken one can fail with it.

The fix. Build before merging, so a broken change never lands. Confirm to the user only after the effect has happened, and make every failure leave a trace you can search for, whether or not anything else is configured.

The patterns we build in from day one

• Narrow tools, enforced by the harness. The send tool has no recipient parameter; where it sends is fixed in configuration.
• One job at a time, fresh session per message. The inbox writes each job to a file and answers immediately. Each session starts clean plus a short, labelled slice of recent history, so nothing drifts across hours of context.
• Rate caps and one send per turn. Cheap, and they turn a loop from an incident into a log line.
• Ledgers before side effects. Write down what you are about to send, then send it.
• Humans close, agents add. Our rule: agents can create tickets, follow-ups and drafts, while closing, deleting and invoicing stay with people. On our WhatsApp agents, that is enforced by which tools they get.
• Human handoff as a first-class route. In ChatWise, a router chooses between answering from the knowledge base, using a tool or escalating to a person, with a reason and a confidence score. The handoff happens only when the customer explicitly asks for a person, and a second check confirms it before it goes ahead. A person can also switch the conversation to manual mode, where the AI stays quiet.
• An evaluation suite defined before launch. Cases in every language the agent speaks, covering prompt injection, refusing to invent prices, honest tool errors and switching languages mid-conversation, with the pass bar set before the first run and no misses allowed on safety cases.
• Plan for the official API. Our recommendation for anything customer-facing is the WhatsApp Business Cloud API. Unofficial clients are cheaper to start with but risk a ban from Meta, so we design the transport as a replaceable piece the agent does not depend on.

Where to start

If you are putting an AI agent on WhatsApp for customer support, start with a narrow scope: answer from your own content, and hand off everything else. Turn on the human handoff before the AI answers its first message, not after the first complaint. Decide early what the agent should remember between conversations. And assume that anything you only wrote in the prompt will eventually happen anyway.

That is how we build ChatWise and the custom agents we deliver to clients. If you want one for your business, let’s talk.