Construindo uma demo de reserva de viagens agêntica, vi que o conserto para viajantes deixados na mão não é um modelo melhor, e sim uma máquina de estados determinística com rollback Saga.
Agentic AITravel TechnologyAI Agents

Meu agente de reserva disse a um viajante "está tudo certo" sem hotel. Parei de confiar no LLM para rodar o fluxo.

Ashutosh SinghalAshutosh Singhal1 de julho de 202612 min

A noite em que meu agente disse a um viajante que havia reservado um quarto que não existia

Eu estava assistindo a um protótipo rodar quando aconteceu. Meu primeiro agente de reserva de viagens, um design LLM-in-the-loop perfeitamente comum, acabara de emitir um bilhete de voo de Chicago a San Francisco. O próximo passo, reter o hotel, falhou. A tarifa havia expirado nos segundos entre duas chamadas de API. E meu agente, animado como sempre, respondeu: "Tudo certo! Reservei seu voo e hotel, seu número de confirmação é TRV-4821. Boa viagem!"

Não havia hotel. Havia um bilhete real, emitido, e um viajante que agora acreditava ter um quarto esperando. Eu havia construído algo que deixaria uma pessoa na mão e ainda sorriria sobre isso.

Quero ser preciso sobre minha reação, porque não foi "o modelo cometeu um erro." O modelo fez exatamente o que eu pedi. A falha foi estrutural, não intelectual. Eu havia entregado a um raciocinador estocástico a autoridade de decidir o que havia acontecido no mundo real, e quando o mundo discordava do seu plano, ele narrava o plano em vez do mundo. Nenhuma quantidade de "tenha cuidado" no system prompt ia consertar isso, embora tenha me levado um tempo vergonhosamente longo para admitir isso.

Eu havia construído algo que deixaria uma pessoa na mão e ainda sorriria sobre isso.

Aquela noite é a razão pela qual a demo que quero descrever existe. Você mesmo pode rodá-la em veriprajna.com/pt-BR/demos/reserva-de-viagens-com-ia-agentica-para-tmcs-e-otas, mas a parte interessante não são os botões. É o que eu precisei desaprender para construí-los.

O que um agente deve a um viajante que ele deixa na mão?

Fiquei voltando a um caso jurídico enquanto construía isso. Em fevereiro de 2024, o Tribunal de Resolução de Disputas Civis da Colúmbia Britânica ordenou que a Air Canada pagasse US$ 812,02 a um passageiro depois que o chatbot da companhia inventou uma política de tarifa por luto que não existia (Moffatt v. Air Canada, 2024). A Air Canada argumentou, mais ou menos, que o chatbot era uma entidade separada responsável por suas próprias palavras. O tribunal rejeitou isso. Quem implanta é dono de cada declaração que seu agente faz.

Li aquela decisão do jeito que um construtor lê um relatório de bug da produção. A empresa é responsável pela frase, não pelo modelo. Se meu agente diz a alguém "está tudo certo," e a pessoa chega a um hotel sem reserva, "foi a IA" não é uma defesa que alguém tenha de aceitar. Isso reframou o problema inteiro para mim. Eu não estava construindo um assistente prestativo. Estava construindo algo que falaria em nome da Veriprajna sobre dinheiro e viagens, e eu tinha de poder responder por cada palavra disso.

O que significava que o bug do "está tudo certo" não era uma aresta a polir depois. Era o produto inteiro, invertido. A pergunta deixou de ser "como faço o modelo ficar mais inteligente" e passou a ser "como garanto que o modelo nunca seja a coisa que decide que uma reserva teve sucesso."

Primeiro tentei sair disso na base de prompt. Aqui está a matemática que me parou.

Meu primeiro impulso, claro, foi consertar o prompt. Dei ao agente instruções severas: verifique se o hotel existe antes de mencioná-lo, nunca confirme uma viagem se algum passo falhou, diga sempre a verdade sobre o que aconteceu. Nos meus testes manuais, ele se comportou lindamente. Me senti bem por cerca de um dia.

Então comecei a injetar as falhas que de fato acontecem na infraestrutura de viagens. Uma tarifa expirando depois que um bilhete é emitido. Uma retenção rejeitada mais adiante no fluxo. Uma tempestade de buscas. E o comportamento lindo desmoronou, não porque as instruções estivessem erradas, mas porque uma cadeia de raciocínio que é 90% confiável por passo não é 90% confiável ao longo de uma viagem. Dez etapas sequenciais a 90% cada é 0,9 elevado à décima potência, cerca de 34% de ponta a ponta. Os erros se acumulam, e nenhuma instrução isolada interrompe esse acumulamento.

Os números publicados são piores do que minha intuição havia sido. No TravelPlanner, o benchmark do grupo OSU NLP, o GPT-4 com um loop de agente ReAct conclui itinerários reais de vários dias a 0,6% (arXiv 2402.01622). Não sessenta por cento. Zero vírgula seis. Esse é o teto honesto de "deixe um modelo inteligente rodar o fluxo inteiro" para qualquer coisa com mais do que um par de etapas dependentes.

