Desarrollo de Agente AI para Peluquería: Arquitectura, Stack y Latencia Reales

Contexto de negocio: si buscas la visión general y no técnica del producto, lee primero Agente IA para Peluquerías. Este artículo es la contraparte de ingeniería.

Requisitos reales del dominio: por qué una peluquería rompe un prototipo estándar

La mayoría de tutoriales de "agente AI + WhatsApp" cubren el caso ideal: usuario escribe, LLM contesta, fin. Una peluquería introduce restricciones que ese prototipo no soporta.

Antes de decidir stack, conviene enumerar los requisitos que hemos visto repetirse en implementaciones reales con salones de entre 2 y 15 sillones:

• Estado transaccional en agenda. Cada reserva bloquea una silla y un profesional durante un intervalo. Dos clientes escribiendo a la vez no pueden ocupar el mismo hueco. Requiere concurrencia con bloqueos optimistas o transacciones cortas sobre la fuente de verdad de la agenda.
• Multi-recurso. Una mecha con secado no es "1 hora en 1 silla". Suele ser 45 min con la técnica X, 30 min de reposo bloqueando silla pero no persona, y 20 min de peinado con la técnica Y. El agente tiene que resolver este puzzle de recursos.
• Latencia p95 <10 s. Por encima de eso los usuarios cierran la conversación. Con dos llamadas a LLM en serie y una consulta a la agenda, el presupuesto es duro.
• Idempotencia. WhatsApp Business API reenvía webhooks si no respondes con 200 en menos de 20 segundos. Sin idempotencia, una reserva se duplica.
• Trazabilidad. El agente accede a datos personales (nombre, teléfono, historial de servicios). Hay que registrar quién hizo qué, cuándo y con qué prompt.
• Escalado a humano. Preguntas ambiguas (queja, reclamación, alergia), cambios de precio, promociones fuera de catálogo. El agente tiene que ceder la conversación con contexto.

Antes de escribir código, este listado marca el corte entre un demo de fin de semana y un agente de IA personalizado que aguanta un sábado por la tarde con 40 mensajes activos.

Arquitectura de referencia en cuatro capas

Los sistemas que hemos puesto en producción para peluquerías siguen una arquitectura de cuatro capas. No es la única, pero sí la que resuelve los seis requisitos anteriores con el menor número de componentes.

Capa 1: Ingress WhatsApp (webhook receiver)

Recibe los webhooks de WhatsApp Business Cloud API. Es un HTTP endpoint que devuelve 200 en menos de 200 ms. No hace nada más que validar la firma HMAC de Meta, guardar el evento en una cola (Redis Streams, SQS o NATS) y responder. Cualquier lógica pesada dentro de este endpoint acaba en reintentos y mensajes duplicados.

Detalles que ahorran incidentes:

• Deduplicación por message_id. Meta reintenta si tu servicio tarda o falla.
• Verificación del webhook con el verify_token en el GET inicial.
• Rate limit por número de origen para bloquear spam antes de que gaste tokens de LLM.

Capa 2: Orquestador con RAG de catálogo

Consume la cola y decide la respuesta. Es donde vive la lógica del agente. Un patrón que funciona:

• Un router ligero (modelo pequeño o clasificador propio) etiqueta la intención: reserva, cambio, cancelación, precios, queja, otra.
• Un LLM más grande (Claude Sonnet 4.5 o GPT-4.1 en producción, con fallback a un modelo local para picos) toma la conversación completa y decide qué herramienta invocar.
• Un RAG con el catálogo del salón (servicios, duraciones, precios, promociones, políticas de cancelación) inyecta contexto solo cuando el router lo pide, no en cada mensaje.

El RAG no vive en un vector store separado si el catálogo cabe en 2.000 tokens. Lo hemos visto muchas veces: 40 servicios con variantes caben en un JSON en memoria, sirviendo con caché por versión, y evitas la latencia del retrieval.

Capa 3: Conector de negocio (agenda y CRM)

Herramientas expuestas al LLM en formato tool-use. Las cinco imprescindibles:

• availability.list(service_id, from, to, professional_id?)
• booking.create(client_id, service_id, slot, professional_id) con clave de idempotencia derivada del message_id
• booking.update(booking_id, changes)
• booking.cancel(booking_id, reason)
• client.upsert(phone, name, tags)

El diseño de estas funciones importa más que el modelo. Un LLM potente con herramientas mal diseñadas produce resultados peores que un modelo medio con herramientas bien tipadas y errores claros. Los error deben ser accionables: SLOT_TAKEN, PROFESSIONAL_OFF, SERVICE_UNKNOWN. El LLM aprende a reintentar solo si el mensaje de error es semántico, no un stacktrace.

