A virada que vi no I/O 2026: o agente não clica, ele chama uma função
No Google I/O 2026, o AI Mode virou padrão global e o AI Overviews ultrapassou 2,5 bilhões de usuários mensais. Na vertical de compras, os resumos de IA aparecem em 14% das buscas de shopping — crescimento de 5,6 vezes em quatro meses. O que mudou não é só a interface: é o sujeito da compra. O cliente pode ser um agente que chama funções, não lê páginas.
Reproduzi essa jornada com a equipe da Brasil GEO: descrevi um problema em linguagem natural no AI Mode, o assistente decompôs a frase em sub-consultas, comparou opções, leu avaliações e ofereceu o checkout ali mesmo. Quando abri o analytics, não havia sessão registrada. A decisão aconteceu, o dinheiro mudou de mãos, e o modelo de atribuição não viu nada.
A tese contraintuitiva deste guia: o trabalho de GEO que você fez até aqui — ser citado em texto — é necessário, mas não suficiente. Quando o cliente é um agente, ele quer chamar uma função que devolve preço, estoque e prazo em formato de máquina. Este artigo não repete o "porquê" do B2A, já coberto em Business-to-Agent: quando a IA compra no lugar do cliente. Aqui é o "como": os protocolos, a tabela de decisão e o piloto mínimo.
Por que o cliente virou agente (e por que isso não é hype de 2030)
O Business-to-Agent (B2A) é o próximo grande modelo de distribuição, segundo a Kantar: o principal cliente da web deixa de ser humano e passa a ser um agente autônomo que exige dados estruturados, APIs de estoque e preço em tempo real, e regras de incentivo verificáveis por máquina. O horizonte é de 18 a 24 meses — não é amanhã, mas também não é 2030.
O número que faz o B2A virar prioridade de roadmap, e não experimento de laboratório, é o da Gartner: até 2028, 90% das compras B2B serão intermediadas por agentes de IA, num mercado estimado em cerca de US$ 15 trilhões. O Google reforçou essa direção em janeiro de 2026 ao lançar o Universal Commerce Protocol e o Business Agent, que permitem ao consumidor conversar com um agente de marca diretamente na Busca e concluir a compra por checkout agêntico.
O sinal mais duro para quem ainda acredita que "ser primeiro no Google basta": a sobreposição entre o top orgânico e as fontes efetivamente citadas nos resumos de IA caiu para algo entre 17% e 54% em 2026. Metade da visibilidade pode estar escapando para uma camada que o SEO clássico não controla. Para o contexto estratégico completo antes de mergulhar nos protocolos, leia Seu próximo cliente não é humano: agentic commerce e a nova economia algorítmica.
A tabela dos protocolos B2A de 2026: o que é, quem mantém, para que serve, como começar
Em 2026, o ecossistema agêntico não é um padrão único: é uma pilha de cinco protocolos que cobrem camadas distintas — descoberta de conteúdo, exposição de ferramentas, comunicação entre agentes e pagamento. MCP e NLWeb são a porta de entrada de menor atrito; A2A, AP2 e UCP entram em fases posteriores. A tabela abaixo consolida fatos verificados na pesquisa de junho de 2026 e resolve a confusão de siglas que trava a maioria dos CTOs.
| Protocolo | O que é | Quem mantém | Para que serve | Como começar |
|---|---|---|---|---|
| MCP (Model Context Protocol) | Padrão aberto para um modelo/agente descobrir e chamar ferramentas e fontes de dados externas. | Anthropic (aberto; adotado por Google, OpenAI e outros). | Expor seus dados e ações (preço, estoque, criar pedido) como ferramentas que qualquer agente compatível consome. | Suba um servidor MCP descrevendo 2-3 ferramentas read-only do seu domínio. |
| NLWeb | Camada que transforma um site em uma interface conversacional consultável, expondo o conteúdo como endpoint para linguagem natural; cada instância NLWeb também é um servidor MCP. | Microsoft (proposto por R.V. Guha, criador de RSS/Schema.org, no Build 2025). | Deixar seu conteúdo existente "perguntável" por agentes sem reescrever tudo, reaproveitando Schema.org. | Instale NLWeb sobre seu feed/Schema.org e exponha o endpoint /ask. |
| A2A (Agent2Agent) | Protocolo para agentes de fornecedores diferentes se comunicarem e delegarem tarefas entre si. | Google (doado à Linux Foundation; ecossistema multi-vendor). | Permitir que o agente do cliente negocie com o seu agente de marca. | Relevante quando você já opera um agente próprio; comece publicando uma "agent card". |
| AP2 (Agent Payments Protocol) | Padrão para autorização e execução de pagamentos iniciados por agentes, com mandatos verificáveis. | Google + parceiros de pagamento; compatível com UCP, A2A e MCP. | Garantir que uma compra feita por agente seja autorizada, auditável e não fraudulenta. | Fase posterior; depende do seu PSP suportar mandatos agênticos. |
| UCP (Universal Commerce Protocol) | Protocolo de comércio ponta a ponta (descoberta, compra, pós-venda); base do Universal Cart. | Google, em co-desenvolvimento com Shopify. | Padronizar o ciclo de compra agêntico dentro da Busca/AI Mode. | Se você está em Shopify, acompanhe a habilitação nativa; senão, mapeie seu catálogo ao schema do UCP. |
| WebMCP (Chrome 149) | Padrão aberto proposto para um site expor ferramentas estruturadas (funções JS, formulários HTML) a agentes que rodam no navegador. | Equipe do Chrome (trial experimental no Chrome 149, suporte planejado no Gemini in Chrome). | Substituir o scraping heurístico da sua UI por chamadas declaráveis e confiáveis (ex.: addToCart). | Marque funções-chave da página com tool schemas no trial do Chrome 149. |
A leitura que faço dessa tabela: MCP e NLWeb são a porta de entrada de menor atrito porque reaproveitam o que você já tem (dados e Schema.org). A2A, AP2 e UCP são camadas de transação e interoperabilidade que entram depois, e WebMCP é a aposta do navegador-runtime, ainda em trial. Comece pela porta de entrada.
O que muda na sua infraestrutura (e o que continua igual)
Tornar um site agent-ready exige três mudanças de infraestrutura que passam de "nice to have" a pré-requisito: dados de estoque e preço em tempo real via API (p95 abaixo de 200 ms), dados estruturados com Schema.org para desambiguação de entidade, e incentivos comerciais legíveis por máquina. O fundamento técnico de SEO — indexabilidade, performance, conteúdo original — continua igual e é pré-requisito para qualquer camada agêntica.
- Dados em tempo real e verificáveis. Estoque, preço e prazo de logística precisam de uma fonte de verdade exposta por API, com baixa latência (mire em p95 abaixo de 200 ms). O agente vai cruzar o que você diz no HTML com o que sua API responde; divergência derruba confiança.
- Dados estruturados como sinal de entidade, não como bala de prata. Schema.org e JSON-LD continuam importando para desambiguar sua marca no knowledge graph (a fase upstream da recuperação), mas seja honesto: o próprio Google reiterou no I/O 2026 que não há schema especial obrigatório para AI Mode, e estudos independentes mostram efeito estatisticamente fraco do JSON-LD sobre a citação em si. Faça por higiene semântica, não por promessa de citação garantida. Aprofundo em GEO para e-commerce.
- Incentivos verificáveis por máquina. A Kantar é explícita: o agente decide por regras, não por emoção de marca. Condições comerciais (frete, garantia, política de devolução) precisam estar legíveis e comparáveis por máquina, ou seu produto some do shortlist do agente antes de qualquer humano ver.
Antes de liberar qualquer bot de agente, decida o que liberar e o que bloquear — o tema está detalhado na matriz de bots de IA. Bloquear por descuido os crawlers de retrieval (e não apenas os de treino) não resulta em neutralidade: faz a marca desaparecer da resposta.
Passo a passo: um piloto B2A mínimo com um endpoint documentado
Não comece pelo pagamento agêntico nem por reescrever o catálogo inteiro. O piloto que recomendo entrega valor de aprendizado em uma sprint e expõe exatamente uma capacidade real do seu negócio a um agente. Eis a sequência que rodo com os times:
- Escolha uma capacidade read-only de alto valor. "Consultar disponibilidade e preço de um SKU" ou "verificar prazo de entrega por CEP". Read-only primeiro: você aprende sem risco transacional.
- Garanta a fonte de verdade por API. Confirme que existe um endpoint interno que responde aquela pergunta com dado vivo e latência baixa. Se o dado mora em planilha ou cache lento, conserte isso antes — é a parte que mais trava pilotos.
- Exponha como ferramenta MCP. Suba um servidor MCP declarando essa única ferramenta, com nome, descrição e schema de entrada/saída claros (ex.:
checarDisponibilidade(sku, cep)retornando preço, estoque e prazo). Descrição boa é o que faz o agente escolher chamar a sua ferramenta. - Espelhe em NLWeb sobre seu Schema.org. Se você já tem produtos marcados com Schema.org, instale NLWeb e exponha um endpoint
/ask— você ganha a versão conversacional de graça, e ela também fala MCP. - Documente em OpenAPI e em uma agent card. Publique a especificação OpenAPI do endpoint e uma descrição legível por máquina de qual agente pode usá-la e sob quais condições. Documentação é descoberta no mundo dos agentes.
- Instrumente a observabilidade. Logue cada chamada de agente: qual ferramenta, quais parâmetros, latência, sucesso/erro. Sem isso você não terá a métrica que substitui a "sessão" que sumiu do analytics.
- Teste com um agente real. Use um cliente MCP (Claude Desktop, um agente em Chrome 149 com WebMCP, ou um script próprio) e valide que o agente descobre, chama e interpreta o retorno corretamente.
- Só então evolua para transação. Com o read-only estável e observado, aí sim avalie A2A para negociação e AP2/UCP para o pagamento — com o seu PSP no circuito.
O critério de sucesso do piloto não é receita. É uma resposta a uma pergunta: um agente consegue descobrir, chamar e confiar em pelo menos uma capacidade do nosso negócio sem intervenção humana? Se sim, você atravessou a linha do B2A. Para encaixar isso na transição maior de SEO para a era dos agentes, leia o guia completo de SEO para IAs e transição B2A.
As armadilhas que já vi derrubarem piloto B2A
Os cinco erros que mais derrubam pilotos B2A, em ordem de frequência, são: começar pelo pagamento agêntico antes de provar o read-only; anunciar "agent-ready" sem endpoint funcional; divergência de preço entre HTML e API; bloquear crawlers de retrieval junto com os de treino; e tratar o B2A como substituto do fundamento de SEO — quando é uma camada por cima dele.
- Começar pelo pagamento. AP2 e checkout agêntico dão manchete, mas é a camada de maior risco e dependência externa. Quem começa por ali trava em compliance e PSP antes de provar valor.
- Tratar protocolo como marketing. Anunciar "somos agent-ready" sem endpoint funcional é o equivalente 2026 do "mobile-first" só no PowerPoint. O agente testa de verdade; ou a ferramenta responde, ou não.
- Divergência entre HTML e API. Preço na página diferente do preço na API é o jeito mais rápido de perder a confiança do agente — e ela não volta fácil.
- Bloquear o bot errado. Confundir crawler de treino com crawler de retrieval e bloquear ambos por precaução. Você queria proteger direito autoral e acabou sumindo da resposta.
- Achar que B2A substitui o fundamento. Não substitui. Site não-indexável e marca com entidade inconsistente continuam invisíveis, com ou sem MCP.
A regra que repito para mim mesmo: o B2A é uma camada nova por cima de uma fundação que precisa estar de pé. Se a fundação está rachada, o endpoint MCP só vai expor a rachadura mais rápido.
O que eu faço: a aposta calibrada para os próximos 18 meses
Minha decisão, como CEO da Brasil GEO, ex-CMO da Semantix (Nasdaq) e cofundador da AI Brasil, é tratar o B2A como aposta calibrada — não como pivô nem como moda. Aloco uma sprint por trimestre para manter um endpoint MCP/NLWeb vivo, documentado e observado. O grosso do esforço continua no fundamento de GEO e SEO que já gera resultado hoje.
A calibração é honesta com o horizonte: a Kantar fala em 18 a 24 meses, e o Google ainda não publicou MAU auditável do AI Mode. Não existe dado público que sustente promessa de ROI de B2A em 90 dias. O que existe é o custo de aprendizado: o time com um piloto real rodando quando o tráfego de agentes virar volume relevante estará a meses de vantagem de quem começar do zero naquele momento.
É a mesma lógica com que tratei mobile e a busca generativa: entrar cedo o suficiente para aprender, com aposta pequena o bastante para não doer se o cronograma escorregar. Fronteira se respeita com piloto, não com all-in.
Próximo passo: a pergunta de uma frase para a sua próxima reunião de produto
Se você é CTO, head de produto ou tech lead, leve esta pergunta para a próxima reunião: qual é a única capacidade do nosso negócio que um agente precisaria chamar — e ela já existe como API com dado vivo? Se a resposta existe, você tem o piloto. Se não existe, você descobriu a real dívida técnica antes que o agente a descubra por você.
Esta semana mesmo, o passo concreto é menor do que parece: identifique esse endpoint candidato, valide a latência e a fonte de verdade, e agende uma sprint para envelopá-lo em MCP. Uma ferramenta, read-only, documentada. É o suficiente para cruzar a linha.
Para fortalecer a base enquanto o B2A amadurece, recomendo alinhar o vocabulário do time com o glossário das 4 camadas de visibilidade e garantir o básico de extração com o FAQ de AEO para iniciantes. Fundamento sólido embaixo, piloto de fronteira em cima: é assim que eu jogaria.