O UCP do Google põe quatro cabeçalhos em cada pagamento. Três existem para a discussão que vem depois

Em 11 de janeiro de 2026, o Google publicou o Universal Commerce Protocol — um padrão de código aberto que permite a agentes de IA comprar, desenvolvido em conjunto com a Shopify e apoiado por mais de 20 parceiros, entre eles Etsy, Wayfair, Target, Walmart, Adyen, American Express, Mastercard, Stripe, Visa e Zalando.

A cobertura que veio depois falava de compras. Agentes que garimpam por você, agentes que pagam por você, o fim do carrinho e por aí vai.

Aí você lê a especificação e descobre que comprar é a coisa menos interessante que há ali dentro. O que o UCP padroniza com um cuidado incomum não é a compra. É a prova de que a compra aconteceu do jeito que as duas partes dizem.

Resumo:

• Toda requisição UCP que altera estado leva quatro cabeçalhos, e três deles — request-signature, idempotency-key, request-id — não fazem nada pela transação em si. Existem para que depois alguém consiga provar o que foi pedido, que foi pedido uma única vez e onde encontrar isso de novo.
• A irretratabilidade é um recurso com nome próprio. Na extensão opcional de mandatos AP2 (dev.ucp.shopping.ap2_mandate), o lojista assina criptograficamente as condições do checkout enquanto a plataforma fornece mandatos criptográficos provando que o usuário as autorizou. O propósito declarado na especificação: "reduzir significativamente os riscos de adulteração e disputa".
• Número de apoiadores não é número de integrações. "Mais de 20 parceiros globais" é a formulação publicada pelo Google, e ela descreve apoio. Até o fechamento deste texto, não encontramos nenhuma fonte primária com uma contagem de lojistas em produção no UCP.

O conjunto de cabeçalhos vem do próprio tutorial que o Google publicou no dia do lançamento. Fontes no final.

O que é o UCP, no menor número de palavras que continuam verdadeiras

Antes do argumento, os fatos verificáveis. Vêm da especificação publicada em ucp.dev e do blog para desenvolvedores do Google, ambos consultados em 5 de setembro de 2026.

Duas linhas dessa tabela merecem uma pausa, porque a maioria dos artigos pula as duas.

A primeira é a dos transportes. O UCP não é uma coisa de MCP nem uma coisa de REST. Os mesmos dados declarados são oferecidos por REST, MCP, A2A e um binding embutido, e quem escolhe é o lojista. É uma recusa deliberada de apostar em qual encanamento de agentes vai vencer.

A segunda é o versionamento por data. 2026-04-08 não é uma versão semântica; é um dia. A razão declarada é a ordenação cronológica e a comparação sem ambiguidade — mas o efeito prático é outro: toda sessão negociada registra a data das regras sob as quais aconteceu. É uma decisão de arquivo disfarçada de decisão de versionamento, e ela dá o tom de todo o resto do documento.

O gargalo que ele veio matar

O enquadramento do Google é um problema N×N. Toda empresa que queira aparecer dentro de uma superfície conversacional precisa construir uma conexão sob medida para cada uma; cada superfície precisa fazer o onboarding de cada empresa separadamente; no fim, ninguém entrega nada.

O artigo de engenharia da Shopify, publicado no mesmo dia pelo distinguished engineer Ilya Grigorik, ataca o mesmo problema por baixo. Depois de mais de 20 anos, bilhões de transações e milhões de lojistas, a lição é que o comércio se recusa a normalizar: "opções e regras de pagamento diferem conforme as propriedades do carrinho, do comprador e do mercado; descontos têm regras de acúmulo e combinação que rivalizam com o código tributário; opções de fulfillment explodem em permutações descontroladas". E então vem a frase que vale guardar: "Essa complexidade não é um bug, é uma propriedade emergente da diversidade dos varejistas."

Essa única linha explica a arquitetura inteira. Se você aceita que os lojistas são irredutivelmente diferentes, não dá para padronizar o comportamento. Só dá para padronizar como um lojista declara seu comportamento, e como um agente descobre com o que acabou de concordar.

A estrutura que uma empresa publica em /.well-known/ucp. Fonte: especificação UCP 2026-04-08, Overview.

A descoberta acontece antes de a conversa começar

Este é o fluxo, como a especificação e o tutorial do Google o descrevem. Vale seguir ao pé da letra, porque a ordem é o argumento.

