A Sierra publicou o rascunho 0.1 do Personal Agent Protocol, ou Poppy, em 9 de outubro, três dias depois de anunciar o projeto com a Meta e outros parceiros. O novo documento transforma a promessa ampla do lançamento em regras propostas para encontrar a interface de agente de uma empresa, identificar um agente pessoal, fazer o cliente entrar e manter uma visita entre um site, APIs e um agente da empresa.

Ainda é um rascunho. A especificação diz que qualquer parte pode mudar antes de uma versão estável, inclusive de formas incompatíveis. A Sierra também citou mais 35 parceiros de design. Participar do processo de design não comprova que essas empresas implantaram interfaces Poppy.

A grande mudança

  • O que mudou: O anúncio de 6 de outubro descreveu uma forma de agentes pessoais trabalharem com empresas. O rascunho de 9 de outubro detalha as trocas propostas de identidade, permissão e sessão que uma empresa e um agente precisariam implementar.
  • Por que isso importa: Um cliente poderia autorizar um agente a executar tarefas na conta, enquanto a empresa identifica o agente e limita seu acesso. O rascunho conecta esse controle à navegação no site, às APIs e às conversas, embora a empresa escolha os canais e as permissões que oferece.
  • O que observar: Agora os implementadores têm interfaces concretas para analisar, mas as regras sobre pagamentos, notificações e anexos continuam em aberto. A Sierra planeja oficinas de design e uma implementação de referência no próximo mês; nenhuma delas é, até agora, prova de interoperabilidade ampla.

A descoberta começa no domínio da empresa

Segundo a especificação preliminar, uma empresa participante publica /.well-known/poppy.json por HTTPS. O documento informa a organização e o emissor OAuth, os métodos de login aceitos e qualquer endpoint de sessão do site, API OpenAPI ou MCP, ou endpoint de conversa com agente empresarial que ela ofereça. A empresa não precisa oferecer todos os caminhos. O agente usaria o arquivo para descobrir o que está disponível, sem tratar o site como única porta de entrada.

O arquivo sozinho não pode autorizar um agente. O domínio da organização precisa corresponder ao domínio solicitado pelo agente. Ele também precisa verificar os metadados do servidor OAuth: o emissor deve corresponder ao arquivo, e a lista poppy_domains precisa incluir o domínio da organização. Essas verificações pretendem impedir que um domínio sem relação reivindique o emissor de outra empresa e receba tokens.

O agente pessoal se identifica por uma URL HTTPS de client_id que fornece os metadados do cliente, incluindo chaves públicas de assinatura e endereços de redirecionamento permitidos. A empresa pode exigir cadastro prévio, bloquear ou revogar um ID de agente e limitar a criação de sessões. O rascunho dá esses controles à empresa; não exige que toda empresa aceite qualquer agente.

Uma sessão de visitante pode se tornar uma sessão de conta

O agente pessoal atribui ao usuário um ID estável e opaco, específico para cada empresa, e inicia uma sessão com uma declaração assinada. A empresa retorna um token de sessão sem login. Assim, pode reconhecer o mesmo agente e usuário entre sessões sem considerar a pessoa conectada. O rascunho proíbe derivar esse ID de nome, e-mail ou telefone, inclusive por hash com chave.

Para acessar a conta, a empresa anuncia os métodos de login aceitos. O login direto usa uma página de autorização OAuth e PKCE no navegador do usuário. No login por dispositivo, o usuário acessa a página da empresa por um link e um código. O login mediado permite que o agente envie credenciais fornecidas pelo usuário a um endpoint específico da empresa; é um caminho separado e opcional, com regras explícitas para tratamento de credenciais e limitação de taxa. O rascunho reconhece um limite de confiança: a empresa nem sempre consegue verificar se foi uma pessoa, e não o agente, que concluiu uma página de login direto.

As permissões são expressas como escopos. O Poppy define escopos amplos poppy:read e poppy:write escopos, mas permite que a empresa ofereça escopos personalizados mais restritos. A empresa não pode conceder mais do que o agente pediu nem mais do que um método de login específico permite. Um token de conta, emitido após o login, permite ao agente obter tokens de sessão autenticados posteriores dentro dos escopos aprovados. Se uma tarefa exigir mais acesso, o usuário precisa fazer login novamente para esses escopos.

