Cómo crear un agente de IA para reservas en WhatsApp: arquitectura, prompting, RAG y salida a producción

Tiempo de lectura estimado: 14 minutos

Key takeaways

Diseña un sistema end-to-end con WhatsApp, orquestación, memoria, RAG, base de datos y calendario desacoplado.
El éxito depende de una buena ingeniería de contexto: prompt + memoria + RAG + contratos de herramientas.
Empieza con un MVP usando Evolution API y escala luego a la API oficial de Meta según volumen.
Optimiza costes: prompt en inglés, salida en español, Redis para ráfagas, respuestas breves.
Operación profesional: panel con takeover humano, métricas, logs y RLS en Supabase.
Checklist de producción y roadmap por fases para pasar de prototipo a operación estable.

Resumen y objetivos

Diseñaremos un agente de IA para reservas en WhatsApp listo para producción: un sistema end-to-end que combina chatbot de WhatsApp para reservas, sistema de reservas con inteligencia artificial, memoria, RAG e integración con calendario. Meta: agendar citas de forma fiable, 24/7 y con calidad de recepción humana.

Para quién es y qué aprenderás

Perfil: makers, PMs y devs no-expertos en IA aplicada; dueños de negocio que quieren automatizar sin sacrificar la experiencia.
Resultado: serás capaz de lanzar un sistema replicable y vendible a clientes.
Entregables mentales: arquitectura end-to-end, prompting, orquestación de herramientas, modelo de datos y calendario, frontend operativo y mejores prácticas.

“Garbage in, garbage out.” La calidad del contexto determina la calidad de la respuesta. Tu trabajo no es programar al LLM; es darle el mundo en el que opera.

Visión general del sistema (end-to-end)

Componentes y flujo

WhatsApp: integración vía Evolution API (alternativa: API oficial de Meta). Maneja texto y audio con voz a texto para captar peticiones.
Orquestación: n8n para flujos, herramientas y control de estados.
LLM: OpenAI como motor conversacional.
Memoria: corto plazo (historial reciente) y largo plazo (CEP) con hechos por usuario.
RAG/base de conocimiento: FAQs + documentos del negocio (pgvector).
Cache/cola: Redis para agrupar mensajes en ráfaga y mejorar contexto.
Base transaccional: Supabase: reservas, usuarios, conversaciones, flags de human in the loop y RAG.
Calendario: Google Calendar desacoplado con tablas “Calendar Slots/Reservations” para disponibilidad y resiliencia (calendario desacoplado).
Frontend de operación: panel con conversaciones, “tomar conversación”, calendario y gestor de documentos.

Demostración: clínica de fisioterapia

Flujo real “hola” → “reserva confirmada”

Usuario: “Hola, quiero para el jueves por la tarde, 60 min”.
Redis agrupa si envía varios mensajes seguidos.
LLM detecta intención: “buscar horarios”.
Search Slots consulta Calendar Slots/Reservations y propone 3 opciones.
Usuario elige opción.
Book Slot asigna profesional con balanceo, persiste en DB, crea evento en Google Calendar y envía email.
LLM confirma con tono natural en menos de 2 minutos (confirmación rápida).

Extras

Modificar/cancelar con nombre y nº de reserva desde el propio agente (cambios y cancelaciones).
Si se complica, un operador humano toma el control desde el panel (takeover humano).

¿Por qué ahora?

WhatsApp domina: canal con mayor adopción; un chatbot puede operar 24/7 y escalar conversaciones (WhatsApp operativo).
Time-to-value corto: costes a la baja; hoy puedes levantar un MVP en minutos con plataformas modernas (MVP rápido).

Núcleo del éxito: ingeniería de contexto

Idea clave: la salida depende del contexto. Define rol, reglas, memoria, herramientas y estilo. Tu prompt + memoria + RAG = calidad.

Estructura del prompt (en inglés, salida en español de España)

