WhatsApp Interactive Messages: Buttons and Lists With AI Agents

WhatsApp Interactive Messages: Buttons and Lists With AI Agents

WhatsApp interactive messages, meaning buttons and lists, show the customer a closed set of options to tap instead of asking them to type. Use them when the answer fits a few known choices, such as department, time slot or type of request, and leave free text for anything unpredictable. Paired with an AI agent, they reduce ambiguity: the AI interprets what the customer writes and proposes the options, and your system receives a choice with an identifier, not a loose sentence.

Key takeaways

• Buttons are for short decisions that are hard to get wrong (yes or no, confirm or reschedule). Lists are for choosing among several options of the same kind.
• Free text remains the best way to describe problems, questions and context. A closed interface does not replace the conversation, it organizes it.
• The AI agent understands intent in natural language, and interactive messages confirm what matters before any action with real consequences.
• Every button and every list row carries an identifier that your system validates. The customer's reply becomes structured data, easier to log and audit.
• Start with one flow, measure whether ambiguity actually dropped, and always keep an exit to a human agent.

What are buttons and lists in the WhatsApp API?

In the official WhatsApp Business API (the one that goes through Meta, directly or via a provider), an interactive message is one that includes tappable elements alongside the text. The two formats most used in customer support are:

• Reply buttons: a few buttons below the message. The customer taps one and your system receives the identifier and the title that was chosen.
• List: a button that opens a menu with sections and rows, each with a title, a short description and an identifier. It fits more options than buttons, but still within a limit.

There are also call-to-action buttons, such as opening a link or placing a call, which serve a different purpose: taking the customer out of the conversation. This article focuses on the first two, because they capture a decision inside the chat itself.

The exact limits (number of buttons, number of rows, title length) and the usage rules change over time and depend on the format. Always check Meta's official documentation or your provider's before designing the flow. There is also the customer service window rule: inside it you can reply with free-form and interactive messages. Outside it, reaching out first depends on approved templates and consent. That topic is covered in WhatsApp outbound messages: templates, opt-in and best practices.

When should you use buttons, a list or free text?

The useful question is not "which format is more modern" but "how many valid answers exist and how much does a mistake cost". A simple decision guide:

• Use buttons when there are two or a few possible answers and the choice triggers something: confirming a time slot, accepting a proposal, authorizing a document to be sent.
• Use a list when there is a known set of similar options: locations, services, available dates, reasons for contact.
• Use free text when the customer needs to describe something: a defect, a technical question, a particular situation, an unusual request.
• Use free text plus a button confirmation when the AI has interpreted a sentence and is about to act. Example: the customer writes "I want to move it to Friday morning", the AI understands the intent and replies with a summary and two buttons, confirm or correct.
• Use neither when the subject is sensitive, emotional or a complaint. In those cases a closed interface feels bureaucratic, and the better move is to hand over to a person.

A practical rule: if you already know the acceptable answers in advance, offer them. If you need to listen before you know, let the customer talk.

How do an AI agent and interactive messages work together?

A well-designed AI agent is good at understanding loose language, but it is also the least predictable part of the system. Interactive messages do the opposite job: they are predictable and limited. Together, they split the work in a healthy way.

The design that usually works has four moves:

• The customer writes freely. The AI identifies the intent and any data already present in the sentence.
• If a piece of data from a known set is missing, the agent asks for it with a list or buttons instead of an open question. This avoids replies like "any day is fine" or "the usual one".
• Before an action with consequences (scheduling, canceling, registering an order), the agent presents a summary and asks for confirmation with a button.
• The reply reaches your system as an identifier. Your code validates and executes it, and the result goes into a decision log.

The core idea is that the AI proposes and the system decides. The model should not invent options: the list rows come from a reliable source (calendar, catalog, customer record), and the model only chooses when to show them. This pattern of separating deterministic flow from what needs judgment also appears in the discussion of guardrails for AI agents and in Anthropic's material on building effective agents, which recommends starting with the simplest solution and adding autonomy only where it pays off.

Step by step: designing an interactive flow

A roadmap to get started without ending up in endless menus:

• Step 1, pick one flow: a single use case, such as rescheduling an appointment or triaging the reason for contact. For the scheduling case in detail, see automatic appointment scheduling on WhatsApp with AI.
• Step 2, map the valid answers: from real conversations, list what customers ask for and which fields the system needs to carry it out.
• Step 3, separate closed from open: whatever has a finite list becomes a button or list, whatever depends on context stays as free text.
• Step 4, define the source of the options: where the rows come from (calendar, catalog, service table) and who keeps that source up to date.
• Step 5, write short texts: clear titles, a description only when it helps, no internal company jargon.
• Step 6, treat the choice as data: validate the received identifier on the server and check that it belongs to the options actually sent in that conversation.
• Step 7, plan the exit: every list needs an option such as "talk to a person" or "something else", which leads to free text or a handover.
• Step 8, log everything: keep the message sent, the option chosen and the action executed, so you can review mistakes.

Illustrative scenario: rescheduling at a maintenance company

Imagine, as a hypothetical example, an equipment maintenance company that receives rescheduling requests on WhatsApp. The customer writes: "I need to change next week's visit, I won't be there".

Without interactive messages, the conversation would start a long exchange: which visit, which day, which period, which address. Each open question invites a vague answer.

With the combined flow, the agent identifies the intent to reschedule and queries the system to find the customer's visit. If there is more than one, it shows a list of the scheduled visits. Then it shows a list of the next time slots that are actually free, pulled from the calendar. Finally, it sends a summary (visit, new date, period) with buttons to confirm or pick another time.

If the customer says something unexpected, such as "the technician broke my gate last time", the agent does not push the menu. It recognizes that the subject is different, records the context and hands over to a person. The menu serves the common path, it does not trap the customer in it.

What mistakes and risks should you watch for?

Some problems show up often when you mix a closed interface with AI:

• Too many menus: chaining many choice screens is tiring. If the customer already gave the data in their sentence, the agent should skip the question.
• Options invented by the model: row text should come from real data. Letting the model generate time slots or prices is asking for an expensive error.
• Blind trust in the identifier: treat what arrives from the webhook as input to validate, and free text as untrusted input. A customer can write instructions disguised as a request, and defensive practice against that is described in OWASP's guidance on prompt injection prevention.
• Old button, new action: a customer can tap a message from days ago. Tie each interaction to a conversation state and reject choices that no longer make sense.
• Too much personal data: ask only for what the action needs. Under Brazil's LGPD, define purpose, legal basis and retention for the history, and consult the ANPD guidance. If an automated decision affects the customer in a significant way, it is worth knowing the right to review described in LGPD automated decision-making: the right to review.
• No human exit: a list without "talk to a person" turns convenience into frustration.

How we apply the method: map, limit, pilot, hand over

The method we use in WhatsApp AI agent projects applies directly to this topic. First, map: understand the current process, which messages arrive and where there is the most back and forth because of unclear wording. Then, limit: define which data and actions the agent can touch, and which options it can offer. Next, pilot: choose one real flow, with conversation logs and a success criterion agreed beforehand (for example, fewer messages to finish the task or fewer corrections made by people). Finally, hand over: keep the handoff to a human agent and decide, with the logs in hand, whether to expand, adjust or stop. To compare the pilot with the starting point, the guide on how to measure an AI automation pilot helps define metrics and decision gates.

Frequently asked questions

Do buttons and lists work outside the customer service window? In general, free-form interactive messages are sent inside the service window opened by the customer. To start contact outside it, you need approved templates, which can include quick reply buttons. Check the current rules in Meta's documentation and handle customer consent carefully.

Can the AI generate the list options on its own? It is not recommended for data with consequences, such as time slots, deadlines and amounts. Options should come from a reliable source, such as a calendar or catalog, and the model only decides when and how to present them. That way the customer never picks something that does not exist.

Do buttons replace free text in customer support? No. They work best as a complement: free text captures context and intent, and buttons close the decision precisely. If the customer ignores the menu and types, the agent must continue the conversation normally or hand over to a person.

How do you know if interactive messages improved support? Compare the flow before and after using the same criterion defined at the start of the pilot, such as the number of messages to finish the task, corrections made by agents and conversations handed over. Review a sample of conversations with the decision logs. If the gain does not show up, adjust the options or go back to free text at that point.

Sources

• Anthropic: Building effective agents
• OWASP: prompt injection prevention
• ANPD: Autoridade Nacional de Proteção de Dados
• Anthropic: Writing effective tools for agents