The Personal Agent Protocol (Poppy) is an open protocol, led by Sierra and Meta, that defines how a personal AI agent finds a company, signs a user in, and acts within limits the user and the company both approve — starting with a poppy.json file the company publishes at its own domain. The specification builds on OAuth, JWTs, HTTPS, and OpenAPI or MCP “wherever they fit,” as its introduction puts it.
This page covers the customer-data side of the protocol: what a Poppy session adds to a company’s own records, and what the specification rules out. Nothing here needs a vendor decision today. For marketing, the two parts that matter are the identifier an agent presents and the scope boundary a company draws.
Why the Poppy protocol exists
The protocol’s own introduction describes today’s arrangement as “all or nothing”: the agent passes as the user, with a password and a series of clicks through pages built for people, or the company blocks it. Neither side can set terms. A person cannot limit what the agent does on their behalf, and a company cannot tell an agent from a person or offer it a better path than the human one.
The worked example given there is an airline. Any agent can search flights. An agent that has signed in sees the user’s own trips. Buying requires the user’s approval. Each of those is a different access level, granted to a different party, and the protocol’s job is to make them describable instead of implied.
Two design principles follow. Sierra’s draft announcement states them as “customers decide what access to give their personal agents” and “companies set parameters for what those agents can do” (Sierra, 2026-10-09).
Both leads are commercial parties: Sierra, an AI company, and Meta, which runs its own personal agent. Sierra introduced the protocol on 2026-10-06 with Bret Taylor and Clay Bavor as authors and Genesys, Instinct, Rocket, Shopify, Stripe and Walmart named as co-designers. A draft followed on 2026-10-09, adding 35 design partners, among them OpenAI, Visa, PayPal, Target and Klaviyo. On 2026-11-13 Sierra’s post announced “1.0”, describing five weeks of design-partner testing, 60 more companies, and “more than 100” design partners in total.
How the Personal Agent Protocol works: discovery, sessions, sign-in, channels
A company’s participation is a file, not an integration project. The specification requires the company to publish https://{domain}/.well-known/poppy.json over HTTPS, describing its sign-in, agent endpoints, APIs, web surfaces, tasks and extensions (specification §3). The rest of the protocol is layered on top of that file, and every step assumes two parties: the AI agent acting for one person, and the company setting the terms.
| Layer | What the specification defines | Source |
|---|---|---|
| Discovery | A poppy.json file at a fixed well-known path over HTTPS, publishing sign-in, endpoints, APIs, web, tasks and extensions | spec §3 |
| Sessions | Every request carries a Poppy-Session header — a JWT the personal agent signs per request, naming the Session and the User ID. The company verifies it before trusting the Session’s claims. Sessions work signed out | spec §5 |
| Sign-in | Standard OAuth: Direct Sign-In (authorization code with PKCE on the company’s page) and Device Sign-In (a code plus the company’s page). Mediated Sign-In is a transitional extension | spec §4; roadmap |
| Channels | One Session covers the website, the APIs, and the company’s own agent | Sierra, 2026-10-09 |
| Execution | The company chooses the surface: its website (the agent browses, and the browser joins the Session by one-time code plus a company cookie, with the access token never passing through the browser), its APIs over OpenAPI or MCP, or its own agent through a conversation endpoint | spec §6-8 |
Three smaller mechanisms sit around that flow. tasks and excluded_tasks tell an agent what the company does not offer through its interfaces, skill_index publishes Agent Skills, and a feedback endpoint lets agents report tasks they could not complete (spec §9). The specification’s security section works through content from companies treated as untrusted for prompt injection, secrets and the model, what a domain does and does not vouch for, token and assertion audiences, joining a browser to a Session, delegated keys, and sign-ins that someone else started (spec §10).
Extensions in the 1.0 draft
Supporting an extension is optional, and the six below ship with the draft (extensions):
| Extension | What it adds |
|---|---|
browser-control | The company marks steps on its site the user should take; the personal agent hands the user control |
disclosures | The company marks notices such as allergen warnings apart from message text |
links | Company messages carry referenced web pages as links |
mediated-sign-in | Transitional: the agent signs in with credentials the user gave it, at companies without Direct or Device Sign-In |
operations (v3) | The user, or the agent on the user’s instruction, approves exact terms; a retry never performs the operation twice |
ucp | The company speaks UCP: Poppy finds it and signs the user in, and shopping happens through UCP |
For a company that sells regulated or safety-relevant goods, disclosures is the row to note: it is how an allergen or safety notice stays distinct from message text. Naming is governed too: plain names are reserved for extensions defined on the protocol site, and third parties use a domain they control, as in example.com/gift-wrap.
AI agent identity: what the Personal Agent Protocol assigns
Poppy defines AI agent identity as a per-company User ID that the agent mints and presents in a signed JWT: stable inside one company, opaque across companies. The specification defines a User ID as “the ID a Personal Agent gives one User at one Company,” and then constrains it in three sentences that carry the whole design:
It is stable, so the Company recognizes the User across Sessions even when they’re signed out. It is opaque and different at each Company, so Companies can’t match Users with each other. (spec §2, §5.1)
The personal agent assigns that ID, the role an OpenID Connect server would take. It must not “contain or be derived from personal information,” which the specification says covers name, email and phone, and even keyed hashes of them. The agent is responsible for protecting its own ID mappings. Signed out, the specification calls the state pseudonymous: “The Company recognizes the User by User ID but doesn’t know who they are.” Sign-in is the user’s approval of the agent’s access; sign-out revokes the refresh token, and Sessions continue afterward. Stable has a condition: User IDs belong to the company’s identifier, so adding or changing an issuer can change it, and personal agents must then use new User IDs (spec §3.2). A domain or identity-provider migration can reset recognition.
In cdp.com’s reading, those constraints invert the usual arrangement. Customer identifiers are normally minted inside the company (a cookie, an account number, a hashed email) and matched outward. Poppy’s identifier is minted outside the boundary and presented inward, on terms the company did not write. “Different at each Company” is stated as a requirement, not a default setting.
Scopes and scope_hints: the consent surface the spec actually defines
Access is described per company. Each company defines its own scopes, with orders:read, orders:write and addresses as the specification’s examples, while the protocol itself defines exactly one, poppy:browser-sign-in (spec §4). A company should describe what each scope opens and whether a task can be completed without it.
Hints are optional per scope: a company may publish an auth.scope_hints entry for any scope, and when it does, the specification requires both fields below. Each entry describes the most consequential action the scope permits, and a scope with no entry carries no hints at all:
| Field | Values | What it asserts |
|---|---|---|
changes | none, reversible, irreversible | Whether the actions under this scope change anything, and whether a change can be undone |
personal_data | true, false | Whether any action under this scope shows or changes personal data such as contact details, addresses or payment methods |
These are the company’s own claims about blast radius. The specification is explicit that they are not proof of user approval — approval is the user granting scopes in the Direct or Device flow, and a company cannot grant itself more scopes than were requested.
What Poppy means for CDPs and first-party data (cdp.com analysis)
Everything in this section is cdp.com’s reading of the specification. It is not a claim the protocol makes, and it is not a prediction about any vendor’s roadmap.
The agent ID is one more identifier inside your own boundary
A company that runs identity resolution already holds cookies, account numbers, device graphs and hashed emails. A Poppy User ID joins that set as an identifier the company can store and key against, and it lives inside the same boundary as everything else — the specification requires it to be different at each company, so it never functions as a shared key across them. For first-party data, that is the conservative outcome: a new, stable, pseudonymous identifier that does not leak identity to anyone else.
The link to a named customer runs through sign-in, not through the ID
Before sign-in, a company has a returning pseudonymous user it can recognize but cannot name. The ID becomes a person’s record only when that person signs in and the company learns who they are. The practical consequence is a two-state profile: recognized-but-anonymous, and recognized-and-identified. Any system that assumes the second state as the baseline — personalization by name, profile merges keyed on email — has to handle the first state as a legitimate, persistent one rather than a temporary gap.
Cross-company matching is ruled out on purpose
“Companies can’t match Users with each other” means the agent-issued ID cannot serve as a shared key across companies, the role third-party cookies played. Stitching still happens inside each company’s own graph, from that company’s own signals. The only party that holds the cross-company mapping is the personal agent, which the specification says must keep it confidential (spec §5.1), so cross-brand resolution moves outside your perimeter rather than disappearing.
Scopes cap what an agent can read or change, not what you may retain
The scope list and its scope_hints describe an agent’s permissions. They say nothing about retention or downstream sharing, and none of the specification’s sections sets retention rules, which leaves both to the company and its privacy obligations. The closest familiar structure is consent management: a recorded grant, tied to defined purposes, revocable. A scope grant is a permission, though, not volunteered information: closer to zero-party data in spirit than in mechanism, because the user is opening a door rather than filling in a form.
Personalization appears in the spec once, as a scope description
The specification’s only mention of personalization is an example of how a company might describe a scope: one “that only personalizes search results” (spec §4.7). None of the specification’s eleven sections covers profile schemas, segments or activation. What that implies for AI personalization is narrow and worth stating plainly: Poppy changes how a request arrives and what it is allowed to touch. In practice, a returning visitor can be recognized and personalized for without being named, and the named experience begins at sign-in; campaign logic keyed on email or a known profile has to treat the pseudonymous state as a permanent segment, not a temporary gap. What the company does with the data afterward, whether unifying it, scoring it or deciding with it, remains outside the protocol’s scope.
That leftover work is where a customer data platform still sits. An agentic CDP exposes the profiles it holds to agents through APIs and MCP servers rather than through pages built for people. Poppy describes how an agent arrives and what it may do; the platform decides what profile data sits behind those APIs.
Poppy vs UCP vs MCP and OpenAPI
The protocols people conflate with Poppy do different jobs. UCP is the agentic commerce protocol; in Sierra’s framing, Poppy is the layer that runs before a single product is searched.
| Protocol | What it covers | Relationship to Poppy |
|---|---|---|
| Poppy | Who the agent is, which company it is visiting, who the user is pseudonymously, and what the agent may do there | The entry layer: discovery, session, sign-in, scopes |
| UCP | “How an agent discovers what a business offers, searches its catalog, builds a cart, completes a checkout with a negotiated payment handler, follows an order, and asks the business questions” (UCP extension) | Poppy’s ucp extension finds the company and signs the user in; shopping happens through UCP |
| MCP and OpenAPI | The API surfaces a company lists for agents in its poppy.json | Channels Poppy points to; it does not replace them (spec §7) |
Sierra draws the same line in one sentence: “UCP handles the shopping itself, like finding products, filling a cart, and checking out. Poppy handles what happens before that, when an agent shows up at a store, says who it is, and finds out what it’s allowed to do” (Sierra, 2026-11-13). Sierra’s post says Shopify co-authored the commerce extension, and the UCP extension page maps UCP’s Business, Platform and Buyer roles onto Poppy’s Company, Personal Agent and User.
Poppy contains no payment specification. The roadmap says payments should use “existing payment and checkout protocols rather than replacing them” (roadmap).
Status: announced as 1.0, still labelled draft 1.0
Sierra’s post announced “1.0” on 2026-11-13. The specification text was still labelled draft 1.0 on that date, in its own words: “This is draft version 1.0. It starts from 0.4, the 1.0 release candidate, and adds fixes for problems implementers find, which can include changes that aren’t backward compatible” (specification). The project’s path-to-1.0 page, updated 2026-11-11, tells implementers to “build against the 1.0 draft” and says no new features are being added until 1.0 is published, while fixes before that point “can still break compatibility with earlier versions” (path to 1.0).
Three cautions are worth carrying into any planning document. The Agentic Commerce Atlas, an independent publication, notes that no neutral standards organization is named, that partner participation does not mean a product has shipped, and that “it is not a payment or checkout protocol” (Agentic Commerce Atlas, 2026-11-02). The specification and documentation are under the Apache License 2.0, which does not cover the names “Personal Agent Protocol” and “Poppy”, the logo, or the site design, and the repository states no governance model (repository).
What is live, as of the 1.0 post: Shopify made Poppy available to every merchant, whose stores now “automatically publish a Poppy file” without merchant implementation, and Shopify serves businesses in “more than 175 countries” (Sierra, 2026-11-13). Meta’s Muse checks Poppy first on every site. Mercury and Turkish Airlines are the two companies the post describes as working: Mercury checking agent requests against an account’s approval policy before sending money, Turkish Airlines retrieving bookings by reference and surname and searching Miles&Smiles upgrades with approval before payment. Synchrony is described as exploring how an agent could help customers find the right product (Sierra, 2026-11-13). Muse’s own announcement describes a personal agent rolling out in the US on iOS, Android and muse.ai, and states that “each person stays in control of their Muse and decides how much access it gets,” that it “checks with the person before sensitive actions like sending an email or making a purchase,” and that it “shows people a complete audit trail of everything it has done and plans to do” (Meta, Muse). That page does not itself mention Poppy; the connection is Sierra’s.
The named design partners are a longer list than the live examples, and the two should not be merged. Braze, Klaviyo, Salesforce, Zendesk, Okta, Ping Identity, Persona, Socure, Fullstory and Twilio all appear in Sierra’s October and November partner lists; only the examples above are described as working.
The roadmap, which it describes as “direction, not dates or promises,” lists work still open: payments tied to approved operations, push notifications (today an agent learns of a change only by checking again), attachments, signed approvals and mandates — a “transfers of up to $50 a week” limit is the example given, self-hosted personal agents, and dropping Mediated Sign-In (roadmap).
What marketing and data teams should do now (cdp.com’s view)
This is advice, not a claim about the protocol. None of it requires a vendor decision today.
- Decide what an agent may see of your loyalty and CRM benefits. Scopes are company-defined, so the boundary is yours to draw: order history yes, full profile no, points balance read-only. Write it down before an agent asks.
- Find out who owns your
poppy.json. Discovery is how an agent learns what you allow: a file at a fixed path, served over HTTPS. Shopify merchants get one published automatically; on any other stack, ask your platform team whether and when one will exist, and who decides its contents. - Design your scope taxonomy before you need it. Scopes are company-defined, so their granularity becomes your consent surface by default.
orders:readandorders:writeare a reasonable start; the question to answer is what you would refuse an agent, and whether you can express that as a scope. - Treat
scope_hintsas claims you will be held to. The specification makeschangesandpersonal_datathe company’s own statements about each scope, so nobody else will check them. Mark them from what the scope’s actions really do. - Keep the agent ID inside your own identity graph. It is stable only while your company’s identifier is unchanged and pseudonymous, which makes it useful for recognition and useless as a cross-company key. Plan the merge logic for the recognized-but-anonymous state before you plan anything else.
- Watch the draft, not the announcement. Payments, push notifications and mandates are on the roadmap rather than in the specification, and the spec text still says draft 1.0. Build against what is written, and expect compatibility fixes.
FAQ
What is the Personal Agent Protocol?
The Personal Agent Protocol (Poppy) is an open protocol for how personal AI agents and companies work together. A company declares its agent-facing interfaces in a poppy.json file, a personal agent signs a user in through OAuth, and the company grants scopes that limit what the agent can read or change. Sierra and Meta lead it, and Sierra described more than 100 design partners in its 2026-11-13 announcement.
Is Poppy the same as MCP or UCP?
No — the three do different jobs. UCP covers shopping: catalogs, carts, checkout and order tracking. MCP and OpenAPI are the API surfaces a company lists for agents to call. Poppy sits in front of both: it finds the company, identifies the agent and a pseudonymous user, signs that user in, and establishes what the agent is allowed to do before any shopping or API call happens.
Does Poppy let companies identify customers across brands?
No — not through the protocol. The specification requires the User ID to be opaque and different at each company, so two companies cannot match users by comparing IDs. Within one company, the ID is stable and survives signed-out sessions, which lets that company recognize a returning user. Stitching across brands remains the company’s own work, done on its own data.
Is Poppy a finished standard?
Not yet. Sierra’s post announced “1.0” on 2026-11-13, but the specification page still calls itself draft version 1.0 and warns that fixes can include changes that are not backward compatible. The project’s path-to-1.0 page says no new features are being added until 1.0 is published. No neutral standards organization is named, and a named design partner is not a shipped integration.
What is poppy.json and who publishes it?
It is the company’s declaration file, published by the company itself at https://{domain}/.well-known/poppy.json over HTTPS. It describes the sign-in methods the company supports, its agent and API endpoints, its web surfaces, the tasks it offers and the extensions it implements. Agents read it to learn how to interact. The specification makes serving it a requirement for participating in the protocol.
Does Poppy replace a customer data platform?
No — it changes where requests come from and what they may touch. The protocol defines discovery, sessions, sign-in and scopes, and none of its sections covers profile unification, segmentation or activation. Those remain the company’s systems. In practice a Poppy session produces one more identifier and a recorded permission, both of which belong in the same customer data infrastructure as everything else.
Related Terms
- Agentic Commerce — The agent-as-buyer model that Poppy’s UCP extension plugs into once identity and sign-in are settled
- AI Agent — The software actor that acts for one person under Poppy’s scoped access
- Consent Management — The discipline of recording and enforcing permission grants, which is the closest analogue to Poppy’s scopes
- Zero-Party Data — Data a customer deliberately shares, the framing a scope grant resembles but does not match
- AI Personalization — The downstream use of customer data that Poppy constrains without defining