Mi agente de reserva le dijo a un viajero «todo listo» sin hotel. Dejé de confiar en el LLM para dirigir el flujo.

La noche en que mi agente le dijo a un viajero que había reservado una habitación que no existía

Estaba observando cómo corría un prototipo cuando ocurrió. Mi primer agente de reserva de viajes, un diseño LLM-in-the-loop perfectamente ordinario, acababa de emitir un billete de Chicago a San Francisco. El siguiente paso, retener el hotel, falló. La tarifa había caducado en los segundos entre dos llamadas a la API. Y mi agente, tan alegre como siempre, respondió: «¡Todo listo! He reservado tu vuelo y tu hotel, tu número de confirmación es TRV-4821. ¡Que tengas un gran viaje!»

No había hotel. Había un billete real, emitido, y un viajero que ahora creía que tenía una habitación esperándolo. Había construido algo que dejaría a una persona plantada y sonreiría al respecto.

Quiero ser preciso sobre mi reacción, porque no fue «el modelo cometió un error». El modelo hizo exactamente lo que le pedí. El fallo fue estructural, no intelectual. Había entregado a un razonador estocástico la autoridad de decidir qué había ocurrido en el mundo real, y cuando el mundo discrepó de su plan, narró el plan en lugar del mundo. Ninguna cantidad de «sé cuidadoso» en el prompt del sistema iba a arreglar eso, aunque me llevó un tiempo embarazosamente largo admitirlo.

Había construido algo que dejaría a una persona plantada y sonreiría al respecto.

Esa noche es la razón por la que existe la demo que quiero describir. Puedes ejecutarla tú mismo en veriprajna.com/es/demos/reserva-de-viajes-con-ia-agentica-para-tmcs-y-otas, pero la parte interesante no son los botones. Es lo que tuve que desaprender para construirlos.

¿Qué le debe un agente a un viajero al que deja plantado?

Seguí volviendo a un caso legal mientras construía esto. En febrero de 2024, el Tribunal de Resolución Civil de la Columbia Británica ordenó a Air Canada pagar 812,02 dólares a un pasajero después de que el chatbot de la aerolínea inventara una política de tarifas por duelo que no existía (Moffatt v. Air Canada, 2024). Air Canada argumentó, más o menos, que el chatbot era una entidad separada responsable de sus propias palabras. El tribunal lo rechazó. Quien despliega el sistema es dueño de cada declaración que hace su agente.

Leí esa sentencia como un constructor de producto lee un informe de error de producción. La empresa responde por la frase, no el modelo. Si mi agente le dice a alguien «todo listo» y esa persona llega a un hotel sin reserva, «fue la IA» no es una defensa que nadie tenga que aceptar. Eso reformuló todo el problema para mí. No estaba construyendo un asistente servicial. Estaba construyendo algo que hablaría en nombre de Veriprajna sobre dinero y viajes, y tenía que poder responder por cada palabra.

Lo cual significaba que el fallo de «todo listo» no era una arista áspera para pulir después. Era el producto entero, invertido. La pregunta dejó de ser «cómo hago el modelo más inteligente» y pasó a ser «cómo me aseguro de que el modelo nunca sea lo que decide que una reserva tuvo éxito».

Primero intenté salir a base de prompts. Aquí está la matemática que me detuvo.

Mi primer instinto, claro, fue arreglar el prompt. Le di al agente instrucciones severas: verifica que el hotel existe antes de mencionarlo, nunca confirmes un viaje si algún paso falló, di siempre la verdad sobre lo que ocurrió. En mis pruebas manuales se comportó de maravilla. Me sentí bien durante aproximadamente un día.

Luego empecé a inyectar los fallos que realmente ocurren en la infraestructura de viajes. Una tarifa que caduca después de emitir un billete. Una retención rechazada aguas abajo. Una tormenta de búsquedas. Y el hermoso comportamiento se derrumbó, no porque las instrucciones estuvieran mal, sino porque una cadena de razonamiento que es fiable al 90 % por paso no es fiable al 90 % a lo largo de un viaje. Diez pasos secuenciales al 90 % cada uno es 0,9 elevado a la décima potencia, aproximadamente un 34 % de extremo a extremo. Los errores se componen, y ninguna instrucción individual se sitúa en esa composición.