1. A empresa publica um perfil em /.well-known/ucp. Ali declara uma versão de protocolo, um ou mais serviços (dev.ucp.shopping), as capacidades dentro deles, os transportes e endpoints, os manipuladores de pagamento disponíveis e — isso vai importar adiante — suas signing_keys públicas.
2. O agente anuncia o próprio perfil em toda requisição, via um cabeçalho UCP-Agent em sintaxe de dicionário RFC 8941: UCP-Agent: profile="https://agent.example/profiles/shopping-agent.json". No transporte MCP, a mesma informação viaja num objeto meta.
3. A empresa calcula a interseção. Das próprias capacidades, mantém as que a plataforma também declara; para cada sobrevivente, escolhe a versão mais alta presente em ambos os arrays; se não houver versão comum, a capacidade some inteira.
4. Extensões órfãs são podadas. Uma extensão que declara extends: "dev.ucp.shopping.checkout" desaparece se checkout não sobreviveu. A poda se repete até nada mais cair, o que resolve cadeias transitivas.
5. Quem escolhe é a empresa. O UCP usa uma arquitetura em que o servidor seleciona: é o lojista, não o agente, que decide o que está ativo na sessão, e devolve o registro de capacidades ativas na resposta.

A nomeação não é convenção, é governança. Toda capacidade é {domínio-invertido}.{serviço}.{capacidade} — dev.ucp.shopping.checkout para a padrão, com.example.payments.installments para a própria de um lojista. Um varejista pode inventar uma capacidade que ninguém mais tem sem pedir licença e sem colidir com ninguém, porque o domínio invertido é a autoridade.

A falha também tem sua taxonomia, e a separação é instrutiva. A especificação divide falhas de descoberta (erros de transporte: invalid_profile_url retorna 400, profile_unreachable retorna 424, profile_malformed retorna 422) de falhas de negociação, que são resultados de negócio e voltam como um 200 normal com capabilities_incompatible no corpo. "Não consegui te alcançar" e "não temos nada em comum" são eventos diferentes, e o UCP se recusa a borrá-los num único 400.

Quatro cabeçalhos viajam em toda requisição que altera estado

Vamos olhar uma chamada real. Este é o próprio exemplo do Google do dia do lançamento: criar uma sessão de checkout numa floricultura de amostra.

POST /checkout-sessions
UCP-Agent: profile="https://agent.example/profile"
request-signature: test
idempotency-key: 0b50cc6b-19b2-42cd-afee-6a98e71eea87
request-id: 6d08ae4b-e7ea-44f4-846f-d7381919d4f2
Content-Type: application/json

Quatro cabeçalhos. Pergunte para que serve cada um e um padrão aparece.

Três dos quatro não são para a transação. São para a discordância sobre a transação.

Não é um acidente de boa higiene de API. Chaves de idempotência e IDs de requisição são boa prática comum em pagamentos, sim — mas a especificação vai bem além, e quanto mais além vai, mais clara fica a intenção.

Irretratabilidade é objetivo de projeto, não remendo de conformidade

O UCP lista quatro mecanismos de autenticação que uma empresa pode aceitar: chaves de API, OAuth 2.0, mTLS e assinaturas de mensagem HTTP conforme a RFC 9421. Três são comuns. O quarto faz algo específico.

Com assinaturas de mensagem, as duas partes publicam suas chaves públicas no array signing_keys do mesmíssimo documento de perfil que declara suas capacidades. O verificador extrai o keyid do cabeçalho Signature-Input, casa com um kid no conjunto de chaves publicado pelo signatário e confere a assinatura. Sem segredo compartilhado, sem cadastro, sem conta. A especificação chama esse resultado de onboarding sem permissão: "qualquer plataforma com um perfil descobrível pode interagir com qualquer empresa sem registro prévio".

O buraco óbvio é fechado pela vinculação de identidade. Seja qual for o mecanismo, os verificadores precisam confirmar que o principal autenticado está de fato autorizado a agir pelo perfil indicado no UCP-Agent, e rejeitar a requisição quando os dois conflitam. Você não pode se autenticar como você mesmo e depois alegar ser o agente de outra pessoa.

E webhooks que vão da empresa para a plataforma precisam ser assinados. Não "deveriam" — precisam. As atualizações de ciclo de vida do pedido — envio, entrega, devoluções — são o único ponto do protocolo em que a exigência é absoluta, porque são as mensagens que chegam depois que o dinheiro se moveu e que ninguém está olhando em tempo real.

Fonte: especificação UCP 2026-04-08, seções Identity & Authentication e Transaction Integrity.

E então vem o topo da escada. Para agentes autônomos e transações de alto valor, o UCP define uma extensão opcional, dev.ucp.shopping.ap2_mandate. Quando as duas partes a negociam:

• a empresa fornece uma assinatura criptográfica sobre as condições do checkout, e
• a plataforma fornece mandatos criptográficos provando que o usuário as autorizou.