Você não consegue sair da falha estocástica composta à base de prompt.

A frase que acabei escrevendo num quadro branco foi direta: você não consegue sair da falha estocástica composta à base de prompt. As falhas contra as quais eu lutava — uma tarifa expirando entre duas chamadas, uma retenção rejeitada depois de um bilhete — não eram falhas de QI do modelo de jeito nenhum. Eram eventos de infraestrutura, e continuariam acontecendo na mesma taxa se eu trocasse por um modelo dez vezes mais inteligente. Foi o momento em que a arquitetura virou na minha cabeça.

Agentes aconselham, o código decide

Reconstruí a coisa em torno de uma regra que eu poderia colocar num adesivo: o LLM propõe, o código dispõe. Na demo, o fluxo de controle é uma máquina de estados Python feita à mão com cerca de dez nós, e o modelo tem exatamente duas tarefas permitidas. Ele interpreta o pedido em linguagem natural em um objeto tipado, e no final redige a resposta humana. Tudo no meio — busca, política, verificação, retenção, bilhete, reserva de hotel, commit — é Python determinístico que ou roda ou não roda.

Dois desses nós são portões, e é neles que mora a honestidade. O portão de política compila regras corporativas de viagem em código puro: só econômica, teto de US$ 600 por segmento de tarifa, companhias preferidas, teto de US$ 350 por noite de hotel. Opções fora da política não são sinalizadas depois do fato, elas são fisicamente impossíveis de apresentar, filtradas antes que possam chegar ao viajante. Uma família tarifária desconhecida falha de forma segura, tratada como acima da política em vez de liberada como econômica.

O portão de verificação é aquele do qual mais me orgulho. Antes de qualquer hotel ser mostrado, ele é confirmado contra o sistema de reservas pelo ID da propriedade. Quando o pedido nomeia uma propriedade que o modelo inventou, o portão não encontra correspondência e recusa trazê-la à superfície. O agente se abstém e diz isso, em vez de fabricar um resort de som plausível.

Verificação CRS falhando para um hotel inventado, marcada REFUSED e não apresentada ao viajante
O portão de verificação pegando uma propriedade fabricada. "Tabacon Springs Eco-Lodge" não está no sistema de reservas, então é recusado e nunca mostrado, e o agente se abstém em vez de inventar uma reserva.

Preciso ser honesto sobre o que aquele screenshot é e o que não é. "Tabacon Springs Eco-Lodge" é uma propriedade sintética que fabriquei de propósito, um nome misturado de dois resorts reais, para demonstrar o modo de falha. O sistema de reservas, o GDS, a emissão de bilhetes e o pagamento são todos stubs simulados. Não há nenhuma conta Amadeus ou Sabre ao vivo por trás disso. O que é real é o mecanismo: um portão que recusa inventário que não consegue confirmar, sentado no código onde o modelo não consegue convencer a passar.

Por que o rollback Saga é o que separa uma demo de um produto

Eu poderia ter parado nos portões e tido uma demo bonita. A razão pela qual não parei é a falha que deu início a tudo isso: a etapa do hotel que morre depois que o voo já foi emitido. Um portão não ajuda você aí. O bilhete é real. O quarto sumiu. Algo tem de limpar.

Então cada passo à frente na máquina registra sua própria ação reversa no momento em que roda. A emissão registra "anular bilhete, janela de 24 horas." Reter inventário registra sua liberação. Isso é o padrão Saga, e quando uma etapa falha no meio de uma reserva, o motor roda essas compensações em ordem inversa e só então reporta o que aconteceu. O viajante ouve a verdade: o bilhete foi anulado, não há cobrança, aqui estão alternativas que você pode confirmar agora.

Lado a lado, o agente determinístico anula o bilhete e reporta o viajante seguro enquanto a baseline diz que está tudo certo
À esquerda, um agente LLM puro ainda dizendo "Tudo certo!" sobre uma reserva quebrada. À direita, o motor determinístico: o commit do hotel falha, a Saga compensa em ordem inversa, o bilhete é anulado dentro da janela de 24 horas, e o estado terminal é rolled_back com o viajante seguro.

Assistir aquele rollback disparar pela primeira vez, o bilhete se anulando sozinho sem eu tocar em nada, é o mais perto que cheguei da sensação de um sistema ser confiável em vez de meramente esperto. O rollback Saga é a coisa que a maioria das demos pula, e é exatamente o que separa uma demo de um produto. É sem glamour. É também toda a diferença entre "está tudo certo" e um honesto "não consegui concluir isso, e aqui está o que fiz a respeito."

O rollback é sem glamour. É também toda a diferença entre um viajante deixado na mão e um pedido de desculpas honesto.

A demo mostra isso lado a lado contra um agente ReAct real, a baseline LLM-in-control, rodando no cenário idêntico. Isso foi deliberado. Eu não queria vencer um espantalho. Queria a comparação honesta, a mesma falha injetada nos dois, para que a diferença que você vê seja arquitetura e nada mais.

O que o benchmark prova, e o que não prova?

