Por que agentes de IA não conseguem usar seu widget de reservas

Passamos julho medindo quão bem assistentes de IA podem reservar mesas em restaurantes de Amsterdã. 200 locais, um agente de navegador, uma tarefa: encontrar o restaurante, entendê-lo, verificar a disponibilidade para uma data real e tamanho do grupo, e chegar à etapa final de reserva. Nunca submetemos uma reserva.

No estudo, publicamos os números. Neste post, quero falar sobre o modo de falha que vimos mais do que qualquer outro, porque é um problema solucionável e a maioria das pessoas que constroem assistentes irá enfrentá-lo eventualmente.

O modo de falha: o widget de reserva.

A maioria dos restaurantes que pagam por um produto de reserva o incorporam como um iframe. Uma pessoa visita a página, vê um botão rotulado Reservar, clica nele, um modal se abre com um calendário e um seletor de horário, ela insere o tamanho do grupo, nome e telefone, e recebe uma confirmação. Esse fluxo funciona porque uma pessoa pode vê-lo, reconhecê-lo e interpretá-lo.

Um agente dirigindo um navegador real vê algo diferente.

O que o agente recebe

A página pai contém o botão e muitas vezes não muito mais sobre a reserva. O manipulador de onclick do botão abre um iframe de uma origem diferente. Dentro desse iframe:

• o DOM não é acessível a partir da página pai sob a política de mesma origem
• os campos são frequentemente renderizados por um aplicativo do lado do cliente que monta após uma viagem de rede
• a disponibilidade vive em uma API interna que o widget chama uma vez montado, através de uma URL para a qual o agente não tem token de acesso
• a confirmação é mostrada como texto dentro do iframe, ou como um redirecionamento que a página pai nunca vê

Um agente que lê a página pai não tem ideia de que um fluxo de reserva sequer existe além do botão. Um agente que clica no botão obtém um novo contexto de navegação que não pode introspectar no nível da página pai. Um agente com acesso total ao iframe pode às vezes operar o widget simulando cliques e digitação, se os elementos forem estáveis, se o foco for tratado corretamente, se um captcha não for acionado, se o widget não detectar automação e rejeitar. Isso é um monte de "se" para uma reserva.

O que a maioria dos sites publica em vez disso

Entre os 163 sites funcionais em nossa amostra de Amsterdã, verificamos descrições legíveis por máquina do restaurante e sua reserva. Nove as tinham. Todas as nove eram esquema de Restaurante ou LocalBusiness, geradas por um plugin de SEO. Elas descrevem o local: seu nome, endereço, horários de funcionamento, culinária, faixa de preço, contagem de avaliações.

Elas não descrevem uma forma de reservar.

Schema.org tem tipos Reservation e ReserveAction. Eles existem. Não são amplamente utilizados. E onde aparecem, normalmente descrevem uma reserva concluída, não uma interface chamável para criar uma.

Uma ação é uma URL que um agente pode POSTAR, com uma estrutura que pode construir. Uma descrição é um parágrafo que um agente pode citar de volta para você. Todo site que verificamos publicou descrições. Nenhum publicou uma ação.

O momento ChatGPT

Um momento da construção do suporte resume isso. Colocamos uma pequena API de reserva em nossa instância de demonstração atrás de uma página HTML simples descrevendo-a em prosa: o endpoint, os campos necessários, a forma da resposta. Não um widget, apenas uma página.

Perguntamos ao ChatGPT para fazer uma reserva contra isso. O ChatGPT leu a página, entendeu a API, listou os campos necessários e informou educadamente que sua ferramenta da web não pode emitir uma solicitação POST. Ele não podia agir. A página era para humanos, a API era para agentes, e o assistente estava entre eles, incapaz de conectar os dois.

Assistentes agem através de ferramentas, não páginas. Eles leem páginas, não pressionam botões.

Como seria realmente pronto para agentes

Na ordem do que realmente move a agulha:

1. Um endpoint de reserva chamável. HTTP, JSON, versionado. Consulta de disponibilidade, criação de slot, cancelamento. Autenticação via uma chave de API que o local pode rotacionar. Isso é para onde a ferramenta de um agente seria apontada.
2. Declare isso. Uma URL .well-known, ou um bloco ReserveAction do schema.org, ou um servidor Model Context Protocol, ou os três. A descoberta é barata uma vez que a ação existe.
3. Se você mantiver o widget visual, mantenha-o. Ambos os caminhos chegam à mesma mesa.

Nada disso requer redesenhar o site. O widget permanece. O agente recebe uma porta que não está atrás de vidro.

Uma nota sobre o Model Context Protocol

MCP é onde eu terminei após este projeto. É um protocolo para expor ferramentas que um assistente pode chamar, e é a coisa mais próxima hoje de uma resposta amplamente suportada à pergunta "como meu assistente faz essa ação específica". OpenAI, Anthropic, Google e Perplexity todos consomem isso de alguma forma. Qualquer assistente com um cliente MCP pode listar suas ferramentas disponíveis, entender suas entradas e chamá-las, sem nunca ver uma página.

Escreverei sobre o servidor MCP que construímos para reservas no próximo post. Este foi sobre o problema, porque o problema é a parte que a maioria dos construtores descobre da maneira difícil, um iframe de cada vez.

Se você constrói assistentes que precisam completar ações do mundo real, eu realmente gostaria de saber onde eles quebram para você.

O estudo de campo completo, método e dados agregados: https://g-lab.studio/research/amsterdam-restaurants-2026