O que é o Personal Agent Protocol?
Eu construo integrações para a eesel, então, quando um padrão promete dizer como um agente "authenticates with and acts on" uma empresa, leio como leio um contrato de API: o que está definido e o que é só uma frase de intenção. O anúncio da Sierra é em grande parte intenção, mas a intenção é específica.
Agentes pessoais são os assistentes que trabalham para um consumidor, como o Meta Muse, o Instinct e o OpenAI dots. Hoje, diz a Sierra, a maioria deles "use websites and apps the way people do" e, quando isso falha, ligam para a central de suporte ou abrem o chat do site. O PAP pretende substituir isso por uma conexão direta e autorizada. Três partes querem coisas diferentes dele:
- Consumidores querem rapidez, confiabilidade e confiança.
- Marcas querem visibilidade e controle: saber quando um agente pessoal está agindo por um cliente e decidir o que ele pode fazer.
- Criadores de agentes querem uma forma consistente de trabalhar com as empresas participantes.
Os parceiros citados na publicação da Sierra são Genesys, Instinct, Rocket, Shopify, Stripe e Walmart, ao lado de Meta e Sierra. Kevin Miller, da Stripe, resumiu o lado das empresas com clareza:
"We're contributing to the Personal Agent Protocol to give businesses a standard way to recognize their customers' agents, efficiently interact with them, and shape their customer relationships."
Como funciona uma sessão PAP?
Este é o fluxo como a Sierra o descreve, passo a passo. O protocolo começa no site, onde um agente pessoal pode descobrir o que a empresa oferece e como falar com ela. O agente então abre uma sessão para o seu usuário, e a sessão pode começar como convidado. Uma sessão de convidado pode bastar para consultar a disponibilidade de um produto ou perguntar sobre a política de devolução.
Quando a tarefa exige acesso à conta, o cliente faz login na página da empresa ou usa credenciais já configuradas com o seu agente. O cliente decide se o agente recebe acesso somente leitura ou de escrita. A sessão é construída sobre OAuth, o mesmo padrão de autorização por trás do "Entrar com o Google", e atravessa canais, de modo que uma pergunta feita antes do login e uma alteração de pedido feita depois são uma única visita.
A empresa então escolhe a porta:
| Porta | O que o agente faz | Bom para |
|---|---|---|
| Site | Navega pelas suas páginas normais | Status do pedido, consulta de políticas |
| APIs (MCP, OpenAPI) | Chama interfaces que você publica | Ações rápidas e estruturadas |
| Agente da empresa | Conversa com o seu próprio agente de IA | Qualquer coisa que exija conversa, como um pedido de garantia |
É na terceira porta que as equipes de suporte devem prestar atenção. A própria publicação da Sierra diz que o agente da empresa cuida de "tasks that need conversation", e um agente da empresa num helpdesk é exatamente isso. O Meta Business Agent, que David Singleton cita na sua publicação, é a versão da Meta da mesma ideia do lado das empresas. Minha leitura: o PAP é um padrão de porta de entrada, e o que fica atrás da porta continua sendo as suas políticas e o seu fluxo de atendimento ao cliente com IA.
Mais uma coisa que vale dizer em voz alta: Sierra, Genesys e Decagon vendem agentes do lado da empresa ou software de central de contato, então a porta do "agente da empresa" também é o território comercial delas. Isso não torna a ideia errada. Mas significa que você deve ler "aberto" como "especificação aberta" e verificar quem escreve a primeira implementação de referência.
O que de fato foi lançado e o que é só promessa?
Esta é a parte que a maior parte da cobertura pulou, então acompanhei por data. Tudo abaixo leva à página do próprio publicador.
| Data | O quê | Status |
|---|---|---|
| 6 out. | Anúncio da Sierra e publicação de Bret Taylor | Publicado: princípios, fluxo, citações de parceiros |
| 6 out. | Publicação de David Singleton, da Meta | Publicado: "previewing our work" |
| 6 out. | A Decagon abre o código do PACT | Publicado: especificação e código de referência |
| 8 out. | fleming-1 da Sierra | Lançado: detecta chamadores de IA em ligações telefônicas |
| "Later this month" | Especificação v0.1 | Prometida, não encontrada |
| Sem data | Workshops de design, implementação de referência | Prometidos |
| Sem data | Limites detalhados por ação, notificações push, extensões de pagamento | Listados como coisas que "could" vir |
Leia a última linha duas vezes. O anúncio afirma o princípio de que "companies set parameters for what those agents can do", mas os controles mais finos, que permitiriam a clientes e empresas limitar ações específicas, são descritos como trabalho futuro. Então o PAP de hoje oferece três coisas no papel: sessões de convidado versus logado, acesso de leitura versus escrita e a sua escolha de porta. Limites por ação não estão na primeira versão como descrita.
A Sierra também admite a lacuna que mais importa para uma equipe de suporte. Na publicação sobre o fleming-1 ela diz que, quando um agente usa o protocolo, "the company knows it's an agent and who it's acting for", e acrescenta: "Of course, some agents may not respect the protocol." Por isso a Sierra lançou o fleming-1 dois dias depois, um modelo que avalia em tempo real a fala de um chamador em busca de sinais de que foi gerada por IA. A Sierra diz que ele é "tuned to be conservative by default, so real people don't inadvertently get flagged" e que serve para dar informação, não um veredito.
Quem está dentro e quem está de fora?
A lista de parceiros depende de quem você pergunta, e acho que vale uma tabela, porque as diferenças são a história. Verifiquei cada fonte diretamente.
| Fonte | Parceiros citados |
|---|---|
| Blog da Sierra | Genesys, Instinct, Rocket, Shopify, Stripe, Walmart (com Meta e Sierra) |
| Jeff Weinstein, Stripe | Meta, Sierra, Genesys, Instinct, Rocket, Shopify, Walmart, com a Stripe como "founding members" |
| David Singleton, Meta | Genesys, NiCE, Decagon, Rocket, Shopify, Stripe, Walmart, com Muse e Meta Business Agent |
| Decagon no X | Entrando no "Personal Agent Protocol working group by @Muse" |
A lista de Singleton acrescenta NiCE e Decagon e deixa de fora a Instinct, enquanto a da Sierra tem a Instinct e não tem NiCE nem Decagon. O mais provável é que o grupo de trabalho tenha crescido em dois dias, o que é de se esperar de um padrão em rascunho. O que nenhuma das quatro publicações cita é OpenAI, Anthropic, Amazon, Google, Zendesk ou Salesforce. A Amazon é a que mais importa para o comércio: ela bloqueou o Muse da Meta em seu site de varejo em setembro, e um comentarista no X resumiu o custo sem rodeios.
"Nobody asked the person whose agent stopped working."
A reação no X ao lançamento foi mista. Uma resposta à publicação da Stripe soa como boa parte do ceticismo do setor que tenho visto:
"like you read the PACT announcement and released this with no spec?"
Isso é um palpite sobre motivos, e a publicação da Sierra não diz isso. Mas as datas coincidem: o código do PACT ficou público em 6 de outubro, o mesmo dia em que o PAP foi anunciado sem especificação.
Como o PAP se relaciona com o PACT?
O PACT é o parente mais bem definido, então vale entendê-lo. PACT significa Personal Agent Consent & Trust. A Decagon o desenvolveu junto com a Instinct, e o repositório aberto traz a especificação, esquemas em TypeScript, um provedor de referência, um agente pessoal de demonstração e testes de conformidade, tudo sob Apache-2.0.
Ele funciona em três passos:
- Descobrir e conectar. O agente pessoal lê o A2A Agent Card da empresa, que lista o endpoint, como autenticar e os escopos oferecidos, como
orders:readouorders:cancel. O agente assina cada requisição com um JWT de curta duração, para que o provedor possa verificar qual plataforma está chamando. - Autenticar o cliente. O agente pede escopos pelo fluxo de autorização de dispositivo do OAuth e mostra ao cliente um link de login. O cliente entra diretamente na empresa e aprova as permissões. O agente nunca vê a senha.
- Agir dentro da concessão. Cada requisição carrega tanto a identidade do agente quanto a delegação do cliente, e as respostas trazem recibos assinados que registram os escopos usados e as ações realizadas.
A escolha de design do PACT de que mais gosto é separar identidade de autoridade: "Verify which agent is calling independently of what the customer has permitted it to do." Alguém que respondeu no X apontou por que isso importa no OAuth simples:
"OAuth tells the business which customer, not which agent process holds the token. A copied bearer token works until it expires, so keep those short."
O PACT responde a isso com JWTs de agente assinados e tokens de delegação de curta duração. O anúncio do PAP ainda não diz como ele lida com isso, mais uma razão pela qual o texto da v0.1 importa. Para o produto construído sobre o PACT, incluindo a detecção e o exemplo da companhia aérea, veja minha análise anterior do Decagon Personal Agent Gateway. Uma correção a essa publicação: ela dizia que a especificação do PACT não era pública. Agora é, com o repositório publicado em 6 de outubro.
Como o PAP se compara aos outros protocolos?
A resposta honesta é que esses protocolos respondem, em sua maioria, a perguntas diferentes, e a comparação é desigual porque só alguns têm texto que dá para ler. Esta é a tabela que eu tiraria um print.
| Protocolo | Apoiado por | Pergunta que responde | Texto público hoje | Chega aos chats de suporte? |
|---|---|---|---|---|
| Personal Agent Protocol | Meta, Sierra e parceiros | Qual porta, qual cliente, leitura ou escrita | Não, v0.1 prometida | Sim, pela porta do agente da empresa |
| PACT | Decagon, Instinct | De quem é este agente, quais escopos o cliente concedeu | Sim, especificação e código no GitHub | Sim, feito para agentes de suporte |
| A2A | Agentic AI Foundation, mais de 150 organizações | Como dois agentes se encontram e trocam mensagens | Sim, especificação 1.0 | Só transporte: a autorização é "implementation-specific" |
| MCP | Citado no PAP como opção de API | Como uma IA chama ferramentas e dados | Sim | Ferramentas, não consentimento |
| Web Bot Auth | Cloudflare | Qual bot está visitando o meu site | Sim | Não, tráfego web |
| Trusted Agent Protocol | Visa | Este agente de checkout é confiável | Sim, com a ressalva "development and deployment" | Não, checkout do lojista |
| Agent Pay probability score | Mastercard | Este pagamento foi iniciado por um agente de IA | Testes nos EUA | Não, pagamentos |
| fleming-1 | Sierra | Este chamador de telefone é uma IA | Recurso de produto, agentes de voz da Sierra | Chamadas de voz |
Duas coisas saltam aos olhos. Primeiro, o PAP mira a linha que ninguém terminou: consentimento e escopo entre o agente de um consumidor e uma empresa, em todos os canais. Segundo, nada na linha de pagamentos fala com o suporte. O protocolo da Visa usa assinaturas vinculadas ao domínio e à operação específica, e a pontuação da Mastercard trata de saber se uma transação foi iniciada por IA. Nenhum dos dois avisa o seu helpdesk de que o agente de um cliente quer um reembolso. A própria publicação da Sierra lista "payments extensions" como trabalho futuro do PAP, o que indica onde as famílias de protocolos podem acabar se encontrando. Se você vende online, o agentic commerce protocol e a versão da Stripe são o lado do checkout da mesma história.
Qual protocolo cobre o seu caso?
Escolha a tarefa que importa para você. O widget mostra qual padrão trata dela, quão pronto está e o que eu faria agora.
O que uma equipe de suporte deve fazer antes de a especificação sair?
A maioria das equipes de suporte não será adotante precoce de um protocolo sem especificação. O trabalho útil está do seu lado da porta e é o mesmo qualquer que seja o padrão que prevaleça, PAP, PACT ou ambos. Os agentes dos clientes já chegam às filas por chat, e-mail e telefone, como mostram OpenAI dots para atendimento ao cliente e Instinct para atendimento ao cliente, então eu faria nesta ordem:
- Liste todas as ações que sua IA de suporte pode executar. Classifique cada uma como leitura, escrita reversível, movimentação de dinheiro ou controle de conta. A maioria das equipes nunca escreveu isso, e vira sua lista de escopos.
- Coloque aprovações em dinheiro e em mudanças de conta. Um reembolso é um reembolso, seja pedido por uma pessoa ou por um agente. Os guias de ações avançadas de IA do Zendesk e de ações de IA do Gorgias mostram o que as ferramentas nativas conseguem controlar.
- Conte o seu tráfego de agentes. Marque as conversas que parecem enviadas por agentes e meça a proporção antes de comprar detecção. A própria Sierra diz que uma empresa de grande volume "might start by measuring how often it happens".
- Escreva o escalonamento com duas saídas. Sua IA deve passar para uma pessoa e também dizer o que precisa do agente do cliente. O guia de gestão de escalonamento com IA cobre o lado humano.
- Mantenha uma entrada para as APIs. Se você já publica uma API de atendimento ao cliente com IA ou uma API de helpdesk, essa é a porta número dois. Defina o escopo antes de divulgá-la.
- Reproduza tickets antigos antes de entrar no ar. Rode tickets reais de reembolso e cancelamento contra a sua IA e veja onde ela cede. O agente de um cliente achará o ponto fraco mais rápido que qualquer cliente.
O sexto ponto tem uma cicatriz por trás. Um líder de suporte contou à eesel numa chamada de vendas o que precisava de uma IA para confiar nela:
"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
A CX lead at a DTC supplements brand on Gorgias and Shopify, about 7,000 tickets a month
Essa frase é uma definição de escopo em palavras simples. Também é o teste certo para um agente pessoal do outro lado: se a sua IA não consegue dizer "este não é meu", ela não consegue encontrar com segurança um agente que vai perguntar de cinco jeitos diferentes.
As equipes de e-commerce têm mais uma tarefa. Se você usa Shopify, que está na lista de parceiros, o guia de estratégias de atendimento ao cliente com IA no Shopify e o Muse para o suporte ao cliente do Shopify mostram como os agentes já chegam a essas filas. Para o lado da própria Meta, veja Meta Muse para atendimento ao cliente.
Onde a eesel se encaixa?
Serei direto sobre os limites. A eesel não detecta agentes pessoais e não implementa PAP, PACT nem A2A. Se você precisa de um fornecedor que esteja construindo um canal de agente para agente com escopos concedidos pelo cliente, Sierra e Decagon são as duas que vale olhar, e a comparação Decagon vs Sierra e o resumo de alternativas à Sierra mostram os prós e contras. Quando a v0.1 for publicada, vou lê-la frente ao que a eesel faz e escrever sobre a diferença, em vez de adivinhá-la agora.
O que a eesel faz é a camada de permissões no helpdesk que você já usa. O colega de IA para helpdesk entra no Zendesk, no Freshdesk ou no Gorgias como um novo contratado. Cada ação que ele pode executar é definida como Auto, Precisa de aprovação ou Desativada, agrupada em Leitura e Escrita, conforme a documentação de ações da eesel. Você pode dizer em palavras simples: "consulte as coisas por conta própria, mas me pergunte antes de qualquer reembolso".
É a mesma divisão entre leitura e escrita que os protocolos formalizam, voltada para a sua própria IA. Se o PAP chegar com limites por ação, são essas as configurações às quais eu os associaria. E, como os protocolos falam de APIs e MCP, mais um detalhe: todo workspace da eesel também é um servidor MCP, e a CLI da eesel controla o mesmo colega a partir de um terminal. Um agente de programação como o Claude Code pode executar eesel integrations <platform> actions para ver cada ação e sua configuração de aprovação, ou eesel approvals para aprovar ou negar ações retidas. A CLI segue as mesmas permissões do painel, então uma escrita definida como "precisa de aprovação" fica retida até que uma pessoa a aprove.
O que as pessoas estão dizendo?
A reação pública ao PAP em si ainda é tímida, o que faz sentido três dias após o lançamento. O debate mais amplo sobre agentes que contatam o suporte é mais barulhento. No Hacker News, o comentário mais útil que encontrei veio do lado do cliente da mesa:
"The solution for both sides is for the companies to implement support bots that have more power to address my problem than the humans they replaced were ever given."
Coloque isso ao lado da leitura do PAP feita por Simon Taylor no X, onde ele o chamou de alternativa ao bloqueio e disse que permite a uma empresa "recognize it, give it read-only by default, and route anything that moves money to your own agent". É a interpretação dele, não o texto da Sierra, mas é a versão para a qual eu construiria. Bloquear afasta o cliente, e uma porta aberta sem limites é pior. São os escopos que permitem aos dois lados ganhar algo.
Experimente a eesel
Se os agentes dos seus clientes estão prestes a pedir reembolsos à sua fila, a primeira tarefa é decidir ao que a sua própria IA pode dizer sim. O colega de IA para helpdesk da eesel se conecta ao Zendesk, Freshdesk ou Gorgias, aprende com seus tickets antigos e sua central de ajuda e mantém reembolsos e cancelamentos atrás de uma aprovação até você ver que ele segura a linha. Você pode rodá-lo em tickets antigos numa simulação antes que ele toque em um cliente.
O plano gratuito inclui 100 créditos e todas as integrações, e os planos pagos começam em US$ 299 por mês para 500 créditos, em que um ticket ou um chat custa 1 crédito, na página de preços da eesel. Experimente a eesel na sua própria fila.