What Is Poppy? When Should Your API Support Customer Agents?

Poppy is the short name for the Personal Agent Protocol, which its overview defines as "an open protocol for how personal agents and companies work together." Sierra and Meta are developing it with industry partners, and the specification is draft 0.1, updated October 9, 2026. As of October 12, 2026, the right call for most consumer-facing API platforms is a small, disposable experiment with no production rollout, while you build the pieces any customer-agent channel needs.

By Sierra's account, most personal agents already use company websites and apps the way people do, loading pages and clicking through forms, and when that can't finish the job they may call the support line or open web chat. The protocol's overview calls this "all or nothing": either the agent "passes as the user, signing in with their password and clicking through pages built for people," or the company blocks it, and "the company can't tell an agent from a person or offer it a better path." Neither source publishes a measurement. Where it matches your traffic, you can't tell an agent from your customer, and your customer can't limit what the agent does once it is in. On a platform that moves money, holds health records, or changes bookings, that is a question for your fraud and privacy owners as much as for your API team.

Poppy's draft names the pieces that close that gap: agent identity by client_id, signed-out Sessions under User IDs that carry no personal data, short-lived key-bound Session Tokens, revocation, and human handoff. That work is likely to carry over whichever customer-agent protocol wins, since PACT, the A2A-based parallel design, also asks for scopes, consent, and discovery. Draft 0.1 defines no audit log, so you design that part.

TL;DR

• Poppy is a consent and session layer between a customer's personal agent and a company. It reuses the company's APIs, MCP server, website, or company agent as channels.
• As of October 12, 2026, the spec is draft 0.1 with breaking changes allowed, no official reference implementation is public, and we found no public evidence of production adoption.
• An OAuth API plus an MCP server already provides scoped delegated authorization. Draft 0.1 adds signed-out Sessions, per-User agent attribution with allow and block lists, key-bound tokens, human handoff, and revocation back to signed out.

What a customer's agent needs from your platform

The spec's term for a customer's agent is personal agent. It is a new kind of client, and it needs six things: discovery (where your channels are and how to sign in), authorization (what the customer allowed), scoped Sessions tied to one agent and one customer, a route to a human, privacy for a customer who has not signed in, and somewhere to act. The status quo covers only the last. A browser agent holding the customer's password looks like the customer to you. MCP's authorization spec gives you scoped OAuth for tools, but it defines no signed-out session, no per-company User ID with no personal data, no human handoff, and no session shared across channels. Poppy puts all six behind one documented interface.

How a Poppy request flows, end to end

The draft spec walks one agent from discovery to sign-out, in this order (draft 0.1, so any step can change):

(opens the full-size image in a new tab)

1. Discover. "A Company MUST publish its poppy.json document at https://{domain}/.well-known/poppy.json over HTTPS." It lists your sign-in options (auth) and channels (agent, apis, web).
2. Identify the agent. "A Personal Agent's client_id MUST be an HTTPS URL that returns its metadata document." You may require registration ahead of time and keep allowlists or blocklists by client_id.
3. Start signed out. The agent sends a signed assertion (a JWT bearer grant) to your token_endpoint, naming itself (iss) and the User (sub). "A Session starts signed out": you can recognize the same User over time, but not who the User is. The User ID "MUST NOT contain or be derived from personal information, such as an email address, phone number, or name, even with a keyed hash."
4. Sign in and grant scope. Sign-in is Direct ("the OAuth 2.0 authorization code flow with PKCE"), Device ("the OAuth 2.0 device authorization grant"), or Mediated, which "is not an OAuth flow." Base scopes are poppy:read and poppy:write, plus any you define. Sign-in returns an Account Token, "A long-lived credential from sign-in."
5. Get a key-bound Session Token. The Account Token yields signed-in Session Tokens, "bound to a key the Personal Agent holds, so a copied token is useless without it," which "SHOULD last hours, not days."
6. Act. The agent calls your APIs ("DPoP for OpenAPI, and Bearer for MCP"), gets a website cookie through web.browser_session_endpoint, or talks to your company agent through the conversation API.
7. Hand off. The agent sends "an empty JSON object" to POST {endpoint}/{id}/handoff; the conversation's responder is agent or human, and its status is working, idle, queued, or closed.
8. Close. An empty JSON object to POST {endpoint}/{id}/close ends the conversation.
9. Revoke or fail. The agent revokes its Account Token at your revocation_endpoint, and you sign out every Session signed in with it: "Usually those Sessions continue signed out, so a cart or an open conversation carries on." Failures return invalid_token (401), sign_in_required (403), insufficient_scope (403), invalid_session (400), or account_mismatch (400).

Poppy vs MCP vs A2A