A diferença entre os dois tokens importa. O token de sessão tem curta duração e é usado em chamadas de API e conversas. O token de conta é uma credencial OAuth de atualização, mais duradoura, usada apenas nos endpoints de token e revogação da empresa. O rascunho diz que o agente deve mantê-lo fora do contexto do modelo, de mensagens, logs e URLs. Sair revoga o token de conta e desconecta as sessões vinculadas; a empresa também pode encerrar essas sessões. Tokens de sessão já emitidos podem continuar válidos, por isso o rascunho recomenda verificar o estado da sessão em cada solicitação ou usar prazos de validade bem menores.

Uma sessão, três caminhos possíveis

O Poppy propõe uma única sessão da empresa para a atividade do usuário por meio do agente pessoal. Para chamadas OpenAPI e conversas com um agente empresarial, o agente envia um token de sessão no cabeçalho de autorização. Em geral, o rascunho vincula esses tokens a uma chave mantida pelo agente por meio de provas DPoP, verificadas pela empresa em cada solicitação. MCP é uma exceção explícita: sua autorização usa um token bearer restrito ao servidor MCP listado, e o rascunho permite esse formato bearer apenas para APIs MCP. São requisitos do protocolo, não uma constatação de que uma implementação é segura.

A navegação no site entra na mesma sessão de outro modo. Se a empresa publicar um endpoint de sessão do navegador, o navegador do agente envia uma declaração assinada de curta duração e recebe o cookie de sessão da própria empresa. O site aplica então o estado atual de login e os escopos da sessão. Sem esse endpoint, o agente navega como visitante comum sem login. A conta de lançamento da Sierra descreveu uma visita entre canais; o rascunho especifica credenciais diferentes para o tráfego do navegador e da API nessa sessão compartilhada.

A empresa pode listar descrições OpenAPI, servidores MCP e um endpoint de conversa no arquivo de descoberta. O rascunho descreve um formato de conversa Poppy para falar com um agente da empresa e chamar uma pessoa quando necessário. Cada API define seu próprio esquema. A empresa decide quais caminhos expõe e pode limitar o que um agente faz mesmo em uma sessão conectada.

O que o rascunho ainda não resolve

A página de tópicos em aberto do protocolo aponta três grandes lacunas: pagamentos, notificações push quando não há uma solicitação aberta e anexos como recibos, etiquetas, imagens ou formulários. A página diz que a lista está incompleta. Os exemplos do rascunho usam empresas fictícias e credenciais de preenchimento.

A publicação da Sierra em 9 de outubro descreve uma demonstração em conferência envolvendo Muse, da Meta, e Rocket. Esse é o relato da Sierra sobre uma demonstração encenada, não uma auditoria independente de uma implantação em produção. A Sierra diz que fará oficinas de design e publicará uma implementação de referência no próximo mês. Por enquanto, o Poppy é uma proposta publicada com detalhes de implementação e uma lista crescente de parceiros de design. Seu alcance prático depende de quais empresas e desenvolvedores de agentes pessoais implementarão versões compatíveis e do acesso que de fato oferecerão.

Fontes e leitura complementar

  • Especificação do Personal Agent Protocol, rascunho 0.1, atualizada em 9 de outubro de 2026. Fonte primária das regras de descoberta, identidade, login, escopos, tokens, sessões e canais. Permite explicitamente mudanças incompatíveis antes de uma versão estável; os exemplos são fictícios.
  • Tópicos em aberto do Poppy, atualizada em 9 de outubro de 2026. Lista primária de pagamentos, notificações push e anexos deixados de fora do rascunho atual; a página diz que outras lacunas podem surgir.
  • Anúncio da Sierra de 9 de outubro. Registra a data de publicação, mais 35 parceiros de design, uma demonstração em conferência relatada e oficinas/implementação de referência planejadas. São declarações da Sierra, não provas de implantação.
  • Apresentação da Sierra de 6 de outubro. Mostra o que o anúncio inicial propôs e o que mudou com o rascunho técnico posterior.