Reserva de viagens com IA agêntica para TMCs e OTAs

O passo maduro para um agente de reservas não é um modelo mais inteligente. É tirar o LLM do fluxo de controle.

Construímos um agente autônomo de reserva de viagens cujo fluxo de controle é Python determinístico. O modelo só interpreta o pedido de viagem e redige a resposta. Cada etapa da reserva registra uma ação compensatória; assim, quando a tarifa do hotel expira depois que o voo já foi emitido, o agente anula o bilhete dentro da janela de 24 horas e entrega ao viajante alternativas honestas, em vez de deixá-lo encalhado.

100%

Estado terminal consistente, por construção

Lote sintético de 200 cenários com semente fixa, vs 65% da linha de base LLM-no-controle

0 / 0

Viajantes encalhados, reservas fabricadas apresentadas

Mesmo lote, vs 40 e 30 da linha de base

$3.25

Gasto médio de busca no GDS por reserva

vs $7.57 da linha de base; o GDS cobra por busca; a Lufthansa aumentou as taxas em 1º de janeiro de 2026

Todos os cenários são sintéticos sobre um GDS e um CRS simulados; códigos de aeroporto e nomes de hotéis são fixtures com forma real, não inventário ao vivo nem reservas reais.

Coloque um LLM no comando de uma transação e duas coisas dão errado

Nenhuma delas é uma falha de QI do modelo. Ambas já são uma classe de bug de 2026.

Ele encalha viajantes

O agente emite o bilhete do voo, a etapa do hotel falha e, sem lógica de compensação, ainda diz "Está tudo certo." Alguém fica com um voo e sem quarto. Um modelo perfeito ainda encalha um viajante se nada anular o bilhete.

Ele apresenta inventário que não existe

Ele inventa um hotel plausível e o reserva. A propriedade nunca esteve no CRS. Nada verificou antes de chegar ao viajante, porque em um loop de raciocínio o modelo é ao mesmo tempo o proponente e o juiz.

A razão pela qual um modelo melhor não resolve isso é que as falhas são eventos de infraestrutura e de uso, independentes da qualidade do modelo. Uma tarifa expira entre duas chamadas de API. Uma retenção é recusada depois que um bilhete é emitido. Uma tempestade de buscas queima a margem. O raciocínio estocástico se acumula contra isso: dez etapas a 90 por cento de confiabilidade resultam em cerca de 34 por cento de ponta a ponta, e o GPT-4 com ReAct conclui itinerários reais de vários dias a 0.6 por cento (TravelPlanner, OSU NLP, arXiv 2402.01622). Não se sai de uma falha estocástica composta só com prompt.

E o deployer é dono de cada afirmação que o agente faz. Em Moffatt v. Air Canada (BC Civil Resolution Tribunal, 14 de fevereiro de 2024) a companhia aérea foi condenada a pagar $812.02 depois que seu chatbot inventou uma política de tarifa por luto, e o argumento de que a IA era uma entidade separada foi rejeitado.

Como funciona: os agentes aconselham, o código decide

O fluxo de controle é uma máquina de estados Python feita à mão, com cerca de dez nós. O LLM fica restrito a dois trabalhos-folha. Tudo entre eles é determinístico.

input → extract (LLM leaf) → search → policy gate → verify gate → hold → ticket → hotel-book → commit

Extract, o único trabalho estruturado do LLM

O modelo interpreta a intenção em linguagem natural em um Pydantic-typed TripRequest (origin, destination, date, passengers, cabin, hotel). Esse objeto tipado é o único artefato estruturado que o LLM produz. É intercambiável de provedor via Pydantic AI e roda totalmente offline com um stub determinístico quando nenhuma chave está presente.

Política compilada em código

A política corporativa vive como predicados Python puros: somente econômica, teto de tarifa de $600 por segmento, companhias preferenciais (United, American, Delta), teto de $350 por noite de hotel. Opções fora da política são fisicamente não apresentáveis porque são filtradas antes de poderem ser exibidas, não sinalizadas depois. Famílias de tarifa desconhecidas falham de forma segura, tratadas como acima da política em vez de silenciosamente como econômica. Sem voo dentro da política, o agente escala para uma fila humana em vez de blefar.

