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):

The draft 0.1 Session lifecycle, condensed.

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.

Criterion	Poppy	MCP	A2A	Status quo: agent passes as the user
Job it owns	Consent and sessions between a personal agent and a company	Connecting LLM applications to external tools and data	Communication between independent, "potentially opaque" agent systems	Finishing a task through pages built for people
Where state lives	A company-side Session per agent and User, signed out or in, shared by API, website, and conversation	Stateless, self-contained JSON-RPC 2.0 requests between host, client, and server; the authorization spec defines no signed-out or cross-channel session	In tasks, with states such as TASK_STATE_COMPLETED	The customer's web session
Who acts for whom	A personal agent for one User, toward one Company	A host's client calling a server, optionally for an OAuth-authorized user	One agent delegating to another	The agent, indistinguishable from the customer
Execution context	Your OpenAPI endpoints, MCP server, website, or company agent	The MCP server's tools	Inside the remote agent	Your website, in a browser
Authorization and control boundary	Direct, Device, or Mediated sign-in; base and custom scopes; key-bound tokens; client_id allow and block lists	Optional; when used, an OAuth 2.1 resource server with RFC 9728 metadata and scope step-up	Agent Card at /.well-known/agent-card.json; a TASK_STATE_AUTH_REQUIRED state	The customer's password
Interoperability	Lists OpenAPI and MCP servers as channels; the spec does not mention A2A	Founding project of the Agentic AI Foundation (December 9, 2025)	Agentic AI Foundation project since August 17, 2026; PACT builds on it	None defined
Fallback path	handoff to a person; revocation drops Sessions to signed out	None in the authorization spec	TASK_STATE_INPUT_REQUIRED marks a task that needs input	The support line or web chat

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.

FAQ

Is Poppy the same as the Personal Agent Protocol?

Yes. The overview says "Personal Agent Protocol (Poppy for short)." Sierra's October 6, 2026 announcement used only the full name; its October 9 post added "known as Poppy."

Who maintains it?

Sierra and Meta develop it with industry partners under the Apache License 2.0. As of October 12, 2026, no editors, governance body, or standards organization appear on the spec site.

Is the spec final?

No. It is draft 0.1, updated October 9, 2026, and any part can change before a stable version, including in ways that are not backward compatible.

Does Poppy replace MCP or A2A?

No. Poppy lists MCP servers and OpenAPI endpoints as channels, so it sits on top of an MCP server you already run. The spec does not mention A2A, and no primary source defines that relationship.

How is it different from PACT?

Decagon's PACT is "Built on the Agent2Agent protocol and OAuth 2.0," and its agents find a business through an A2A Agent Card. Poppy uses poppy.json and routes agents to OpenAPI, MCP, the website, or a company agent. Decagon's PACT is a different document from the IETF individual draft also named PACT (Private Agent Consent and Trust Profile, April 2026); neither references the other.

Is there a reference implementation?

Not an official one as of October 12, 2026. Sierra said on October 9 it would publish one "Over the next month." Independent community SDKs and demos exist.

Should our API support Poppy now?

For most consumer-facing platforms, as of October 12, 2026, run a bounded experiment with signed-out read access and no new write paths, and hold production rollout until the adopt conditions are met.

Run the evaluation checklist against your own API with the draft 0.1 specification open beside it, and record your adopt, experiment, or wait decision with its reasons.