O agente assina os objetos de mandato com a chave privada do usuário numa superfície não agêntica — ou seja, a pessoa autoriza numa tela que controla, e não dentro do laço do agente que está prestes a gastar o dinheiro dela. A declaração de propósito da própria especificação merece citação literal, porque não é frase de segurança de praxe: o mecanismo "fornece garantias criptográficas fortes e de ponta a ponta sobre os detalhes da transação e o consentimento dos participantes, reduzindo significativamente os riscos de adulteração e disputa".

E aqui está o ponto. Um protocolo desenhado só para deixar agentes comprarem não precisaria de nada disso. Condições assinadas do lado do lojista e mandatos assinados do lado do usuário não são funcionalidades de comprar. São funcionalidades de brigar sobre a compra, seis semanas depois, diante de alguém que precisa decidir quem tinha razão.

Onde a narrativa passa na frente das evidências

Três coisas se repetem sobre o UCP que as fontes primárias não sustentam do jeito que são ditas.

"Mais de 20 parceiros" é uma contagem de apoios. A formulação do Google é que o UCP foi "codesenvolvido e apoiado por mais de 20 parceiros". Apoio é uma declaração pública de suporte. Não é integração entregue, e muito menos lojista em produção. Procuramos uma fonte primária com o número de lojistas transacionando via UCP e não encontramos.

"Padrão aberto" e "padrão do Google" são ambos verdadeiros, e a tensão é real. A especificação é código aberto, o repositório no GitHub aceita pull requests e a convenção de nomes deixa qualquer um reivindicar o próprio namespace de propósito. Ao mesmo tempo, o Google construiu a primeira implementação de referência, e para participar dela uma empresa precisa de uma conta ativa no Google Merchant Center com produtos elegíveis a checkout. Protocolo neutro, primeiro palco com portaria.

O UCP não remove o lojista. Isso é distorcido com frequência suficiente para merecer uma frase direta: sob o UCP, a empresa mantém a própria lógica de negócio e continua sendo Merchant of Record. O Embedded Checkout Protocol da Shopify assume o mesmo compromisso pela outra ponta — quando o fluxo precisa de uma pessoa, o agente carrega uma continue_url e o checkout real do lojista é renderizado dentro da superfície do agente por um canal JSON-RPC 2.0, com o lojista finalizando a transação. O agente é uma superfície, não um substituto.

Quatro coisas que não conseguimos verificar, marcadas como tais

A especificação publicada em ucp.dev no momento da consulta é a versão 2026-04-08, e sua lista de capacidades padrão — Cart, Checkout, Identity Linking, Order — difere do tutorial de 11 de janeiro, cujos exemplos rodam na versão 2026-01-11 e mostram checkout, discount e fulfillment. Algo foi acrescentado entre essas duas datas. Não encontramos um changelog primário identificando quando, nem uma nota de versão datada para as versões intermediárias, então relatamos a diferença, e não um evento de lançamento.

Não encontramos nenhuma contagem publicada de lojistas em produção no UCP, nem do Google, nem da Shopify, nem de qualquer parceiro apoiador. Ausência de número não é evidência de número pequeno, mas é a razão de não imprimirmos nenhum.

O Google afirma ter construído a primeira implementação de referência que movimenta compras dentro do AI Mode da Busca e do app Gemini. Não verificamos de forma independente a disponibilidade, a geografia ou a escala desse lançamento.

Se o UCP vai virar o padrão do comércio agêntico é, no momento em que escrevemos, impossível de saber, e qualquer texto que diga o contrário está chutando. A leitura honesta é mais estreita: existe uma especificação, ela é pública, é incomumente cuidadosa quanto à prova, e várias empresas muito grandes assinaram o anúncio.

A metade não assinada

Vamos nos afastar do comércio, porque a parte interessante generaliza.

O UCP descreve um mundo em que uma máquina age em seu nome e cada passo dessa ação deixa alguma coisa para trás: quem pediu, assinado; quais condições, assinadas; quantas vezes, com chave; em que ordem, correlacionado. Seis semanas depois, quando a cobrança é contestada, existe um artefato. Ninguém precisa lembrar.

Agora pense de onde vem, de fato, a autoridade para essas ações. Um agente compra 400 unidades porque uma decisão de compra foi tomada. Um contrato se renova porque alguém concordou com uma cláusula. Um escopo muda porque duas pessoas conversaram numa quinta-feira e uma delas disse sim.

Essas conversas são a metade não assinada do mesmo fluxo de trabalho. A metade-máquina está sendo construída com recibos criptográficos e uma especificação que trata disputas como cenário de primeira classe. A metade humana, na maioria das organizações, é a memória de alguém, a memória diferente de outro alguém e um resumo escrito a partir das duas.