O portão de verificação

Cada hotel é confirmado contra o CRS por property_id. Uma propriedade que o modelo inventa simplesmente não está no CRS, então é recusada e nunca apresentada, e a reserva chega ao estado terminal abstained. O portão recusa inventário não confirmado; não pede ao modelo que avalie a própria saída.

A Saga, a parte que a maioria das demos ignora

Cada etapa de avanço registra sua ação reversa no momento da execução. A emissão, por exemplo, registra "void ticket, 24-hour window." Diante de uma falha no passo N, as compensações de N-1 até 1 rodam em ordem inversa, e só então o agente informa. É isso que separa uma demo de um produto, porque é o que impede que uma falha parcial vire um cliente encalhado.

O medidor de custo do GDS e a trilha de auditoria

Um contador ao vivo rastreia o gasto de busca no GDS a $3.25 por segmento, porque as buscas são cobradas, não só as reservas. Um cache L2B e a busca adiada mantêm isso estável onde um agente especulativo rebusca e queima margem. Cada reserva grava um log de eventos JSON append-only, exportável como audit-<pnr>.json, com o modelo e a versão, o pedido de viagem tipado, cada veredito de nó, cada compensação da Saga, a flag de divulgação do EU AI Act Article 50 e o estado terminal.

O que a demo mostra

Quatro botões, lado a lado com uma linha de base real de LLM-no-controle no mesmo cenário. Cada captura de tela abaixo foi tirada do aplicativo em execução.

Uma reserva normal, nó a nó

A demo executando uma reserva normal de ORD para SFO. À direita, o rastreio do pipeline determinístico executa cada nó por vez, da extração de intenção ao portão de política, verificação no CRS, holds, emissão do bilhete e commit do hotel, terminando em um PNR no estado confirmed com o medidor de gasto de busca no GDS em $3.25. À esquerda, o painel rotulado No Tools and No Verification simplesmente responde que está tudo reservado.

"ORD para SFO na próxima terça, uma noite no centro, política da empresa." A máquina de estados executa cada nó, confirma o Hyatt Regency SF contra o CRS por property_id, e o medidor de busca permanece em $3.25 em uma busca em cache. Estado terminal: confirmed, com um PNR.

O portão de verificação recusa um hotel que não existe

A etapa de verificação no CRS marcada como failed. O painel de detalhes informa que Tabacon Springs Eco-Lodge não está no CRS e foi recusado, não apresentado. O card da propriedade está carimbado REFUSED, com a nota de que o portão de verificação o recusou e ele não foi apresentado ao viajante.

O pedido nomeou uma propriedade fabricada, "Tabacon Springs Eco-Lodge," um nome que mistura dois resorts reais e, de propósito, não tem property_id. O portão não encontra correspondência no CRS e recusa apresentá-la. O agente se abstém com honestidade, "Não pude confirmar essa propriedade," em vez de inventar uma.

O rollback da Saga, versus o LLM no controle

O rastreio do pipeline depois que uma tarifa de hotel expirou após a emissão do bilhete. Três etapas de compensação da Saga rodam em ordem inversa, e um banner informa que o hold expirou antes do commit e o rollback da Saga está compensando em ordem inversa. O card de resultado lê ROLLED BACK, TRAVELER SAFE, com uma nota de que o bilhete do voo foi anulado sem custo e hotéis alternativos são oferecidos.

A tarifa do hotel expira depois que o voo já está emitido. Do nosso lado a Saga dispara: anula o bilhete dentro da janela de 24 horas, libera os holds e responde com honestidade que o bilhete foi anulado sem custo, com alternativas anexadas. Estado terminal: rolled back, traveler safe. A linha de base no mesmo cenário deixa o bilhete emitido, não oferece compensação e emite um falso "Está tudo certo," que é exatamente o precedente da Air Canada esperando acontecer.

Uma trilha de auditoria exportável