Los números publicados son peores de lo que mi intuición había sido. En TravelPlanner, el benchmark del grupo OSU NLP, GPT-4 con un bucle de agente ReAct completa itinerarios reales de varios días al 0,6 % (arXiv 2402.01622). No sesenta por ciento. Cero coma seis. Ese es el techo honesto de «dejar que un modelo inteligente dirija todo el flujo» para cualquier cosa con más de un par de pasos dependientes.

No puedes salir a base de prompts de un fallo estocástico que se compone.

La frase que acabé escribiendo en una pizarra fue contundente: no puedes salir a base de prompts de un fallo estocástico que se compone. Los fallos contra los que luchaba, una tarifa que caduca entre dos llamadas, una retención rechazada después de un billete, no eran fallos de IQ del modelo en absoluto. Eran eventos de infraestructura, y seguirían ocurriendo al mismo ritmo si cambiara a un modelo diez veces más inteligente. Ese fue el momento en que la arquitectura se volcó en mi cabeza.

Los agentes aconsejan, el código decide

Reconstruí la cosa alrededor de una regla que podría poner en una pegatina: el LLM propone, el código dispone. En la demo, el flujo de control es una máquina de estados en Python hecha a mano de unos diez nodos, y al modelo se le permiten exactamente dos trabajos. Parsea la petición en lenguaje natural a un objeto tipado, y al final mismo redacta la respuesta humana. Todo lo que hay en medio, búsqueda, política, verificación, retención, emisión, reserva de hotel, commit, es Python determinista que o se ejecuta o no.

Dos de esos nodos son puertas, y es ahí donde vive la honestidad. La puerta de política compila las reglas de viajes corporativos en código llano: solo economía, un tope de tarifa de 600 $ por segmento, transportistas preferidos, un tope de 350 $ por noche de hotel. Las opciones fuera de política no se marcan a posteriori, son físicamente no presentables, filtradas antes de que puedan llegar al viajero. Una familia tarifaria desconocida falla de forma segura, tratada como por encima de la política en lugar de dejarla pasar como economía.

La puerta de verificación es de la que estoy más orgulloso. Antes de mostrar cualquier hotel, se confirma contra el sistema de reservas por ID de propiedad. Cuando la petición nombra una propiedad que el modelo inventó, la puerta no encuentra coincidencia y se niega a mostrarla. El agente se abstiene y lo dice, en lugar de fabricar un resort que suene plausible.

Necesito ser honesto sobre lo que esa captura de pantalla es y no es. «Tabacon Springs Eco-Lodge» es una propiedad sintética que fabriqué a propósito, un nombre mezclado de dos resorts reales, para demostrar el modo de fallo. El sistema de reservas, el GDS, la emisión y el pago son todos stubs simulados. No hay ninguna cuenta en vivo de Amadeus o Sabre detrás de esto. Lo que es real es el mecanismo: una puerta que rechaza el inventario que no puede confirmar, situada en el código donde el modelo no puede convencerla de que lo deje pasar.

Por qué el rollback del Saga es lo que separa una demo de un producto

Podría haberme detenido en las puertas y tener una demo agradable. La razón por la que no lo hice es el fallo que empezó todo esto: el paso del hotel que muere después de que el vuelo ya está emitido. Una puerta no te ayuda ahí. El billete es real. La habitación ya no está. Algo tiene que limpiar.

Así que cada paso hacia adelante en la máquina registra su propia acción inversa en el momento en que se ejecuta. La emisión registra «anular billete, ventana de 24 horas». Retener inventario registra su liberación. Esto es el patrón Saga, y cuando un paso falla a mitad de una reserva, el motor ejecuta esas compensaciones en orden inverso y solo entonces informa de lo que ocurrió. Al viajero se le dice la verdad: el billete fue anulado, no hay cargo, aquí hay alternativas que puedes confirmar ahora.

Ver ese rollback dispararse por primera vez, el billete anulándose solo sin que yo tocara nada, es lo más cerca que he estado de la sensación de un sistema que es digno de confianza en lugar de meramente ingenioso. El rollback del Saga es lo que la mayoría de demos se saltan, y es exactamente lo que separa una demo de un producto. Es poco glamuroso. También es toda la diferencia entre «todo listo» y un honesto «no pude completar esto, y esto es lo que hice al respecto».

El rollback es poco glamuroso. También es toda la diferencia entre un viajero plantado y una disculpa honesta.