Role and personality: “You are a clinic receptionist on WhatsApp. Warm, concise, helpful. Max 100 words per message. If long, split in 2–3 WhatsApp-style messages.”
Background con memorias: usar etiquetas tipo <MEMORY_L> y <MEMORY_S> para inyectar hechos y últimos mensajes.
Style and language: “Always reply in Spanish (Spain), natural WhatsApp tone, evita expresiones LATAM.”
Fechas: “Today is 12/06/2025 — Thursday. Always include date + weekday.”
Herramientas con contrato explícito: define argumentos, cuándo usar y el “shape” esperado por respuesta.
Plantillas conversacionales: buscar horarios → proponer 2–3 → pedir confirmación → reservar → confirmar con datos.

Optimización de coste y contexto: prompt en inglés, respuesta en español; menos tokens y menos fallos. Divide respuestas largas en 2–3 mensajes al estilo WhatsApp.

Ejemplo:

“Te paso tres opciones para 60 min: jueves 16:00, 17:00 o 18:30.”
“¿Cuál te viene mejor? Si quieres otro día, dime rango horario.”

Diseño de herramientas del agente

Search Slots (buscar horarios)

Inputs: fecha (DD/MM/AAAA), tipo (30|60).
Lógica: consulta Calendar Slots y Reservations; excluye solapes; devuelve máx. 3 opciones ordenadas.
Respuesta:

{ success: true, date: «12/06/2025 — Thursday», options: [{ start: «16:00», end: «17:00», duration: 60, staff_candidates: [«Ana»,»Luis»] }], notes: «Return max 3» }
Tip: si no hay fecha, inferir rango (“esta semana por la tarde”) y pedir confirmación breve.

Book Slot (reservar)

Inputs: fecha (DD/MM/AAAA), tipo (30|60), nombre, correo.
Tablas: Reservations, Calendar Slots, Staff, Staff Daily Load.
Algoritmo: disponibilidad por profesional → balanceo por carga → anti-colisión → persistir en DB → crear evento en Google Calendar → email.
Respuesta:

{ success: true, reservation_id: «RSV-2025-0612-XYZ», professional: «Ana», start: «12/06/2025 17:00», duration: 60, email_sent: true, next: «Confirm to user with short recap» }
En caso de fallo:

{ success: false, reason: «slot_taken», suggestion: [«17:30″,»18:00»] }

RAG/FAQ

Pipeline: normalizar → retrieve (pgvector) → agregar fragmentos → empaquetar “extended info” al LLM.
Doble RAG: negocio (precios, políticas, ubicaciones) + FAQs (cambios/cancelaciones, qué llevar, aparcamiento).
Frontend: subir/eliminar documentos y re-embeddings bajo demanda (base de conocimiento).
No answer policy: si el score es bajo, pedir aclaración o derivar a humano.

Memoria y estado conversacional

Memoria a corto plazo: últimos N mensajes, con quién dijo qué, marcas de tiempo y entidades.
Memoria a largo plazo (CEP): hechos importantes; recuperar meses después para personalizar (“Hola, Marta…”) (memoria de cliente).

Redis como buffer temporal

Agrupa mensajes en ráfaga (~10 s) para evitar respuestas con contexto incompleto. Ejemplo: “Hola” → “para mañana” → “por la tarde” se procesa como una sola intención coherente.

Integración con WhatsApp

Evolution API vs API oficial de Meta

Evolution API: ideal para empezar y volúmenes bajos-medios; open source, despliegue rápido y coste bajo. Pros: iteración veloz, conexión con n8n en minutos (guía práctica). Contras: para SLAs estrictos, evalúa migración.
API oficial de Meta (WhatsApp Business/Cloud API): robustez, entregabilidad y analíticas; adecuada para alto volumen y multi-país; requiere cumplimiento de políticas y plantillas (Cloud API).

Recomendación: MVP y pilotos con Evolution API; producción estable y escalado con la API oficial o partners (buenas prácticas de escalado).

Manejo de sesiones, estados y “human in the loop”