A parte inferior do console mostrando o link Export Audit Trail (JSON), ao lado do resultado rolled-back explicando que a tarifa em hold expirou antes do commit, o bilhete foi anulado sem custo e dois hotéis alternativos são oferecidos, com o gasto de busca no GDS em $3.25.

Um clique exporta audit-<pnr>.json: o modelo e a versão, o pedido de viagem tipado, cada nó e seu veredito determinístico, cada compensação da Saga, a flag de divulgação do EU AI Act Article 50 (obrigações de transparência valem a partir de 2 de agosto de 2026) e o estado terminal.

O benchmark de 200 cenários

O placar do benchmark sobre 200 reservas sintéticas com semente fixa e as mesmas falhas injetadas. Quatro tiles comparam o agente determinístico a uma linha de base de LLM simples: 100 por cento versus 65 por cento de estado terminal consistente, 0 versus 40 viajantes encalhados, 0 versus 30 reservas fabricadas, e $3.25 versus $7.57 de gasto médio no GDS. Uma tabela de resultados lista os desfechos por cenário, incluindo confirmed, rolled back, abstained, escalated, integrity breach e stranded.

As mesmas 200 reservas sintéticas, uma semente fixa (42) e as mesmas falhas de infraestrutura injetadas, executadas nas duas arquiteturas. A mistura de cenários é 50 por cento happy, 20 por cento hotel-fail-after-ticket, 15 por cento hallucinated-entity e 15 por cento search-storm. Nossas garantias valem por construção; as falhas da linha de base emergem dos mesmos dados.

Fluxo de controle determinístico versus um LLM no loop

A linha de base é um agente real ReAct-style LLM-no-controle rodando nos mesmos cenários, uma âncora honesta em vez de um homem de palha. Os números abaixo são sobre o lote sintético de 200 cenários com semente fixa (benchmark.py, seed 42, n=200).

Métrica	Agente determinístico (o nosso)	Linha de base (LLM-no-controle)
Estado terminal consistente	100.0%	65.0%
Viajantes encalhados	0	40
Reservas fabricadas apresentadas	0	30
Gasto médio de busca no GDS por reserva	$3.25	$7.57

Os 100 por cento, 0 e 0 valem por construção sobre este lote sintético de semente fixa, não como uma garantia de produção em mundo aberto. A afirmação é estreita e durável: uma reserva parcial nunca é mostrada como confirmed, e um viajante nunca fica encalhado. A diferença $3.25 versus $7.57 é um número de margem que vale em qualquer qualidade de modelo.

O que esta demo não faz

Ela não se conecta a um GDS, CRS ou NDC ao vivo. O GDS e o CRS, a emissão de bilhetes IATA e ARC, e o pagamento PCI são stubbed e simulados. O adaptador de fixtures é a integração V1; não há conta ao vivo Amadeus, Sabre ou Duffel.
Ela não emite bilhetes reais nem move dinheiro real, e a Veriprajna não é credenciada pela IATA nem pelo ARC. Bilhetes e pagamento são stubs.
Os cenários, PNRs, hotéis e viajantes são sintéticos. "Tabacon Springs Eco-Lodge" é uma propriedade deliberadamente fabricada, uma demonstração do modo de falha. Hotéis com nomes reais como Hyatt Regency SF são inventário de fixture, não reservas reais.
Ela não afirma reservar mais, mais barato ou de forma mais inteligente do que um GDS ou OTA, e não afirma alucinação zero do modelo. O LLM ainda redige a intenção; a garantia é que o portão recusa inventário não confirmado e a Saga limpa falhas parciais.
O motor é uma máquina de estados Python feita à mão, não LangGraph. O LangGraph é citado como um swap-in de produção adiado. As chamadas-folha do LLM usam Pydantic AI.

Perguntas que os compradores fazem

Posso confiar em um agente de IA para reservar viagens sem encalhar meus viajantes?

A garantia não vem de confiar no modelo. Nesta demo o fluxo de controle é Python determinístico, e cada etapa de avanço registra uma ação compensatória no instante em que roda. Quando uma etapa falha depois que um bilhete é emitido, o motor executa essas compensações em reverso (uma Saga), anula o bilhete dentro da janela de 24 horas e informa com honestidade. Um viajante nunca fica com um voo e sem quarto porque nada depende do modelo decidir limpar.

