Personal Agent Protocol (“Poppy”) is an open protocol, announced by Sierra and Meta on 6 October 2026, for how a personal agent acting for one person works with a company on that person’s behalf. A company publishes /.well-known/poppy.json declaring how agents can start a session, which sign-in methods and scopes it offers, and which channels it exposes — its website, its APIs (OpenAPI or MCP), or a company agent. Sessions are built on OAuth, start signed out under a stable per-company user ID that carries no personal information, and can be signed in with read or write access the person chooses. Draft 0.1, Apache 2.0.
Personal Agent Protocol
Personal Agent Protocol — “Poppy” for short — sets out to replace the all-or-nothing choice companies face with personal agents today: block the agent, or let it sign in as the person and do anything they can. It was announced on 6 October 2026 by Bret Taylor and Clay Bavor as an open standard Meta and Sierra are developing with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. The specification is published as draft 0.1 (updated 9 October 2026) under the Apache License 2.0, and says plainly that any part of it can change, including in ways that are not backward compatible. A reference implementation and design workshops are planned; no source repository is linked from the site yet.
- Discovery at a well-known path - A company MUST publish
poppy.jsonathttps://{domain}/.well-known/poppy.json. It names the organization, the OAuth issuer, the sign-in types and scopes on offer, a company agent endpoint, a browser-session endpoint, and a list of APIs. Theorganization.domainMUST match the host the agent requested, so a redirect to a hosting provider does not change who the document speaks for. - APIs are OpenAPI or MCP - Each listed API is typed
openapi(an OpenAPI 3.0 or 3.1 description) ormcp(a remote MCP server over Streamable HTTP, 2025-06-18 or later). Agents skip types they do not recognize. Every listed API must accept the session’s tokens — DPoP for OpenAPI, Bearer for MCP — and an MCP server’s protected resource metadata (RFC 9728) must name the company’s issuer. - Sessions before sign-in - An agent always identifies itself, and starts a session signed out under a
user ID that is stable at one company and different at every other, so companies cannot match users
with each other. Direct, device and mediated sign-in flows then attach a company account, with scopes
such as
poppy:readandpoppy:write. - One session across channels - Web browsing, API calls and conversations with a company agent share the session, so a question asked before sign-in and an order changed after it are one visit. The conversation channel covers streaming, human-or-AI status and handoff to a person at the company.
- Controls, not policy - The protocol offers options and leaves the choices to each side: whether agents may work anonymously, which agents to allow, which channels to offer, and how much access a person grants. Payments, push notifications and finer-grained permissions are named as extensions to come.
- Built on existing standards - OAuth 2.0, JWTs, DPoP, OAuth server metadata (RFC 8414), protected resource metadata, OpenAPI and MCP, defining something new only where no standard covers the need.
Where it sits. Poppy is a discovery-plus-authorization layer for the consumer’s agent reaching a
company, and it defines its own well-known document rather than reusing the
AI Catalog at /.well-known/ai-catalog.json that MCP Server Cards and
Agentic Resource Discovery point to. It complements
A2A for the company-agent conversation, and relies on OAuth for
everything about access.
