AI agents for restaurants: orders, payments and kitchen

By Lic. J. Andrés A. García · Published June 6, 2026 · Editorial review: October 16, 2026.

An AI agent for restaurants in Colombia can turn a WhatsApp conversation into a structured order: products, quantities, modifications, delivery coverage, payment and fulfillment. Getting that order to the kitchen requires an up-to-date menu and systems that confirm each step. The conversation is the entry point; operations determine whether the order can be fulfilled.

This guide helps restaurant, café, bakery and bar owners evaluate that journey. It explains integration, payment handling, measurement and the costs of a direct channel. For the detailed workflow and Spanish video, also read how to take an order from chat to kitchen (in Spanish).

What an AI agent does in a restaurant

The agent interprets requests and uses authorized tools to check the menu, availability and states. It can clarify quantities, offer compatible options and prepare a summary for the customer. Prices and totals are calculated by the ordering system rather than improvised by the language model.

The choice between a predefined response flow and an AI agent depends on the tasks. A simple flow can answer opening hours or send a menu. Updating a cart, checking stock and recording a kitchen ticket require additional tools. The useful test is to observe the action executed and how its outcome is confirmed.

Eight points worth reviewing

1. Menu and suggestions. Keep products, variants, prices and sold-out items current. Complementary suggestions respect budget and availability.
2. Service. Distinguish an automated reply from order acceptance. Outside operating hours, explain when preparation can start.
3. Direct channel. Calculate its actual costs before comparing it with a delivery marketplace.
4. Kitchen. Define where the ticket appears and who acknowledges receipt.
5. Payments. Handle pending, approved and rejected states, plus refunds.
6. Repeat purchase. Use authorized history and stop contact when requested.
7. Reservations. Confirm actual capacity and terms if table booking is included.
8. Exceptions. Assign owners for complaints, ambiguous addresses and allergy questions.

Messaging can be available continuously, while preparation and delivery depend on opening hours, capacity, stock and coverage. Make that distinction clear in the first message to avoid accepting orders nobody can fulfill.

From the WhatsApp message to the kitchen ticket

A unique order reference connects the conversation, cart, transaction and kitchen. States should represent observable events: draft, awaiting payment, approved, sent to kitchen, received, ready and delivered, according to the agreed process. Record each change once even when a message or notification arrives repeatedly.

1. Capture the order. Confirm products, quantities, variants and fulfillment: table, pickup or delivery.
2. Validate. Check stock, hours, address, coverage and delivery fee. Resolve missing information before charging.
3. Show the total. Summarize the cart and terms so the customer can correct them.
4. Verify payment. Check the provider's status or follow the agreed manual process. Do not infer approval from a screenshot.
5. Send to the kitchen. Record the ticket and check receipt. Make failures visible to the team.
6. Close. Update preparation, dispatch and delivery. Preserve cancellation or refund states where applicable.

When a customer changes the order

A change before payment can recalculate the cart. After payment or kitchen dispatch, it may require authorization, a payment adjustment or refund. The agent must recognize the current state and hand over when the request exceeds its permissions. The restaurant's commercial policy determines the response.

Allergies and dietary restrictions need a clear route to the team. The assistant communicates only validated information; it does not infer ingredients, cross-contamination or safety from a dish name. Missing or uncertain information leaves the order pending human confirmation.

POS, kitchen display and payments: verify each connection

Before quoting, identify the POS name and version, API access, permissions and test environment. Check whether it supports reading menu items, stock, prices, modifiers and taxes, as well as creating and updating orders. An API does not necessarily support all those operations.

Where the required connection is unavailable, options include an independent kitchen display or a manual review and entry stage. Specify which system holds the order, how it reconciles with the till and which tasks the team retains. Do not promise universal compatibility based on a POS brand alone.

A link or QR starts payment; the provider confirms its state

Automated payment needs a reference and a verifiable state. As one technical example, Mercado Pago documents webhooks, testing and origin validation. The implementation must verify the event, check the transaction and handle retries without duplicating actions.

Bre-B enables interoperable transfers and payments through participating institutions. This does not give the agent direct system access: automatic reconciliation depends on the selected institution or provider's capabilities. A transfer verifiable only manually needs that step in the workflow.

WhatsApp and Instagram have their own requirements

Number enablement, permissions and templates are separate checks; the WhatsApp API approval guide explains those distinctions. Instagram is a separate technical scope. Meta's webhook material distinguishes delivery states, including failure; an accepted send request does not prove customer receipt.

Comparing direct channels, marketplaces and repeat purchase

A direct channel has acquisition, technology, payment, preparation, packaging, delivery and service costs. Compare it with a marketplace using the restaurant's actual contract and settlement statements. Commissions, promotions and included services vary; there is no single percentage that applies to every business.

Average order value divides sales by orders, with consistent rules for discounts, delivery and refunds. An extra suggestion can raise the total while adding little margin. Measure acceptance, cost and complaints before expanding contextual upselling.

For repeat purchase, distinguish first-time buyers from customers returning within a comparable period. The retention versus acquisition guide develops that measurement. The WhatsApp policy requires permission for subsequent contact, honoring opt-outs and approved templates outside the 24-hour service window.

Document the purposes, access and retention of customer history under Law 1581 of 2012. Installing a points program does not by itself settle personal-data obligations.

What to request in a budget and how to test the system

Separate setup, monthly operation and third-party usage. Setup describes the menu, rules, WhatsApp, order integration and testing. The monthly scope defines support and included adjustments. POS, payment gateway, delivery, infrastructure, Meta messages and model usage need clear terms, including whether they are charged separately.

The Cocina Conectada catalog lists price in your MD account for setup and price in your MD account for monthly operation to signed-in users. Review the current restaurant service scope and confirm included connections in your proposal. Meta enablement and provider access must be accounted for when setting dates.

Start with a limited menu, one channel and one fulfillment method. Test sold-out products, out-of-area addresses, pending payments, duplicate events, a disconnected kitchen and cancellation. Check that each exception has an owner and that the system never announces success without confirmation.

During the pilot, measure confirmed orders, abandonment, pending payments, time to kitchen receipt, errors, cancellations and repeat purchase. Compare with the restaurant's own baseline. The restaurant demonstration explores a simulated flow; to review your POS and operation, request a diagnostic conversation. Those inputs determine what to automate first.