Isso se conecta a Amadeus, Sabre ou Duffel?

Não. O GDS, o CRS, a emissão de bilhetes e o pagamento são todos stubbed e simulados nesta demo. O adaptador de fixtures é a integração V1, e não há conta ao vivo Amadeus, Sabre ou Duffel por trás. A demo prova a arquitetura de fluxo de controle e a lógica de compensação, não um pipeline de reservas de produção.

O que acontece se o hotel falhar depois que o voo já está emitido?

Esse é exatamente o caso para o qual a Saga foi feita. A emissão registra sua própria ação reversa (anular o bilhete dentro da janela de 24 horas) no instante em que roda. Se a tarifa do hotel expirar antes do commit, o motor dispara as compensações em ordem inversa, anula o bilhete sem custo, libera os holds e entrega ao viajante alternativas honestas. O estado terminal é rolled back, não confirmed e não stranded.

O que impede o agente de inventar um hotel que não existe?

Um portão de verificação confirma cada propriedade contra o CRS pelo seu property_id antes de poder ser exibida. Quando o pedido nomeou uma propriedade fabricada na nossa demo, o portão não encontrou correspondência no CRS e recusou apresentá-la, e o agente se absteve com honestidade em vez de reservá-la. O portão não sinaliza um hotel inventado depois do fato; ele o torna fisicamente não apresentável.

Como isso é diferente de colocar o GPT-4 em um loop de agente com ferramentas?

Um agente ReAct-style coloca o LLM no comando da transação, então ele decide quando buscar, reservar e emitir, e não tem portão nem lógica de compensação. No mesmo lote sintético de 200 cenários com semente fixa, essa linha de base apresentou inventário fabricado e deixou bilhetes emitidos sem rollback, emitindo um falso "Está tudo certo." Aqui o LLM é um nó-folha tipado que só interpreta a intenção e redige a resposta; o código determinístico é dono do fluxo e cada etapa carrega o próprio undo.

Quem é responsável se o agente disser algo errado a um viajante?

O deployer é dono de cada afirmação que o seu agente faz. Em Moffatt v. Air Canada (BC Civil Resolution Tribunal, 14 de fevereiro de 2024) a companhia aérea foi condenada a pagar $812.02 depois que seu chatbot inventou uma política de tarifa por luto, e a defesa de que foi a IA foi rejeitada. A demo exporta uma trilha de auditoria JSON por reserva com o modelo e a versão, cada veredito de nó, cada compensação da Saga e uma flag de divulgação do EU AI Act Article 50, para que o que o agente fez seja inspecionável depois do fato.

Pesquisa técnica

A pesquisa por trás desta demo — a arquitetura, o design de verificação e o blueprint empresarial.

Solução completa

Explore a solução Reserva de viagens com IA agêntica →

Avaliando uma camada de reserva agêntica na qual você não pode apostar a empresa?

As falhas que encalham viajantes e inventam hotéis são eventos de infraestrutura, não problemas de QI do modelo.

Se a sua equipe está pesando onde o LLM deve ficar em um agente de reservas de alto risco, e como impedir que uma falha parcial vire uma responsabilidade no estilo Air Canada, gostaríamos de fato de trocar impressões. O problema é de toda a indústria e as respostas também serão.

Revisão de arquitetura de agentes

✓ Mapear onde o LLM fica no seu fluxo de controle hoje
✓ Identificar as etapas que precisam de uma ação compensatória
✓ Testar sob pressão os modos de falha: expiração de tarifa, holds pós-bilhete, tempestades de buscas
✓ Definir os estados terminais em que um operador pode confiar

Construção de agente determinístico

✓ Uma máquina de estados que é dona da busca, da política e da emissão
✓ Um portão de verificação e um motor de compensação Saga
✓ Política compilada em código, com defaults fail-safe
✓ Uma trilha de auditoria exportável com uma flag de divulgação do Article 50

Conecte-se via WhatsApp Envie um e-mail à nossa equipe