Concluímos um Booking de Voo com Agente de IA de Forma Autônoma

Um agente de IA recebeu uma instrução em linguagem natural, pesquisou voos, selecionou uma oferta, passou por verificações de autorização e criou uma reserva confirmada — de forma autônoma, sem intervenção humana após a configuração inicial.

Hoje isso passou de especificação de arquitetura para realidade de produção.

O que realmente aconteceu

Às 15:33 CET, no UCPPlayground, executamos o seguinte comando em nossa pilha ao vivo:

"Use search_flights para ZAG a AMS amanhã. Em seguida, chame imediatamente complete_checkout na primeira oferta direta. Não explique primeiro."

Duas chamadas de ferramenta. Oito segundos.

O agente pesquisou. O agente reservou. Uma referência de reserva confirmada retornou. Abrimos o painel do provedor de viagens e o pedido estava lá — confirmado, com um PNR, um e-ticket, detalhes do passageiro, tudo.

Nenhum humano tocou no fluxo de reserva após a configuração inicial do viajante.

Por que isso é mais difícil do que parece

Qualquer um pode envolver uma API de pesquisa de viagens em uma ferramenta MCP e chamá-la de "reservas de viagens com IA." Essa parte é fácil.

A parte difícil é tudo o que acontece entre pesquisa e reserva confirmada:

As ofertas expiram. As tarifas de voo são um inventário perecível. Uma oferta retornada da pesquisa pode desaparecer em 15–30 minutos. Nenhum LLM verifica isso sem solicitação — ele tentará reservar uma oferta expirada e receberá uma rejeição da qual não sabe como se recuperar.

Os preços mudam silenciosamente. Uma tarifa pode ser reavaliada entre o momento em que o agente a vê e o momento em que tenta reservar. Sem um portão de revalidação, o agente reserva ao novo preço sem avisar ninguém.

As reservas podem ser parcialmente confirmadas. Um provedor de viagens pode retornar uma resposta assíncrona — reserva aceita, resultado pendente. Um agente que não entende esse estado irá tentar novamente, e tentar novamente uma chamada de reserva corre o risco de uma cobrança dupla.

Identidade e autorização importam. Para quem é essa reserva? O que eles podem gastar? Qual classe de cabine? Eles são apenas diretos? Sem uma camada de mandato, um agente não tem restrições. Ele gastará qualquer inventário disponível.

Os requisitos de documentação bloqueiam certas rotas. Algumas rotas exigem que os detalhes do passaporte sejam validados antes que um pedido seja criado. Um agente que não verifica isso desperdiça uma tentativa de reserva e confunde o viajante.

Esses não são casos extremos. Cada um deles acontecerá em produção. Nenhum deles é resolvido pela API de viagens ou pelo LLM — eles precisam ser resolvidos pela camada intermediária.

Foi isso que construímos.

A pilha

Construímos UCP Travel — uma camada de transação de viagens que fica entre agentes de IA e inventário de viagens.

Ela implementa:

• UCP (Protocolo de Comércio Universal) — o padrão aberto para comércio agente, incluindo todo o ciclo de vida do checkout
• MCP (Protocolo de Contexto de Modelo) — para que qualquer agente compatível com MCP possa descobrir e chamar nossas ferramentas
• AP2 (Protocolo de Pagamentos de Agente) — mandatos de viajantes assinados criptograficamente que impõem limites de gastos, tetos de classe de cabine e restrições de reserva antes de qualquer transação

O viajante configura uma vez: conecta seu assistente de IA via OAuth, assina um mandato definindo suas restrições de reserva, armazena suas preferências de viagem. Depois disso, cada reserva é autônoma dentro dessas restrições.

Nossas declarações de capacidade são públicas em ucp.travel/.well-known/ucp e verificadas por UCPChecker — atualmente a única implementação verificada de travel.ucp.mandate no mundo.

A integração do UCPPlayground

A reserva de hoje aconteceu através do UCPPlayground — um ambiente de teste ao vivo para o ecossistema UCP construído por Ben Fisher. Ele conecta modelos de IA reais a pontos finais reais do UCP e executa sessões de agentes de ponta a ponta.

Gemini 2.5 Flash se conectou ao nosso ponto final MCP, descobriu três ferramentas (search_flights, complete_checkout, get_booking), e completou a reserva em 3 turnos:

Turno 1: search_flights(origem: ZAG, destino: AMS, data_partida: 2026-06-02, max_conexões: 0)
Turno 2: complete_checkout(id_oferta: off_..., id_checkout: chk_live_1)
Turno 3: [confirmado — PNR retornado]

Total de 33.816 tokens. Ainda não otimizado, mas funcionando.

O que "configuração do viajante uma vez" realmente significa

A reserva autônoma só funciona porque resolvemos primeiro o problema da identidade.

Durante a integração, um viajante:

1. Cria um perfil com documentos e preferências de viagem
2. Assina um Mandato de Intenção AP2 — suas restrições de reserva autorizadas, assinadas criptograficamente
3. Vincula seu assistente de IA via fluxo de Código de Autorização OAuth 2.0

A partir desse ponto, cada chamada de ferramenta MCP que o agente faz carrega um token de portador que se resolve no servidor para a identidade do viajante, mandato e perfil de pagamento. O agente nunca vê credenciais brutas, números de cartão ou dados de passaporte. Ele apenas chama ferramentas e obtém resultados.

Esta é a arquitetura que torna a reserva autônoma confiável — não apenas tecnicamente possível.

O que está ao vivo agora

A plataforma de operador multi-inquilino está em funcionamento. Operadores se integram, configuram mandatos de viajantes e conectam assistentes de IA hoje. A reserva de voos está ao vivo.

Próximos passos:

• Reserva de estadia (hotel) junto com voos
• Serviço pós-reserva — alterações, cancelamentos, adicionais
• Interface de trilha de auditoria completa para operadores e equipes de conformidade

Se você está construindo um assistente de viagens com IA, uma plataforma de gerenciamento de viagens, ou qualquer coisa que precise transformar a intenção de viagem em reservas confirmadas — gostaríamos de conversar.

ucp.travel · contact@zologic.nl

Construído por Zologic — zologic.nl

Especificação UCP: ucp.dev · Especificação MCP: modelcontextprotocol.io · AP2: ap2-protocol.org