Identificador de sesión por teléfono; guarda estado en Conversations.
Flag human_in_the_loop: si un operador toma la conversación, el agente se silencia hasta liberar el flag.
Transferencias claras: el agente deja mensaje de cortesía y “aparta” la sesión; el operador lee contexto (memoria + últimos mensajes) antes de responder.
Notas de voz: admite y transcribe; útil para conductores o mayores (voz a texto).

Modelo de datos (base del sistema de reservas con IA)

Bloque reservas

Calendar_Slots: date, start_time, end_time, staff_total, service_type.
Reservations: id, user_id, staff_id, start_datetime, duration, status (pending|confirmed|cancelled|modified), notes.
Staff: id, name, skills, email, active.
Staff_Daily_Load: staff_id, date, sessions_count, minutes_total (para balanceo).

Bloque aplicación

Users: id, phone, name, email, preferences_json.
Conversations: id, user_id, last_state, memory_s, memory_l, last_message_at.
Human_Takeover: conversation_id, taken_by, taken_at, released_at, reason.
Tool_Logs: conversation_id, tool_name, args, result, latency_ms.

Bloque conocimiento (RAG)

Documents: id, title, source, status.
Chunks: document_id, chunk_id, text, embedding (pgvector).

Razones para desacoplar de Google Calendar

Resiliencia: la DB es la fuente de verdad; Calendar es proyección (desacoplar calendario).
Portabilidad y contexto limpio para el LLM; evitas límites/latencias del API en picos.

Seguridad y acceso

RLS en Supabase; scopes por rol; API keys seguras en n8n y variables de entorno.

Frontend operativo (panel)

Conversaciones en tiempo real

Lista de chats con filtros (abiertos, con humano, cerrados).
Vista de mensajes y contexto: Memoria S y L resaltadas.
Botón “Tomar conversación” que activa human in the loop.

Calendario

Vista agenda/semana; filtros por profesional/servicio/estado.
Crear, mover y cancelar con reglas de colisión y logs.

Base de conocimiento

Subir/eliminar documentos; estado de indexación; re-embeddings; control de versiones (gestión de conocimiento).

Métricas esenciales (MVP)

Usuarios únicos, conversaciones, reservas confirmadas, tiempo medio a confirmación, reprogramaciones y cancelaciones.

Logs y trazabilidad

Panel de Tool_Logs con duración y errores; trazas por conversación para depurar prompts y RAG.

Buenas prácticas y trucos de producción

Prompting y contratos

Contratos de herramientas con inputs/outputs y ejemplos reales.
Fecha + día de la semana siempre; limitar a 3 opciones y 100 palabras por mensaje.
“No answer policy” en RAG de baja confianza (política de no respuesta).

Orquestación robusta

Validaciones previas (fecha DD/MM/AAAA, email, tipo 30/60).
Reintentos idempotentes y locks cortos; anti-colisión pre-confirmación.

Idioma y costes

Prompt en inglés; salida en español; respuestas breves WhatsApp-style (optimización de costes).

Diseño de datos

Multi-negocio desde el día 1: tenant_id en todas las tablas; lógica crítica centrada en DB + n8n.

Quality gates y mantenimiento

Pruebas con conversaciones largas, voz a texto, FAQs ambiguas; test de carrera (dos usuarios mismo slot).
Versionar prompts y reglas; re-entrenar embeddings ante cambios.
Seguridad: RLS, rotación de claves, auditoría; limitar endpoints y validar inputs.

Roadmap por fases (implementación guiada)

Fase 1: agente base y prompting (rol, estilo, idioma, contratos).
Fase 2: WhatsApp + Redis (buffer ~10 s, respuestas en 2–3 partes).
Fase 3: Datos + Search/Book + Calendar + correos (Supabase con RLS, balanceo por Staff_Daily_Load).
Fase 4: RAG/FAQ + gestor de documentos y no answer policy (RAG por fases).
Fase 5: Panel operativo + métricas (conversaciones, takeover, calendario, logs y KPIs).

Gracias a las plataformas actuales, un MVP funcional puede estar en minutos y crecer por fases sin rehacer todo (arranque acelerado).

Checklist de salida a producción

