The key idea
A useful WhatsApp agent connects a customer’s request to a real operation in your app, then explains the result. Start with one workflow you can complete reliably.
Your customer already has WhatsApp open. They want to move a booking, check an order or find the right product. An AI agent gives them a way to do that by sending a message, while your existing application remains the place where the work happens.
The design question is simple: what should the customer be able to finish without leaving the conversation? A precise answer is a much better starting point than a long list of things the agent could discuss.
What is a WhatsApp AI agent?
A WhatsApp AI agent is a conversational interface connected to tools and business data. It interprets a request, gets the information it needs, takes an allowed action and reports the outcome in chat.
For a booking app, that might mean finding an appointment, checking available times and moving the booking after the customer confirms. For a shop, it could mean looking up an order and explaining its current status. The model handles language; your backend decides which operations are valid.
The basic architecture has four parts:
- WhatsApp connection: receives customer messages and sends replies.
- Conversation state: keeps track of the request and the details already supplied.
- Agent and tools: choose an appropriate operation and call your app’s API or MCP server.
- Your application: stores the order, booking or account record and returns the actual result.
If you want that same workflow on other channels, see the unified messaging API guide.
Agent or chatbot?
Both can be useful. Choose based on the job, rather than the label.
| Customer need | A scripted chatbot | An agent with tools |
|---|---|---|
| Opening hours | Returns a prepared answer | Can answer from the same business facts |
| Order status | Often sends a tracking link | Can look up the customer’s order |
| Rescheduling | Follows predefined menus | Can ask for missing details and check live availability |
| Exceptions | Needs an explicit branch | Can explain the problem and offer an allowed next step |
An agent earns its complexity when customer requests vary and the answer depends on live data. A fixed reply is often enough for a fixed question. You can use both in one experience.
Build one complete workflow
Consider rescheduling an appointment. Define the whole operation before connecting a model:
- Find the customer’s booking using a verified identity or booking reference.
- Read available slots from the scheduling system.
- Ask the customer to choose and confirm a new time.
- Update the booking once and return its saved time and reference.
Here is an illustrative conversation, assuming your backend exposes those operations:
Customer: Can I move tomorrow’s appointment to Friday afternoon?
Agent: I found your appointment. Friday has 2:30 pm and 4 pm available. Which works?
Customer: 4 pm.
Agent: Shall I move your appointment to Friday at 4 pm?
Customer: Yes.
Agent: Done — your appointment is now Friday at 4 pm. Your booking reference is BK-1042.
The final answer must follow a successful update. If the slot disappears, the agent should explain that and fetch another option. It should never turn a proposed booking into a claimed booking just because the conversation sounds complete.
Give each tool a narrow job. A find_booking operation is easier to control than a general “manage the calendar” operation. Keep authorization in your backend: a phone number alone should not grant access to every booking on an account. For payments, use your existing checkout or payment flow when it is exposed by your integration.
With Flow, start by describing the workflow and providing your app’s API or MCP connection. Review what the agent can do in the builder before connecting the customer channel. Start building your agent.
Understand the messaging window
On the WhatsApp Business Platform, customer messages open or reset a 24-hour service window. Free-form replies belong inside that window; approved templates are required outside it. Obtain the relevant opt-in for proactive contact, respect opt-outs and give customers a clear route to support. These requirements come from WhatsApp’s Business Messaging Policy.
Separate that platform rule from the features of the API you use. Flow’s current owner API sends free-form messages to existing customers inside the allowed window; it does not provide template sending. A scheduled update can therefore become ineligible before it runs. Design the application to handle that outcome rather than repeatedly retrying a message that cannot be sent.
For your own messaging integration, confirm the business account, number connection and provider requirements during setup. Costs can include channel delivery, the messaging provider and model usage. Check the current rate cards for your actual recipient markets and message types before estimating a monthly bill.
Send an update with Flow’s API
This example queues a fixed order update for a customer who has already messaged your connected WhatsApp bot. Replace 42 with your bot ID and the recipient with an existing customer. Create an API key in Flow’s Settings → API, and keep it on your server.
curl -X POST 'https://flow.engineer/api/v1/bots/42/messages' \
-H "Authorization: Bearer $FLOW_API_KEY" \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: order-1042-ready' \
-d '{
"to": "whatsapp:+14155550123",
"text": "Your order 1042 is ready for pickup."
}'An accepted request returns 202, which means queued, rather than delivered. Use the returned message ID with GET /api/v1/bots/42/messages/{id} to read its status. Reuse the same idempotency key when retrying the same event so a network timeout does not create two updates.
Use prompt instead of text when you want the agent to compose the update using its instructions and tools. That path can perform real tool operations, so give it a specific task with the same permissions you would allow in a customer conversation.
Launch with a clear success metric
Start with a small set of actual customer tasks. Include a normal request, missing details, an unavailable slot, a backend error and a request outside the agent’s scope. Observe whether the customer reaches the intended result and whether your application records it correctly.
Measure completed workflows, avoidable support transfers and delivery failures. A quick reply that creates the wrong booking is not a success. Improve the tool boundary or clarification step where conversations get stuck, then expand to another workflow.
Frequently asked questions
Can I connect an existing app?
Yes. Start with the API or MCP server that exposes the operations you want customers to use. Describe the workflow to Flow and supply the connection details. The agent’s useful actions depend on what that backend actually supports.
Can it send messages to any phone number?
Flow’s current owner API addresses customers who already wrote to the connected bot, subject to the WhatsApp window. It is not an endpoint for cold outreach to arbitrary numbers.
Can the same agent work on Telegram?
You can reuse business operations and instructions across interfaces, while keeping channel identities and delivery rules separate. The Telegram AI agent guide explains the bot setup and update flow.
Where should I start?
Choose one task your app already performs well. Connect that operation, make the conversation clear and launch from there. Build it with Flow.
