A Meta, a Walmart e a Stripe querem que os agentes iniciem sessão em vez de clicar. A especificação ainda não existe
By Surya Pratap
10 de outubro de 2026
9 min read
AI & Technology
10 de outubro de 2026
9 min read
Convidado, depois leitura, depois escritaHover to exploreHoje, um agente pessoal de IA que queira consultar uma encomenda, reservar uma mesa ou alterar uma morada de entrega faz o mesmo que uma pessoa: carrega a página, encontra o formulário e vai preenchendo. É lento, deixa de funcionar quando a página muda e, normalmente, a empresa do outro lado não sabe se está a lidar com uma pessoa ou com um programa.
Esta semana, um grupo de grandes empresas propôs outro modelo: o agente inicia sessão, o cliente decide o que ele pode fazer e a empresa decide como ele entra.
Este artigo baseia-se em «Introducing Personal Agent Protocol», de Bret Taylor e Clay Bavor, da Sierra, publicado a 6 de outubro de 2026, e na cobertura da The Next Web, da Constellation Research e do The Daily Brief. À data em que foi escrito, não tinha sido publicada nenhuma especificação. A leitura a partir da secção 4 é minha.
A 6 de outubro de 2026, na cimeira da Sierra em São Francisco, a Sierra e a Meta anunciaram o Personal Agent Protocol, que descrevem como uma norma aberta sobre «a forma como os agentes pessoais interagem com as empresas». Os parceiros fundadores indicados são a Genesys, Instinct, Rocket, Shopify, Stripe e Walmart.
A ideia, nas palavras da Sierra: «os consumidores decidem que acesso dão aos seus agentes pessoais, e as empresas definem os parâmetros do que esses agentes podem fazer».
O anúncio organiza o protocolo em torno do que três grupos querem:
O interesse da Meta é direto. O seu agente pessoal, o Muse, é exatamente o tipo de agente para o qual o protocolo foi pensado. Segundo a Constellation Research, o Muse faz dois testes antes de agir: se uma pessoa honesta faria o mesmo — o exemplo dado é criar cinco contas para usar um único cupão — e se o sistema aguentaria caso todos os agentes o fizessem.
O anúncio descreve uma sessão com três níveis de acesso:
A sessão assenta em OAuth, a norma que a maioria dos inícios de sessão já usa. Além disso, «mantém-se entre canais, de modo que uma pergunta feita antes de iniciar sessão e uma alteração a uma encomenda feita depois fazem parte da mesma visita».
Do lado da empresa, é ela que escolhe como os agentes chegam até si:
O cliente escolhe quanto o agente pode fazer. A empresa escolhe por que porta ele entra. Por agora, a proposta é só isto.
Isto é um anúncio, não uma norma que se possa implementar esta semana.
Bret Taylor, citado pelo The Daily Brief, resumiu o ponto em que estamos: «Enquanto não existir uma norma assim, isto é um bocado o caos.»
Vale a pena ler este anúncio ao lado dos outros com que se sobrepõe. O The Daily Brief comparou quatro:
| Protocolo | Principais apoiantes | Foco |
|---|---|---|
| Agentic Commerce Protocol (ACP) | OpenAI, Stripe | Pagamento dentro do agente, com tokens de pagamento delimitados |
| Trusted Agent Protocol (TAP) | Visa, Cloudflare | Provar a identidade de um agente com pedidos assinados |
| Universal Commerce Protocol (UCP) | Google, Shopify e outros | A compra completa, da descoberta ao pós-venda |
| Personal Agent Protocol (PAP) | Sierra, Meta, Walmart e outros | Como o agente de uma pessoa inicia sessão e o que pode fazer |
A Stripe e a Shopify estão envolvidas nos quatro. As empresas com mais a perder se escolherem a norma errada decidiram não escolher. Uma startup de cinco pessoas não deve tentar ter mais certezas do que elas.
Além disso, os protocolos respondem a perguntas diferentes. O TAP trata de que agente está a fazer o pedido. O ACP trata de pagar. O PAP trata do que este cliente autorizou este agente a fazer na sua conta. Um produto real pode acabar por precisar de partes de mais do que um.
A boa notícia é que a base que todos estes protocolos exigem é a mesma, e quase toda ela também melhora o produto para as pessoas.
Torne os dados públicos legíveis sem início de sessão. Stock, preços, horários, zonas de entrega, política de devoluções. Se um agente em modo convidado não os conseguir ler de forma fiável, vai mandar o utilizador para onde consiga. Servem tanto dados estruturados nas suas páginas como uma pequena API só de leitura.
Separe o acesso de leitura do acesso de escrita. Se a sua API tem um único token que faz tudo, um agente a quem o cliente só queria deixar ver as encomendas também as pode cancelar. Scopes OAuth distintos para «ler a conta» e «alterar a conta» são o mínimo que o protocolo pressupõe.
Torne as ações de escrita seguras de repetir. Os agentes voltam a tentar. Uma alteração de encomenda, uma reserva ou um pedido de reembolso devem aceitar uma chave de idempotência, para que o mesmo pedido enviado duas vezes só seja executado uma. Acrescente um passo de confirmação para tudo o que seja caro ou irreversível.
Identifique as sessões de agentes. Registe se uma ação veio de uma pessoa, de um agente conhecido em nome do cliente ou de um script desconhecido. Não consegue definir limites de utilização, detetar abusos nem medir a receita trazida por agentes se não distinguir esse tráfego.
Se já expõe uma API, um servidor MCP sobre um punhado das tarefas mais comuns dos seus clientes é uma forma barata de perceber o que os agentes pedem de facto. Comece por ferramentas só de leitura. Acrescente ferramentas de escrita apenas quando conseguir ver quem está a chamar e tiver a idempotência e a confirmação resolvidas.
Escolher o canal
O protocolo deixa-o escolher entre o seu site, a sua API e o seu próprio agente. Para a maioria dos produtos em fase inicial, a primeira resposta certa é a API: um site é frágil para um agente, e manter um agente próprio virado para o cliente é um produto em si mesmo. Ofereça um agente próprio quando a tarefa precisar mesmo de uma conversa — uma devolução complicada, uma dúvida sobre um crédito à habitação — e não como porta de entrada por defeito.
Que o PAP vai ganhar. Tem nomes de peso e nenhuma especificação. O UCP, o ACP e o TAP têm cada um os seus pesos pesados, e a sobreposição de membros mostra que nada está decidido.
Que os agentes vão chegar em breve ao seu produto. A própria investigação da Visa concluiu que a maioria das pessoas ainda não está disposta a deixar um agente pagar por si. O protocolo torna os agentes mais capazes; não faz com que os clientes confiem neles.
Que resolve as questões jurídicas. O anúncio não diz quem responde quando um agente com acesso de escrita faz algo que o cliente não pretendia. Também não diz como os pagamentos aprovados por um agente se enquadram em regras como a autenticação forte do cliente na Europa, pensadas para uma pessoa que aprova um pagamento. Para ver como um tribunal tratou agentes que atuam em nome de utilizadores, leia a nossa análise da decisão do Ninth Circuit no caso Perplexity.
Que os detalhes estão fechados. Tudo o que está nas secções 2 e 3 vem de um anúncio. A especificação v0.1 pode mudar nomes, scopes ou o modelo de sessão.
A Meta, a Sierra, a Walmart, a Shopify, a Stripe e outras empresas propuseram uma forma normalizada de o agente de IA de uma pessoa iniciar sessão numa empresa. Os agentes começam como convidados, o cliente escolhe via OAuth acesso só de leitura ou de escrita, e a empresa decide se os agentes usam o site, as API ou um agente próprio. Ainda não há especificação, pagamentos, permissões detalhadas nem órgão de governação, e é um de quatro protocolos que se sobrepõem.
O protocolo que acabar por adotar importa menos do que a base que todos pressupõem: dados públicos que um agente consiga ler, acesso às contas com permissões delimitadas, ações de escrita que se possam repetir sem risco e a capacidade de distinguir tráfego de agentes de tráfego humano.
Escolha as três tarefas mais comuns dos seus clientes. Ponha as de só leitura a funcionar sem início de sessão e torne as de escrita delimitadas, repetíveis e registadas. Depois, leia a especificação v0.1 quando sair, em vez de esperar que saia para começar.
Fontes: Bret Taylor e Clay Bavor, «Introducing Personal Agent Protocol», Sierra, 6 de outubro de 2026 — os parceiros, o princípio enunciado, as necessidades dos três grupos, os níveis de convidado, só leitura e escrita, o OAuth e as sessões entre canais, os canais site, API e agente da empresa, o calendário da v0.1 e o trabalho futuro sobre pagamentos, permissões e notificações. The Next Web, para a data e o contexto do anúncio. Larry Dignan, Constellation Research, 7 de outubro de 2026 — o Muse da Meta e os seus dois testes. Rajesh Beri, The Daily Brief, 7 de outubro de 2026 — a ausência de especificação, licença e órgão de governação, a citação de Bret Taylor e a comparação com o UCP, o ACP e o TAP. A leitura das secções 4 a 6 é minha.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