The last column is today's browser agent. Versions: Poppy draft 0.1, MCP schema 2026-07-28, and A2A 1.0.0, as of October 12, 2026.

The layers stack: Poppy decides which agent is asking and what the customer allowed; an MCP server is one channel it can route that agent through.

A2A's relationship to Poppy is unsettled. Neither the Poppy spec nor Sierra's posts mention A2A, so no primary source defines it; the independent tracker poppy.md calls the two "Mostly complementary, with one overlap to watch: the 'company agent' route." The A2A-based design is Decagon's PACT (Personal Agent Consent & Trust Protocol), released October 6, 2026, the same day Sierra announced the Personal Agent Protocol, and "Built on the Agent2Agent protocol and OAuth 2.0." Decagon says PACT joins "the Personal Agent Protocol working group announced by the team behind Meta's Muse," though no Poppy spec text mentions PACT. For A2A's own production gaps, read A2A production readiness: what it takes beyond protocol support.

Where Poppy stands on October 12, 2026

Maturity, implementations, and adoption are separate claims.

Draft maturity. The spec's status line marks it Draft 0.1, updated October 9, 2026, under the Apache License 2.0, and warns that "Any part of it can change before a stable version, including in ways that aren't backward compatible." No editors, governance body, or standards organization appear on the spec, overview, or home page.

Implementations. On October 9, Sierra wrote, "Over the next month we will host design workshops and publish a reference implementation to help developers get started." As of October 12, the independent tracker poppy.md says of the official reference implementation, "none is public yet." It lists only community and partner-demo work, such as a Cloudflare Workers demo, a demo of Meta's Muse shown only in an X video, and the independent Datalayer SDK, which implements "draft 0.1 (2026-10-09)."

Production adoption. We found no public evidence of it. On October 9 the orka project reported, "No company publishes a PAP file," after checking about 40 sites, including the launch partners: "Some sites blocked the check, and none of the rest had one." Sierra's October 9 post adds 35 design partners, including OpenAI, Visa, Mastercard, PayPal, Okta, and Bank of America, to the launch partners Meta, Genesys, Instinct, NiCE, Rocket, Shopify, Stripe, and Walmart. Design-partner status is not an implementation, and poppy.md lists no design-partner implementation beyond demos as of October 12. A go/no-go review in the fillthemat project's GitHub issues said of OpenAI's listing as a design partner, "This does not establish ChatGPT support or merchant traffic."

What your API team would need to build

The minimum is small: a company implements "one of agent, apis, or web," and sign-in is optional: "With none, it offers only signed-out Sessions."

An OAuth API plus an MCP server already covers:

• Scoped delegated authorization: under MCP's authorization spec, a protected server "acts as an OAuth 2.1 resource server," publishes RFC 9728 metadata that tells clients how to authorize, and can step up scope on insufficient_scope.
• Direct and Device sign-in, if your OAuth server runs PKCE and the device grant. The OpenAgents team found this overlap: "We already have RFC 8414/9728 metadata, PKCE, a device flow (coder login) and an MCP resource server."
• An API channel: an MCP server listed in apis is a valid Poppy channel with Bearer tokens.
• Agent identity by URL: MCP's authorization spec says authorization servers and MCP clients "SHOULD support OAuth Client ID Metadata Documents," where the client uses an HTTPS URL as its client_id.

Draft 0.1 adds:

• A poppy.json discovery file pointing at your existing endpoints.
• Agent and User attribution on every token, plus allow and block lists by client_id.
• Signed-out Sessions started from the agent's signed assertion, with User IDs never derived from personal data.
• Key-bound Session Tokens that last hours, checked on OpenAPI calls with DPoP (RFC 9449), which proves the caller holds the agent's key.
• One Session across channels, including a browser_session_endpoint whose cookie follows sign-in and sign-out.
• Handoff and close endpoints, if you offer a company agent, wired to a staffed queue.
• A revocation_endpoint that signs out every Session tied to an Account Token.
• Audit records you design. The spec gives attribution ("the Company always knows a request comes from a Personal Agent, which one, and for which User") and defines no audit log.

For delegated OAuth in more depth, read OAuth for AI agents: why general-purpose agents strain the integration model.

The case against adding Poppy now, and where it holds

The strongest objection is that an OAuth API, and maybe an MCP server, is enough, and a new draft protocol is premature. The evidence supports much of it. The spec can change incompatibly, and fillthemat found that "Datalayer shipped 11 non-stage npm versions Oct 10–11, including breaking changes." We found no adoption to serve, and PACT is a parallel design, though poppy.md notes it is "now an input to the Poppy working group rather than a rival, at least on paper." Three of the four public GitHub issues we found from October 9 to 12 stopped short of production: orka wrote, "We should not build anything yet," OpenAgents closed its issue as "Not on the V1 launch path," and fillthemat's review said "NO-GO for production rollout or substantial investment yet." The fourth is fillthemat's own follow-up spec: "The owner chose (2026-10-11) to build full support anyway, as a deliberate bet." That is a planned build, not adoption.