A assimetria vai piorar antes de melhorar, porque a metade-máquina melhora no ritmo de uma especificação e a metade humana não melhora nada. E o modo de falha é específico: não é que as pessoas mintam. É que um artefato derivado — um resumo, uma ata, uma lista de tarefas — passa a ser tratado como o registro no momento em que aquilo de que ele derivou desaparece. Resumos são, por construção, com perda. É justamente isso que os torna úteis. E é justamente isso que faz deles uma péssima fonte primária: depois que o original é descartado, não há como distinguir um resumo com perdas de um resumo exato.

Os autores do UCP entenderam isso na camada de protocolo e escreveram: guarde o original assinado, derive dele o que quiser e garanta que a derivação sempre possa ser conferida contra algo que não se moveu. É uma disciplina, não uma tecnologia, e vale exatamente tanto para uma hora de pessoas conversando quanto para um POST /checkout-sessions.

No fim das contas: comércio agêntico é um padrão de comprovantes fantasiado de compras

O Universal Commerce Protocol costuma ser descrito como um jeito de agentes de IA comprarem coisas. Lido de ponta a ponta, é mais bem descrito como uma tentativa de responder a uma pergunta que tudo que é agêntico vai encontrar o tempo todo: quando uma máquina agiu por mim, o que exatamente se pode provar sobre aquilo com que eu concordei?

A resposta do UCP é boa: declare suas capacidades em público, assine as condições, assine o consentimento, coloque chave na retentativa, correlacione a chamada e assine o webhook que depois relata o que aconteceu. Se o protocolo vai vencer é uma questão genuinamente aberta. A pergunta em torno da qual ele foi construído não vai embora, vença quem vencer.

Fica uma pergunta para carregar. Seus agentes estão prestes a ter registros melhores do que concordaram do que os que você tem do que você concordou. Onde isso vai parar?

---

Onde a Telli.sh entra: nós construímos a metade não assinada. A Telli.sh grava a conversa, separa os interlocutores, traduz ao vivo entre 15 idiomas e mantém a gravação original e a transcrição completa ao lado de cada resumo que gera — para que o artefato derivado nunca vire o único artefato. A Telli.sh não implementa o UCP nem alega implementar; tratamos da outra ponta do mesmo problema, que é o fato de as decisões que autorizam o comportamento dos agentes serem quase sempre tomadas em voz alta e não ficarem guardadas em lugar nenhum.

Grave sua próxima reunião de decisão

Fontes

• Especificação Universal Commerce Protocol, Overview, versão 2026-04-08 — modelo de serviços, capacidades e extensões, convenção de nomes, versionamento por data, algoritmo de interseção de capacidades, códigos de erro de negociação e assinatura, capacidades padrão (Cart, Checkout, Identity Linking, Order), transportes, cabeçalho UCP-Agent e sintaxe RFC 8941, mecanismos de autenticação e onboarding sem permissão, descoberta de chaves via signing_keys, vinculação de identidade, assinatura obrigatória de webhooks e a seção Transaction Integrity and Non-Repudiation; consultada em 5 de setembro de 2026
• Google Developers Blog, "Under the Hood: Universal Commerce Protocol (UCP)", 11 de janeiro de 2026 — lista de parceiros e o número de mais de 20 apoiadores, compatibilidade com AP2, A2A e MCP, o enquadramento N×N, o manifesto /.well-known/ucp, o tutorial em cinco passos e o conjunto de cabeçalhos de POST /checkout-sessions, Merchant of Record e a opção embutida, a implementação de referência do Google no AI Mode e no Gemini, e o requisito do Merchant Center; consultado em 5 de setembro de 2026
• Shopify Engineering, Ilya Grigorik, "Building the Universal Commerce Protocol", 11 de janeiro de 2026 — o enquadramento de 20+ anos, bilhões de transações e milhões de lojistas, o argumento "não é um bug, é uma propriedade emergente", os quatro princípios de projeto e o repasse do Embedded Checkout Protocol via JSON-RPC 2.0 por continue_url; consultado em 5 de setembro de 2026
• Agent Payments Protocol (AP2) — o protocolo de pagamentos com o qual o UCP declara compatibilidade
• Universal Commerce Protocol no GitHub — o repositório de código aberto citado nos dois anúncios
• Nossa leitura do GPT-6 Astra e do que a camada de captura ainda decide — o mesmo argumento pelo lado do modelo: a qualidade do raciocínio tem teto no que produziu o registro sobre o qual ele raciocina