Agentes de IA vs flujos de trabajo: dónde fallan de verdad las reservas por WhatsApp

Respuesta corta: en un sistema de reservas con IA, lo que suele fallar no es el modelo. Falla la junta, el punto en el que el código determinista y el agente de IA se pasan información. El 28 de octubre de 2026 probamos Conversa, nuestro asistente de WhatsApp para inmobiliarias, de principio a fin y encontramos dos fallos de ese tipo en una sola conversación. Los dos estaban en el código que rodea al modelo, no dentro de él.

La prueba la hicimos sobre nuestra propia agencia de demostración, desde un teléfono del equipo, no con un cliente. Escribimos como escribe un comprador, en el canal real.

Agentes de IA vs flujos de trabajo: la distinción que importa

Anthropic lo explica bien en Building effective agents. Un flujo de trabajo es un sistema en el que los modelos y las herramientas siguen caminos fijados de antemano en el código; en sus palabras, «predefined code paths». Un agente es un sistema en el que el modelo decide por sí mismo qué pasos dar y qué herramientas usar. La recomendación de fondo es buscar la solución más simple posible y dar autonomía al modelo solo donde de verdad la necesita.

Un sistema de IA para reservas de visitas inmobiliarias por WhatsApp mezcla las dos cosas, como casi cualquier sistema serio en producción. En Conversa:

• Flujo. Un enrutador clasifica cada mensaje (pregunta, petición de visita, aceptación), unas reglas fijas llevan la reserva y un control de respuesta revisa lo que sale.
• Agente. El agente de agenda es el único paso en el que el modelo elige herramientas y redacta.
• Herramientas. La disponibilidad real del calendario y el tiempo real de desplazamiento entre visitas.

Cada paso le pasa información al siguiente, y cada traspaso es una junta. Ahí es donde se rompió.

Fallo 1: un control que convirtió una buena respuesta en un callejón sin salida

El comprador pidió ver un piso «mañana a las 12:00». La ficha solo admite visitas los jueves de 12:00 a 13:00, y ese día había otra visita en Vinaròs, a 69 km, que terminaba a las 11:00. La comprobación de desplazamiento calculó que hacían falta 151 minutos para llegar, así que la primera hora posible caía después de que cerrara la franja. Descartó, con razón, todo ese día.

Hasta aquí, todo correcto. El agente de agenda redactó una buena respuesta: recordaba el horario de visitas verificado y proponía el jueves siguiente.

Entonces actuó el control de respuesta, una comprobación determinista que bloquea cualquier dato que el sistema no pueda respaldar. No aceptó como prueba el horario que la propia herramienta de calendario acababa de verificar y sustituyó la oferta entera por esto: «Ahora mismo no tengo ese dato verificado por aquí».

El modelo había acertado. El código que lo vigilaba dejó al comprador sin ninguna opción.

Qué cambiamos: el control ahora confía en los datos de horario que devolvió la propia herramienta de calendario. Una comprobación que falló sigue sin probar nada.

Fallo 2: una regla que solo miraba la hora

El comprador contestó: «Sí, el jueves 5 a las 12:00». Una regla determinista se encarga de averiguar cuál de las horas ofrecidas ha aceptado el comprador, y esa regla comparaba solo la hora. Entre las opciones había dos jueves a las 12:00, el 5 y el 12 de noviembre, así que preguntó: «¿cuál de los dos prefieres?». El comprador ya lo había dicho.

Qué cambiamos: cuando dos opciones coinciden en la hora, decide el día. Primero se lee lo que escribió el comprador. Y una hora que el comprador menciona sin que nadie se la haya ofrecido ya no cuenta como aceptar la propuesta de la IA.

Las dos correcciones salieron el mismo día, cada una con un test de regresión que reproduce el fallo tal como ocurrió en la conversación.

Por qué fallan los agentes de IA en producción

Ninguno de los dos fallos era un error del modelo. Entendió la petición y redactó bien. Lo que falló fue el reparto de confianza entre las piezas: un control que no se fiaba de una herramienta fiable y una regla que volvía a leer texto libre con un criterio demasiado estrecho. Cada pieza funcionaba por separado. El error estaba en la unión.

Lo que aplicamos en cada sistema que construimos

• El modelo propone, el código decide. Reservas, disponibilidad y dinero viven en código. El modelo sirve para entender el lenguaje y redactar respuestas.
• Un control nunca debe convertir una buena respuesta en un callejón sin salida. Si bloquea algo, el comprador tiene que recibir otra opción o una persona.
• Datos estructurados entre pasos. Identificadores de franja en lugar de volver a leer texto libre con patrones. Una regla que recibe el identificador de la franja aceptada no tiene que adivinar.
• Cada rechazo, registrado. Cuando un control bloquea algo, queda escrito por qué. Así se puede ver la razón en lugar de suponerla.
• Cada fallo real, convertido en un test. El test reproduce la conversación que falló, de modo que el mismo error no puede volver sin que nos enteremos.
• Un traspaso limpio a una persona es un éxito. Cuando el sistema no puede confirmar algo, pasar la conversación con contexto a alguien del equipo es la respuesta correcta. Lo explicamos en la guía de traspaso humano y RGPD.

Además, antes de publicar un cambio, un panel de revisores independientes intenta romper el plan. Es mejor encontrar la junta débil en una revisión que en el WhatsApp de un comprador.

Cómo trabajamos en SME Analytica

Hacemos integración de sistemas, software a medida e IA. Probamos nuestros sistemas como los usa un comprador, en canales reales, corregimos lo que se rompe el mismo día y dejamos el fallo escrito en un test. No todo es IA: hay software, integración y datos, y la IA entra donde compensa. Conversa es uno de esos sistemas; si te interesa cómo encaja en una agencia, empieza por la guía de IA por WhatsApp para inmobiliarias.

Si tienes un sistema con IA que funciona en la demo y falla en las uniones, el primer paso es un Reconocimiento: mapeamos el flujo contigo, localizamos las juntas y decidimos qué va en código y qué en el modelo. Cuéntanos qué tienes.