La demo muestra esto lado a lado contra un agente ReAct real, la línea base de LLM en control, ejecutada en el escenario idéntico. Eso fue deliberado. No quería vencer a un hombre de paja. Quería la comparación honesta, el mismo fallo inyectado en ambos, de modo que la diferencia que ves sea arquitectura y nada más.

¿Qué demuestra el benchmark, y qué no?

Ejecuté ambas arquitecturas a través del mismo lote porque no confiaba en mis propias anécdotas. Doscientas reservas sintéticas, una semilla fija, los mismos fallos de infraestructura inyectados, a través del motor determinista y a través de la línea base de LLM en control. Los resultados, por construcción sobre ese lote sintético de 200 escenarios con semilla fija, son contundentes.

Quiero ser cuidadoso con esos números, porque la versión cuidadosa es la honesta. El 100 %, el cero plantados, el cero fabricados son verdaderos por construcción sobre un lote sintético con semilla fija, no una garantía de mundo abierto que pueda hacer sobre tu tráfico de producción. Las garantías deterministas se sostienen porque el código no puede hacer otra cosa. Los fallos de la línea base emergen de los mismos datos. Si lo afirmas en términos más amplios, has cruzado de un resultado real al marketing, que es precisamente aquello contra lo que esta empresa lleva el nombre.

El número del que más me encuentro hablando es el último. 3,25 $ frente a 7,57 $ de gasto medio de búsqueda GDS. Las búsquedas, no solo las reservas, se facturan a aproximadamente 3 a 3,50 $ por segmento, y Lufthansa volvió a subir esas tarifas el 1 de enero de 2026. Un agente especulativo que vuelve a buscar en cada paso de razonamiento quema ese margen. Un flujo determinista con caché no. Esa brecha es un número de margen, y se sostiene a cualquier calidad de modelo, que es el punto entero.

La parte que me deja dormir: el recibo

Construí una cosa más antes de darlo por terminado, y es la menos vistosa y la que más me importa. Cada reserva escribe un rastro de auditoría JSON append-only: el modelo y la versión, la petición tipada, cada nodo con su veredicto determinista, cada compensación Saga que se disparó, la bandera de divulgación del Artículo 50 de la Ley de IA de la UE, y el estado terminal. Puedes exportarlo como un único archivo.

Sigo pensando en Air Canada. Cuando algo sale mal, y en los viajes algo siempre acaba saliendo mal, la pregunta que un responsable de cumplimiento tiene que responder es «qué le dijo el agente al viajero, y podemos demostrar por qué». El Artículo 50 de la Ley de IA de la UE, con obligaciones de transparencia aplicables desde el 2 de agosto de 2026, va a hacer esa pregunta rutinaria. Un flujo determinista con un veredicto en cada nodo te da una respuesta. Una cadena de razonamiento te da una transcripción y un encogimiento de hombros.

Si quieres pulsar los botones tú mismo, todo está en vivo en veriprajna.com/es/demos/reserva-de-viajes-con-ia-agentica-para-tmcs-y-otas. Rómpelo si puedes. Para eso está.

¿Sobre qué cambié realmente de opinión?

Empecé esto creyendo que un modelo lo bastante bueno acabaría haciendo todo esto innecesario, que el determinismo era una muleta para el interim pre-AGI. Ya no lo creo. Los fallos contra los que pasé semanas diseñando no están esperando a que llegue un modelo más inteligente. Una tarifa sigue caducando entre dos llamadas. Una retención sigue siendo rechazada después de emitir un billete. Esas son propiedades de la infraestructura, no de la inteligencia, y un razonador perfecto deja plantado a un viajero tan a fondo como uno mediocre si nada en el sistema está construido para anular el billete.

Y si preferirías verlo en lugar de leerme describirlo, aquí está todo corriendo de extremo a extremo.

Así que la pregunta que sigo haciendo a otras personas que construyen agentes es la que tuve que hacerme aquella noche, viendo a mi creación mentir tan placenteramente. Cuando tu agente le dice a un cliente «todo listo», ¿qué en tu sistema sabe realmente que es verdad? Si la respuesta es «el modelo, probablemente», no tienes un problema de modelo. Tienes un problema de flujo de control, y me gustaría genuinamente saber cómo planeas resolverlo.