On Hacker News, in a thread with two comments, one commenter asked, "As a human directing my personal agent, why does it need a protocol?"

On scoped authorization, the objection is right, and a large investment in a draft would be a poor trade. It falls short on the rest. MCP's authorization spec defines no signed-out session, per-company User ID, human handoff, or session shared across channels, and those gaps remain whatever protocol your customers' agents speak. PACT on A2A also asks for scopes, consent, and discovery of its own, so identity and session work is likely to carry over, whichever design wins.

Adopt, experiment, or wait

For any draft standard, production work waits for stability and a counterpart; cheap, reversible work can start now.

Adopt now when all of these hold

• The spec is stable.
• An official reference implementation is public.
• A personal agent your customers use sends Poppy traffic to services like yours.
• Audit records, fraud review, and a staffed queue are ready for poppy:write actions and handoffs.

As of October 12, 2026, the spec is not stable, no official reference implementation is public, and we found no public evidence of the third.

Run a bounded experiment when these hold

• You already run OAuth with PKCE or a device flow, an MCP server, or a public OpenAPI.
• You see customer agents in your web or support traffic.
• You can cap the work and throw it away, as fillthemat's review capped a proposed spike at one engineer-day or less.
• The scope stays at poppy.json over existing endpoints, signed-out read access, and no new write paths.

Wait when any of these hold

• You have no OAuth-scoped public API yet; build that first.
• No customer agents appear in your web or support traffic.
• Your write actions move money or change accounts, and you have no audit trail for agent actions.

Waiting still leaves protocol-neutral work open: per-agent attribution, short token lifetimes, revocation, and an escalation route to a person.

Risks and open questions

• Protocol churn: draft 0.1 allows breaking changes, so record the protocol_version you implement and budget for rework.
• Identity and authorization: Mediated sign-in uses "credentials the User has given it for this Company." The agent still holds the customer's credentials, though you can now see it is an agent; decide whether to offer it.
• Consent: poppy:write covers "Make changes, such as exchanging an item or updating a booking," so your custom scopes carry the consent design.
• Privacy: check that analytics and fraud tooling never join a signed-out User ID to an identity before sign-in.
• Auditability: the spec defines no audit log, so record agent, User, scope, Session, and action yourself.
• Abuse and fraud: registration, allow and block lists, client_id revocation, and per-client_id rate limits are among the spec's optional controls, so decide what fraud review applies to agent writes.
• Observability and versioning: tag logs and metrics by client_id, and pin community SDK versions in any spike.
• Operational ownership: name owners for the token endpoints, the handoff queue, and poppy.json.
• Fallback to people: customers whose agent fails still need your existing support workflow.

Evaluation checklist

Mark each yes or no for your own API:

1. Your OAuth server supports the authorization code flow with PKCE and the device authorization grant.
2. Your MCP server, if any, acts as an OAuth 2.1 resource server with RFC 9728 metadata.
3. Your API can validate DPoP-bound tokens, or you have sized that work.
4. Your token endpoint can issue a signed-out Session for an agent and a User ID with no personal data.
5. You can identify agents by HTTPS client_id and keep allow and block lists.
6. One revocation signs out every Session tied to an account while carts and conversations continue.
7. A staffed human queue sits behind any agent handoff.
8. Your logs record agent, User, scope, and action for every request.
9. You see customer agents in your traffic today.
10. One named person owns the experiment and tracks the spec.

Yes on 1 or 2, plus 9 and 10, points to an experiment. No on both 1 and 2 points to waiting. Yes across the list, plus a stable spec and an agent counterpart, points to adoption.

---

Sources

• Introducing Personal Agent Protocol, Sierra, October 6, 2026
• Sharing a draft of Personal Agent Protocol, Sierra, October 9, 2026
• Personal Agent Protocol specification, Draft 0.1
• Personal Agent Protocol overview
• MCP specification
• MCP authorization
• A2A protocol specification
• A2A agent discovery
• Linux Foundation announces the Agentic AI Foundation
• A2A joins AAIF
• Introducing PACT, Decagon
• poppy.md comparisons
• poppy.md implementations
• Datalayer Personal Agent Protocol SDK
• orka issue #774
• fillthemat issue #123
• fillthemat issue #173
• OpenAgents issue #11239
• Hacker News discussion
• IETF draft: Private Agent Consent and Trust Profile
• A2A production readiness
• OAuth for AI agents