Pruebas E2E con servicios de 30/60 min y voz a texto (pruebas con voz).
Test de colisiones y balanceo de profesionales.
Validación de formatos (fecha, email) y timezone.
Fallbacks si RAG no encuentra respuesta o hay baja confianza.
Monitorización de errores en n8n y logs del LLM.
Ensayo completo de human in the loop y retorno al agente.
Confirmación en menos de 2 minutos en escenarios estándar (SLA de confirmación).
Recordatorios automáticos para reducir ausencias (recordatorios).

Conclusión

Crear un agente de IA para reservas en WhatsApp ya es práctico, medible y rentable. Con arquitectura clara (n8n, Supabase, Redis), un buen prompt con ingeniería de contexto, RAG sólido y calendario desacoplado, agendarás citas 24/7 con confirmaciones rápidas y una experiencia cercana a la recepción humana. Añade un panel operativo y buenas prácticas de producción para escalar de un local a una red completa manteniendo control, seguridad y costes a raya (guía de reservas, calendario desacoplado, MVP y escalado).

FAQ

¿En qué se diferencia un chatbot de WhatsApp para reservas de un agente?

Un chatbot clásico sigue flujos rígidos y respuestas predefinidas; un agente usa LLM + herramientas + memoria + RAG. Entiende contexto, decide acciones y aprende con el uso; maneja texto y voz e integra calendario y DB (capacidades del agente).

¿Cuándo usar Evolution API vs API oficial de WhatsApp?

Evolution API: MVP, menor volumen, rapidez y control en VPS. API oficial: alto volumen, compliance, plantillas aprobadas y SLAs (comparativa práctica).

¿Cómo reducir costes al agendar citas con IA?

Prompt en inglés con salida en español; Redis para agrupar mensajes y evitar llamadas de más; limitar opciones y palabras; automatizar recordatorios y cambios/cancelaciones desde el agente (mejores prácticas de coste).

¿Qué es la ingeniería de contexto y cómo se aplica en reservas?

Es definir “el mundo” del agente: rol, reglas, memoria, herramientas y conocimiento (RAG). Así el agente sabe quién es el usuario, qué slots hay y cómo reservar sin errores; resultado: respuestas útiles y consistentes (ingeniería de contexto).

¿Cómo escalar de una clínica a múltiples negocios?

Multi-tenant con tenant_id en todas las tablas; RAG por negocio con índices separados; prompts y estilos por marca; conectores de calendario por tenant; panel con permisos por equipo y negocio.

¿Puede el agente gestionar notas de voz y entender “este jueves por la tarde”?

Sí. Transcribe voz a texto y normaliza fechas relativas; si no hay precisión, pide aclaración breve (voz → texto).

¿Se pueden modificar o cancelar reservas sin llamar?

Sí. El agente pide nombre y nº de reserva, valida y ejecuta en DB y Calendar con confirmación inmediata (modificaciones y cancelaciones).

¿En cuánto tiempo confirma una cita?

En flujos estándar, confirma en menos de 2 minutos tras la interacción (tiempo de confirmación).

¿Qué pasa si el RAG no tiene la respuesta?

Se aplica “no answer policy”: el agente pide aclaración o deriva automáticamente a un humano (política RAG).

¿Cómo se integra con Google Calendar?

Tras confirmar en DB, crea/actualiza el evento vía webhook; la DB es la fuente de verdad y Calendar es un espejo (integración operativa).

¿Sirve para restaurantes, barberías y clínicas?

Sí. Mismo patrón: servicios, duraciones, profesionales/mesas y políticas; ajusta reglas y RAG por sector (patrón multi-sector).

¿Qué métricas vigilar al inicio?

Conversaciones, reservas confirmadas, tiempo a confirmación, tasa de cancelación y derivaciones a humano.

¿Cómo empiezo rápido?

Levanta WhatsApp con Evolution API, orquesta con n8n, usa Supabase + pgvector y un prompt en inglés con salida en español. En minutos tendrás un MVP operando (arranque en minutos).