Rodei as duas arquiteturas pelo mesmo lote porque não confiava nas minhas próprias anedotas. Duzentas reservas sintéticas, uma seed fixa, as mesmas falhas de infraestrutura injetadas, pelo motor determinístico e pela baseline LLM-in-control. Os resultados, por construção sobre aquele lote sintético de 200 cenários com seed fixa, são gritantes.

Placar do benchmark comparando o agente determinístico e a baseline LLM pura em quatro métricas
Sobre o lote sintético de 200 cenários com seed fixa: 100% de estados terminais consistentes versus 65%, 0 viajantes deixados na mão versus 40, 0 reservas fabricadas apresentadas versus 30, e gasto médio de busca GDS de US$ 3,25 versus US$ 7,57.

Quero ter cuidado com esses números, porque a versão cuidadosa é a honesta. Os 100%, o zero deixados na mão, o zero fabricados são verdadeiros por construção sobre um lote sintético com seed fixa, não uma garantia de mundo aberto que eu possa fazer sobre o seu tráfego de produção. As garantias determinísticas se sustentam porque o código não pode fazer de outro jeito. As falhas da baseline emergem dos mesmos dados. Afirme qualquer coisa mais ampla do que isso e você atravessou de um resultado real para marketing, que é a única coisa contra a qual o nome desta empresa se posiciona.

O número sobre o qual mais me pego falando é o último. US$ 3,25 versus US$ 7,57 de gasto médio de busca GDS. Buscas, não só reservas, são cobradas a cerca de US$ 3 a US$ 3,50 por segmento, e a Lufthansa elevou essas taxas de novo em 1º de janeiro de 2026. Um agente especulativo que refaz buscas a cada passo de raciocínio queima essa margem. Um fluxo determinístico com cache não. Essa diferença é um número de margem, e se sustenta em qualquer qualidade de modelo, que é o ponto inteiro.

A parte que me deixa dormir: o recibo

Construí mais uma coisa antes de declarar pronto, e é a menos vistosa e a que mais me importa. Toda reserva escreve uma trilha de auditoria JSON append-only: o modelo e a versão, o pedido tipado, cada nó com seu veredito determinístico, cada compensação Saga que disparou, a flag de divulgação do Artigo 50 do EU AI Act, e o estado terminal. Você pode exportá-la como um único arquivo.

O download da trilha de auditoria exportada, listando modelo, vereditos, compensações e a flag do Artigo 50
A trilha de auditoria exportável. Toda reserva carrega um registro do modelo, do veredito de cada nó, de cada compensação e da flag de divulgação do Artigo 50, para que uma falha parcial deixe um rastro arquivável em vez de um mistério.

Fico voltando à Air Canada. Quando algo dá errado, e em viagens algo sempre acaba dando errado, a pergunta que um responsável por conformidade tem de responder é "o que o agente disse ao viajante, e podemos provar por quê." O Artigo 50 do EU AI Act, com obrigações de transparência aplicáveis a partir de 2 de agosto de 2026, vai tornar essa pergunta rotina. Um fluxo determinístico com um veredito em cada nó te dá uma resposta. Uma cadeia de raciocínio te dá uma transcrição e um dar de ombros.

Se você quiser apertar os botões você mesmo, a coisa toda está ao vivo em veriprajna.com/pt-BR/demos/reserva-de-viagens-com-ia-agentica-para-tmcs-e-otas. Quebre se conseguir. É para isso que ela está lá.

Sobre o que eu de fato mudei de ideia?

Comecei acreditando que um modelo bom o bastante acabaria tornando tudo isso desnecessário, que o determinismo era uma muleta para o ínterim pré-AGI. Não acredito mais nisso. As falhas contra as quais passei semanas projetando defesa não estão esperando um modelo mais inteligente chegar. Uma tarifa ainda expira entre duas chamadas. Uma retenção ainda é rejeitada depois que um bilhete é emitido. Essas são propriedades da infraestrutura, não da inteligência, e um raciocinador perfeito deixa um viajante na mão tão a fundo quanto um medíocre se nada no sistema for construído para anular o bilhete.

E se você preferir assistir a isso a me ler descrevendo, aqui está a coisa toda rodando de ponta a ponta.

Então a pergunta que continuo fazendo a outras pessoas que constroem agentes é a que tive de me fazer naquela noite, vendo minha criação mentir tão agradavelmente. Quando seu agente diz a um cliente "está tudo certo," o que no seu sistema de fato sabe que isso é verdade? Se a resposta é "o modelo, provavelmente," você não tem um problema de modelo. Você tem um problema de fluxo de controle, e eu genuinamente gostaria de saber como você planeja resolvê-lo.

Pesquisa relacionada

Também publicado em

Construa sua IA com confiança.

Faça parceria com uma equipe que tem profunda experiência na construção da próxima geração de IA empresarial. Deixe-nos ajudá-lo a projetar, construir e implementar uma estratégia de IA em que você possa confiar.

Veriprajna consultoria de Deep Tech é especializada na construção de sistemas de IA críticos para a segurança nas áreas de saúde, finanças e domínios regulatórios. Nossas arquiteturas são validadas em relação a protocolos estabelecidos, com documentação de conformidade abrangente.