We built an AI coach that guides participants of a 30-day development programme through a conversation on WhatsApp. The language model was the simplest part of the project. The harder parts were the platform's own rules, running hundreds of conversations concurrently, and the situations in which the bot should hand a conversation over to a human while nothing in the metrics says so.
Below are the lessons that will be useful to anyone planning a bot on WhatsApp Business. The platform data comes from our analysis in early 2026. Meta changes its rules fairly often, so check them again before you start.
Limits apply to the whole business, not to a number
Messages initiated by the business, such as reminders or broadcasts, are subject to daily limits. A starting account can send 250 such conversations a day, and the next tiers are 1,000, 10,000 and 100,000. Moving up a tier requires a high quality rating and using at least half of the current limit for a week.
Since October 2025 the limit has been shared across the whole business portfolio in Meta, not per number. In practice this means the popular idea that "three numbers give three times the limit" does not work. A new number inherits the portfolio limit. The only way to more throughput is a higher tier.
For product architecture something else matters more: the limit does not apply to conversations started by the user. When a participant writes, the business has 24 hours to reply freely. After that it can only send an approved template. So it is worth designing the product so that most traffic is started by the person, and templates are used to open a conversation, for example a morning reminder about a task.
Number quality matters more than throughput
Meta rates the quality of a number, and a drop in that rating leads to sending restrictions and a lower tier. The rating is affected by spam reports and user blocks, as well as repetitive content and sending too often. Reports against one number weigh on the whole portfolio.
Several decisions follow from this:
- The bot works during the day in the participants' time zone. Evening and night messages go to a queue, and morning replies go out with a random offset, not all on the hour.
- Bulk messages go out in batches with pauses, through a single worker with a per-minute limit.
- Each message type has several versions, picked at random when sending. Repetition hurts the quality rating and, as our audit confirmed, gives away the automation to people.
- An extra number does not raise the limit, but it isolates risk if something happens to the first one. The test environment should have a separate portfolio.
With a new number, it is worth increasing volume gradually over several weeks instead of starting with the full recipient list.
Provider: we stayed with Twilio
We considered moving to a cheaper intermediary or to the Meta API directly. At this scale the saving on messages would have been smaller than the risk of a migration just before launch, and limits are counted per portfolio anyway, so changing provider would not have added throughput. We will revisit the decision at several thousand active users, where the price difference starts to matter.
Architecture for hundreds of simultaneous conversations
The webhook from the operator verifies the signature of every request and rejects duplicates by message identifier. The message then goes to a queue, not straight to the model.
People write on WhatsApp in bursts of short messages. If the bot replied to each one separately, the conversation would be chaotic and expensive. So each number has a delayed job in the queue, which every new message pushes back. The bot waits a few seconds, longer when a message looks unfinished, and replies once to the whole utterance. Each message is stored separately, so the history is complete.
Model calls go through a limiter with a queue. If the model does not respond in a reasonable time, the participant gets a short fallback message and the conversation goes to a human. An error in one conversation does not stop the others, and the team has a kill switch for the AI, both global and per conversation.
Two bugs only surfaced in production. The job identifier in the queue cannot contain a colon, which we had used in the key with the phone number. The second was a race when deleting a job that was being processed at that moment. Both are minor, but they show well why a new feature is worth releasing behind a switch, with a safe default behaviour.
Escalation: low model confidence is not enough
A conversation goes to humans in several situations. Crisis signals have the highest priority: the AI falls silent immediately and the person on duty gets a notification. Beyond that come low confidence in the answer, a negative rating from a second model that checks every answer before it is sent, and the case where a knowledge base search finds no confident match. In that case the bot does not guess, it hands the conversation over.
The most valuable lesson came from a manual audit of 747 messages after the first few days. Average model confidence was 0.973, and yet one person got stuck in a loop: the bot repeated the same instruction dozens of times and did not react to a request for help. The metrics did not show it. We added escalation after a series of failed attempts and on requests for human help. The audit also found one hallucination and a case where the model guessed which task of the programme was current. Since then the stage of the programme has been decided by the schedule in the system, not by the model.
The conclusion is simple: high average confidence does not measure quality. Alongside metrics you need a regular review of real conversations by a human.
Costs
In the first 11 days the system handled 1,248 messages, and the AI sent 597 of 601 replies without human involvement. The AI cost in that period was 13.20 USD, about 0.022 USD per reply. The largest part was generating replies (8.36 USD), followed by operator costs (2.99 USD), reranking of search results (1.19 USD), scoring replies with a cheaper model (0.48 USD) and embeddings (0.18 USD).
Merging a burst of messages into one reply works twice here: it improves the conversation and lowers the cost, because three short messages cost as much as one reply, not three.
Cost forecasts for a larger scale depend heavily on assumptions about the number of exchanges per day, so instead of a single figure we calculate them in scenarios. With user-initiated traffic the operator cost is small, and it grows quickly when the product relies on frequent broadcasts.
Checklist before launch
- Check the current limit rules and Meta's pricing, because they change several times a year.
- Design the product so that most conversations are started by the user.
- Prepare and get templates approved in advance, in several variants, including a template that reopens a conversation after 24 hours.
- Handle opt-outs before the first user asks for one.
- Connect the number quality rating and the block rate to alerts, not only to manual checks in the dashboard.
- Plan escalation for loops and requests for help, not only for low model confidence.
- Run a manual review of conversations after the first week and repeat it regularly.
The whole implementation is described in the case study.