Capa 4: Ejecutor y observabilidad

Envía la respuesta al usuario vía WhatsApp Business API, escribe el evento en el CRM, guarda la traza (prompt, tool calls, resultados) y actualiza métricas. Aquí es donde vive la trazabilidad completa. Sin esto, cuando un cliente reclama "el bot me cobró de más", nadie puede reconstruir la conversación.

Todo el flujo se apoya en WhatsApp Business integrado al CRM como fuente única de verdad del cliente y del ticket.

Presupuesto de latencia: los 10 segundos importan más que el modelo

Un agente para peluquería vive o muere en el p95 de latencia. Por encima de 10 segundos, la conversión se cae en picado. Los datos internos de nuestros salones piloto muestran que cada segundo por encima de 8 s baja un 4-6% la tasa de reserva confirmada.

Presupuesto real para un turno completo (mensaje entra, respuesta sale):

Etapa	Objetivo p95	Realista con Cloud API
Webhook ingress + encolado	<150 ms	90 ms
Router de intención	<400 ms	350 ms (Haiku 4.5, contexto pequeño)
LLM principal (con tool-use)	<3.500 ms	2.400 ms (Sonnet 4.5, 1 turn)
Consulta a agenda (tool)	<250 ms	120 ms (Postgres indexado por (professional, slot))
LLM final (formato respuesta)	<2.000 ms	1.100 ms
WhatsApp Send Message API	<400 ms	280 ms
Total p95 end-to-end	<7.000 ms	~4.500 ms

Cloud API de WhatsApp soporta hasta 500 mensajes por segundo, por lo que el bottleneck rara vez está en Meta. Está en cómo enlaces los pasos. Tres decisiones que hemos visto derribar el presupuesto:

• Streaming inutil. El streaming del LLM no llega al usuario final en WhatsApp: el mensaje se envía cuando termina. Streaming en tu backend solo sirve para cancelar temprano si detectas hallucination o política violada.
• Un solo modelo para todo. Usar Sonnet para clasificar la intención cuesta 5x más tiempo y 20x más dinero que un modelo Haiku. El router pequeño paga solo.
• Consultas a la agenda sin caché. El slot list de "hoy y mañana para servicio X" se pide 30 veces por hora los sábados. Caché en Redis por 60 segundos con invalidación en booking.create baja la latencia de esta tool a <30 ms.

Stack de referencia (2026)

No hay un stack único correcto. Sí hay combinaciones que hemos visto llegar a producción con menos incidentes. Este es el stack por defecto en los últimos ocho salones que hemos migrado:

• Mensajería: WhatsApp Business Cloud API con número dedicado y plantillas aprobadas para mensajes proactivos (recordatorios y encuestas post-servicio).
• Runtime: Node.js 22 con Fastify, o Python 3.12 con FastAPI. Elección por afinidad del equipo, no por rendimiento; ambos superan holgadamente la carga.
• Cola: Redis Streams para volumen pequeño (<10k msg/día). Si tienes cadena de 50 sillones, mejor NATS JetStream con dead-letter queue.
• Base de datos: PostgreSQL 16 con dos tablas críticas: slot_lock (con constraint UNIQUE sobre (professional_id, slot_start)) para evitar dobles reservas, y agent_event particionada por día para las trazas.
• LLMs: Claude Haiku 4.5 para router y clasificaciones, Sonnet 4.5 para el turno con tool-use. Fallback a un modelo local (Llama 3.3 70B fine-tuneado sobre 300 conversaciones históricas anonimizadas) para picos.
• Observabilidad: Langfuse o Helicone para trazas de LLM, OpenTelemetry para el resto del stack, Grafana para dashboards de latencia p95 por etapa.
• Deploy: Fly.io o Railway para el runtime, Neon o Supabase para Postgres. GitHub Actions con blue-green deploy: WhatsApp no perdona downtime.

Este stack no es barato en tiempo de ingeniería. Un desarrollador senior tarda entre 3 y 6 semanas en llevarlo a producción estable con tests end-to-end. Es la razón por la que muchos salones optan por comprar un CRM con WhatsApp integrado en lugar de construir. Pero si tu operación tiene particularidades reales (multi-marca, políticas complejas, integración con TPV propietario), construir sale a cuenta.

Errores caros que hemos cometido y visto cometer

Cuatro patrones que aparecen en casi todos los proyectos que fracasan:

1. Prompt-only sin schema estricto en tools. El LLM inventa parámetros. Solución: JSON Schema con additionalProperties: false y validación server-side. El error del schema vuelve como prompt al modelo para que reintente.
2. Sin límite de turnos por conversación. Un usuario mal intencionado agota los tokens con un loop de "y ahora dime otro horario". Límite duro: 12 turnos por conversación en 24 horas antes de forzar escalado humano.
3. Fecha implícita. "Sábado a las 10" en martes es distinto que en jueves. El sistema debe inyectar la fecha actual del salón (zona horaria del local, no del servidor) en el system prompt de cada turno.
4. Sin pruebas contra el catálogo real. Un salón añade un servicio ("balayage express") y el agente lo confunde con "balayage" completo. Antes de cada deploy, batería de 40-60 conversaciones sintéticas contra el catálogo vigente. Sin regresión, no hay merge.

Coste real: build vs. buy con números encima de la mesa

Los costes que aparecen a continuación son medios de proyectos reales cerrados en 2025-2026 en salones de España y LATAM. La comparación no es "custom siempre gana". Es cuánto pagas y cuánto vale para tu operación.

Build in-house

• Desarrollo inicial: 3-6 semanas de un senior full-stack con experiencia en LLMs = 12.000-24.000 euros según mercado.
• Infraestructura mensual: WhatsApp Cloud API (por conversación de utilidad iniciada por el negocio, en peluquería ronda 0,02-0,04 euros; gratis las iniciadas por el cliente dentro de la ventana de 24 horas), Postgres, Redis, deploy = 60-140 euros/mes.
• Coste LLM en un salón de 4 sillones con 2.500 conversaciones/mes: 90-160 euros con la mezcla Haiku + Sonnet 4.5 descrita arriba.
• Mantenimiento: 4-8 horas al mes de un ingeniero para monitor, tuning de prompts y actualización de catálogo = 400-800 euros/mes al coste interno.

Total primer año: 18.000-33.000 euros según seniority del equipo y volumen del salón.

Buy (plataforma tipo ZENIA)

• Setup one-off con integración a tu agenda y CRM: 997 euros.
• Suscripción Growth (WhatsApp API, agente, CRM, mantenimiento incluido): 497 euros/mes.

Total primer año: 6.961 euros. La diferencia son 11.000-26.000 euros y tres meses de time-to-market. La ecuación se invierte cuando (1) tu equipo interno ya mantiene infraestructura similar, (2) el salón forma parte de una operación multi-vertical que reutiliza el stack, o (3) hay integraciones propietarias que el proveedor no puede tocar (TPV custom, sistema fiscal específico, ERP interno).

Métricas post-lanzamiento a monitorizar en semana 1

Un agente en producción sin dashboard es una caja negra. Cinco métricas que hemos aprendido a mirar antes de tocar nada más:

Métrica	Umbral saludable	Señal roja
Latencia p95 end-to-end	<7 s	>12 s en 15 min consecutivos
Tasa de escalado a humano	6-12%	>20% (prompt roto o catálogo obsoleto)
Tasa de reserva por conversación entrante	28-42%	<18% (agente no cierra)
Errores de tool en 24h	<0,5% de calls	>3% (integración inestable)
No-shows sobre reservas confirmadas	4-8%	>12% (recordatorios mal configurados)

Datos internos y estudios de sector coinciden en el impacto que consigue una implementación bien hecha: WhatsApp abre entre el 80% y el 90% de sus mensajes frente al 45-60% de SMS y 20-25% del email, y los salones con recordatorios automatizados reducen no-shows entre un 30% y un 40%. Ese salto es lo que justifica el proyecto; monitorizar es lo que lo mantiene vivo.

Cuándo tiene sentido construir y cuándo no

Si operas un solo salón con menos de 10 sillones, construir desde cero rara vez sale a cuenta. El tiempo hasta ver la primera reserva reservada por el agente es muy largo comparado con adoptar un agente de IA para peluquerías ya empaquetado.

Construir tiene sentido cuando (a) eres una agencia o software house que va a re-vender la solución a varios salones y necesitas el control sobre roadmap y datos, (b) tienes ingeniería interna y quieres que el agente forme parte de tu producto principal, o (c) la integración con tu operación (facturación electrónica, TPV, ERP) no se puede resolver con webhooks estándar.

En cualquier otro caso, comprar y personalizar la última milla es más barato, más rápido y menos frágil. La ingeniería no está en la moda del framework; está en resolver la agenda con concurrencia, la latencia y la observabilidad. Si ya hay un producto que hace eso bien, gastar semanas replicándolo casi nunca compensa.