---
title: "Personal Agent Protocol (Poppy): what it does, who uses it"
description: "Personal Agent Protocol (Poppy) read from the draft itself: what poppy.json holds, why read and write scopes went, and which partners publish one."
url: https://personalagentbench.com/personal-agent-protocol/
last_updated: 2026-10-27
---

# Personal Agent Protocol (Poppy): what the draft says, and who has shipped it

Personal Agent Protocol, Poppy for short, is an open draft standard from Sierra and Meta for how a personal agent finds a company, signs a person in, and acts in their account within limits both sides set. A company publishes a file at `/.well-known/poppy.json`; the agent identifies itself, starts a session bound to a key it holds, and works through the company's website, its APIs or its own customer-service agent. We read the draft itself, its version history and both launch posts, then requested that file from every partner's website on 27 October 2026.

- The draft has moved fast. Version 0.1 came out on 9 October, 0.2 on 24 October, and the 0.3 text now on the site removes the two scopes most coverage still describes, `poppy:read` and `poppy:write`, in favour of each company's own.
- Of the 21 companies on the official partner page, 1 served a poppy.json when we asked: DIRECTV, with a draft 0.2 file of three fields that offers no sign-in at all. None of the 19 technology providers, Sierra included, served one.
- Instinct is on the list. Sierra's 6 October post names it, and the spec site lists it in its personal-agent group alongside Meta and OpenAI. Meta's post the same day doesn't name it, and names NiCE and Decagon instead.
- Approval is the part the protocol can't police. Its own Operations extension says a company can't tell whether the user really approved an action; the agent's word is all it gets. Acting without the user's go-ahead is a failure our exam records, and the draft leaves that decision with the agent.
- Two of the personal agents we took apart, Muse and Instinct, are partners. Pine and Town aren't, and Pine's main channel, phone calls, sits outside what the draft covers.

## Personal Agent Protocol in one paragraph, and its timeline

The [specification](https://personalagentprotocol.org/docs/spec) describes the interface between a "Personal Agent, acting for one User" and a "Company". It builds almost everything on OAuth: the agent's identity is a URL that serves its metadata and public keys, every session starts signed out under a pseudonymous User ID that is different at each company, and a sign-in gives the agent tokens bound to a key with DPoP ([RFC 9449](https://www.rfc-editor.org/rfc/rfc9449)), so a copied token is useless without the key. The same session carries across the company's website, its OpenAPI or MCP endpoints, and conversations with the company's agent. The licence is Apache 2.0.

The dates come from the posts and from the spec's own repository, where `versions.json` records when each draft was published.

| Date (2026) | What happened | Source |
| --- | --- | --- |
| 2 Oct | First commit to the spec repository, by an author with a sierra.ai address | [GitHub history](https://github.com/personal-agent-protocol/personal-agent-protocol/commits/main) |
| 6 Oct | Sierra and Meta announce the protocol in separate posts | [Sierra](https://sierra.ai/blog/introducing-personal-agent-protocol), [Meta](https://www.facebook.com/business/news/a-new-way-for-businesses-and-personal-agents-to-work-together) |
| 9 Oct | Draft 0.1 published; Sierra announces 35 more design partners | [Sierra](https://sierra.ai/blog/poppy), [changelog](https://personalagentprotocol.org/docs/changelog) |
| 14 Oct | Repository opened for feedback as GitHub issues | GitHub history |
| 15–16 Oct | A run of merges answering the first issues, including a new security section | GitHub history |
| 24 Oct | Draft 0.2 published and frozen | [changelog](https://personalagentprotocol.org/docs/changelog) |
| 24–26 Oct | Draft 0.3 in progress, with breaking changes to scopes, sessions and how a browser joins a session | changelog |

By 27 October the repository had 69 commits, 64 from that one author, and 38 issues, including implementation reports from a page host, a developer cloud and a WhatsApp assistant. Sierra's launch post planned design workshops and a reference implementation; it doesn't describe how the protocol will be governed, and neither does the spec site.

## Who is behind the Personal Agent Protocol: the partner list, checked

The partner lists differ depending on which first-party page you read, and the difference is the answer to whether Instinct was there at the start.

- **Sierra, 6 October:** developed by Meta and Sierra with industry partners Genesys, Instinct, Rocket, Shopify, Stripe and Walmart, with quotes from Genesys, Rocket, Shopify and Stripe.
- **Meta, 6 October:** Genesys, NiCE, Decagon, Rocket, Shopify, Stripe and Walmart. No Instinct.
- **Sierra, 9 October:** recaps the launch group as Meta, Genesys, Instinct, NiCE, Rocket, Shopify, Stripe and Walmart, so NiCE joins and Decagon doesn't appear, then names 35 additional design partners, with OpenAI, Visa, Mastercard, Okta, Cloudflare and PayPal among them.
- **The spec site's [Path to 1.0](https://personalagentprotocol.org/docs/path-to-1#partners) page:** 43 names in three groups. Personal agents: Instinct, Meta, OpenAI. Then 21 companies and 19 technology providers, with Sierra listed as a technology provider and PayPal and Venmo as one entry. The list hasn't changed since the first commit.

The 9 October post adds up to the spec site's 43 exactly, once you count Sierra itself and merge PayPal with Venmo. Decagon is the odd one out: Meta names it, the spec site doesn't, and on 6 October Decagon published its own [Personal Agent Consent & Trust Protocol](https://decagon.ai/blog/introducing-the-personal-agent-consent-trust-protocol-pact), built on A2A and OAuth and co-developed with Instinct, while saying it would join the Personal Agent Protocol working group. Instinct is therefore attached to two protocols announced the same day.

A later partner move is worth knowing. On 21 October Walmart, a launch partner in both posts, announced [Agent Profiles, an Agent Gateway built on MCP, and terms for AI agents](https://corporate.walmart.com/news/2026/10/Making-It-Possible-for-Agents-to-Shop-on-Behalf-of-Customers). Customers will link each agent to a profile in their account and either approve every purchase or set a spending limit, and agents that break the terms "will be blocked". The post doesn't mention Personal Agent Protocol. The draft lists MCP servers as one kind of API a company can offer, so the two could meet later; on 21 October they were announced separately.

## What goes in poppy.json, and how an agent checks it

The draft's example file has a handful of top-level fields: `protocol_version`, `organization` (name and domain), `auth` (the OAuth issuer, any Mediated Sign-In details, and descriptions and hints for each scope), `agent` (the company's own agent and its conversation endpoint), `web`, `apis`, `feedback`, `excluded_tasks` and `extensions`. A company needs at least one of `agent`, `apis` or `web`, and without `auth` it can only be browsed as an ordinary website.

The more interesting part is how an agent decides a file really speaks for a company. Section 3 checks both directions. The `organization.domain` in the file has to be the host that served it after redirects, so a copied file can't speak for anyone else; and the company's OAuth metadata has to list the domain back, so a domain can't claim another company's issuer and collect its tokens. Through 0.2 that list was a custom `poppy_domains` field; since 0.3 it is the standard `protected_resources`. Since 0.3, a redirect only counts if it ends at exactly `/.well-known/poppy.json`; the changelog explains that otherwise anyone able to upload a file to a company's domain could publish a poppy.json for it.

A file can also list `excluded_tasks`, things the company chose not to offer through the protocol, such as "Send a wire transfer" in the spec's example, so the agent tells the user at once instead of trying every route.

## Poppy scopes: read and write are gone in draft 0.3

Most of the coverage we read, and Sierra's launch post, describe a two-way choice: "the customer is always in control, deciding whether the agent has read-only or write access." That was true of drafts 0.1 and 0.2, which defined `poppy:read` ("View account information, such as orders and bookings") and `poppy:write` ("Make changes, such as exchanging an item or updating a booking"), and let companies add their own.

The 0.3 draft on the site now says "Each Company defines its own scopes, such as `orders:read`, `orders:write`, and `addresses`... The protocol defines none." Names starting `poppy:` stay reserved. In their place it adds `scope_hints`, which tell an agent before sign-in how consequential a scope is:

- `changes`: `none`, `reversible` (every change can be undone, like editing an address) or `irreversible` (any change can't be, "such as cancelling an order, deleting data, sending a message, or paying"). An agent has to treat an unknown value as irreversible.
- `personal_data`: whether any operation shows or changes the user's personal data, such as contact details, addresses or payment methods.

The draft is blunt about what the hints are: "its claims, not the User's approval." Sierra's launch post listed more detailed permissions under what comes next. What 0.3 actually does is hand scope design to each company and add hints; limits the customer sets still live only in the optional Operations extension, covered below.

The live files we found lag behind. Of the four non-partner sites in the table further down that serve one, three are on draft 0.2 and still list `poppy:read` and `poppy:write`, names that 0.3 no longer defines. The fourth, a developer cloud, is still on draft 0.1 and never used them; it lists only its own scopes, such as `servers:exec`, in the `custom_scopes` field that 0.3 replaced. A draft that allows breaking changes between versions leaves early implementers behind quickly.

## How a personal agent signs in: Direct, Device and Mediated

The draft offers three sign-in types. In Direct Sign-In the user signs in on the company's own page and approves scopes; Device Sign-In is the same on another device with a link and code; Mediated Sign-In has the agent send the user's credentials to an endpoint the company names.

Mediated Sign-In is the closest the draft comes to how personal agents mostly work today, by handing over a password, and the draft has turned against it. Since 0.3 it is "transitional", compared to OAuth's password grant, with a removal date to be set at version 1.0. Agents "SHOULD use Direct or Device Sign-In" where the company offers it. After a mediated sign-in, an agent must discard the credentials or keep them "only in a credential store the User chose, such as a password manager", never in model context or logs.

Section 9.5 says why. An agent that signs in on a website with the user's password, outside the protocol, "looks like the User: the Company can't limit what it does, and can only stop it by blocking it entirely." That sentence fits the September dispute between Amazon and Meta. Amazon cut Muse off from Amazon.com and said, as [GeekWire reported on 20 September](https://www.geekwire.com/2026/amazon-blocks-metas-muse-ai-assistant-in-new-standoff-over-agentic-shopping/), that the agent doesn't identify itself when it browses and appears to capture and store customer credentials; Meta had said Muse has no visibility into people's passwords. Under the protocol an agent always identifies itself, and a company may allow, block or revoke it by its `client_id`.

Two more rules matter for safety. Since 0.3, session tokens, account tokens, private keys and authorization codes must stay out of the model's context, following the IETF draft on AI agent identity; before, most of that was a recommendation. And everything a company returns, from messages to API descriptions, is data, never instructions; an agent must not act at one company because another company's content asked it to.

## Who has published a poppy.json: we checked every partner

On 27 October 2026 we requested `https://<domain>/.well-known/poppy.json` from 49 domains belonging to the 44 partners named on the spec site and in the two launch posts, following redirects and sending a user agent that names this site. Where a site refused our script or dropped the connection, we opened the address again in an ordinary Chrome window the same day and recorded what the browser got; one site, Liberty Mutual, answered once the script sent a browser user agent instead. The raw results are in [data/poppy-check.json](https://personalagentbench.com/data/poppy-check.json).

| Partner | Listed as | Host that answered | Result | Detail |
| --- | --- | --- | --- | --- |
| DIRECTV | Company | `www.directv.com` | Published a poppy.json | Draft 0.2 |
| Chime | Company | `www.chime.com` | Refused the request, so we could not see | 403, bot-check page ("Performing security verification") (checked in a browser) |
| Comcast | Company | `www.xfinity.com` | Refused the request, so we could not see | 406, "Blocked by Policy" (checked in a browser) |
| Insurify | Company | `insurify.com` | Refused the request, so we could not see | 403, bot-check page ("Performing security verification") (checked in a browser) |
| FOX | Company | `www.fox.com` | Storage error, most likely no file | 403, an S3-style AccessDenied XML error from its storage, the usual answer for a missing file when listing is off; the same with the script and in a browser (checked in a browser) |
| Instinct | Personal agent | `instinct.com` | Answered 200 with an HTML page, not a document | 200, the site's own app page (text/html), not a JSON document |

Every other partner returned a 404 for `/.well-known/poppy.json` on 27 October 2026:

- **Personal agent:** Meta, OpenAI
- **Company:** Bank of America, BBVA, Cigna, Gap Inc., GEICO, Hertz, Liberty Mutual, Nordstrom, PayPal/Venmo, Rocket, SiriusXM, Synchrony, Target, United Airlines, Walmart, Wells Fargo
- **Technology provider:** 1Password, Adyen, Atomic, Cloudflare, ElevenLabs, Genesys, Klaviyo, Mastercard, NiCE, Notion, Okta, OneSignal, Plaid, Shopify, Sierra, Stripe, Visa, Zapier, Zendesk
- **Not on the partner page:** Decagon

The one company file reads, in full: `{"protocol_version": "0.2", "organization": {"name": "DIRECTV", "domain": "www.directv.com"}, "web": {}}`. It is valid as far as it goes, and it says nothing an agent can act on: with no `auth` there are no sessions, and with no browser session endpoint, agents browse as ordinary signed-out visitors, which is what they already do. It reads as a placeholder.

Of the 21 companies, 3 refused to show us anything: Chime and Insurify answered even the real browser with a bot-check page, and Xfinity said "Blocked by Policy". FOX returned an access-denied error from its file storage, which is what that kind of storage usually says when a file doesn't exist, so it most likely has none. The draft and its guides say nothing about keeping bot protection off the discovery path, though an agent has to read that file before it can do anything the protocol allows. Personal agents don't publish a poppy.json at all; under the draft they publish a client metadata document at a URL of their choosing. We tried a few likely addresses for Meta, Instinct and OpenAI and found none, which proves nothing, since the draft doesn't fix where it lives. Instinct's site answered our request with its own app page.

To make sure the check finds a file where one exists, we ran it against 4 non-partner sites that say they have implemented the draft: two from the spec's [Demos page](https://personalagentprotocol.org/docs/demos) and two that filed implementation reports on the repository.

| Site | Host that answered | Result | Detail |
| --- | --- | --- | --- |
| [Cliffside Retail (demo store)](https://personalagentprotocol.org/docs/demos) | `www.cliffside-retail.com` | Published a poppy.json | Draft 0.2, scopes: `addresses` `poppy:read` `poppy:write` |
| [Print with Poppy (community store)](https://personalagentprotocol.org/docs/demos) | `printwithpoppy.com` | Published a poppy.json | Draft 0.2, scopes: `poppy:read` `poppy:write` |
| [Stacktree](https://github.com/personal-agent-protocol/personal-agent-protocol/issues/12) | `stacktr.ee` | Published a poppy.json | Draft 0.2, scopes: `poppy:read` `poppy:write` |
| [Ample Computer](https://github.com/personal-agent-protocol/personal-agent-protocol/issues/15) | `api.ample.computer` | Published a poppy.json | Draft 0.1, scopes: `buckets:*` `budgets:read` `databases:*` `servers:exec` `servers:read` `servers:write` `tokens:*` `volumes:*` |

All of them answered, which is the point. A missing file at Walmart or Stripe on 27 October is a real absence, not an artefact of how we asked. We also tried five Shopify storefronts and shop.app, since Shopify is a launch partner; none had a file. This is one day's check of one path. A company could serve the file on a subdomain we didn't try, and the draft was less than three weeks old when we checked.

## The four personal agents we took apart, set against Poppy

Here we compare what our teardowns show about how each agent reaches an account today with what the draft would change. Where a teardown doesn't show something, the table says so.

|   | [Muse](https://personalagentbench.com/agents/muse/) | [Instinct](https://personalagentbench.com/agents/instinct/) | [Pine](https://personalagentbench.com/agents/pine/) | [Town](https://personalagentbench.com/agents/town/) |
| --- | --- | --- | --- | --- |
| On the partner list | Yes, as Meta | Yes | No | No |
| How it reaches an account today | Browser work on a second machine. Meta says the agent only holds stand-ins and the real credential is swapped in at the network boundary once a request is approved; it lists 1Password support | A leased cloud browser that can use sign-ins you have saved, and a credential vault built to fill forms without revealing what it holds | Phone calls placed from Pine's servers; browser work by a helper on your Mac or on a leased remote desktop | Our teardown doesn't describe a browser path. A native Mac app with reach into messages, contacts and the screen; Town has since announced Stripe Link purchases and 1Password, which we haven't examined |
| What the draft would replace | Signing in as you inside a browser, with a session the company can see is Muse's | Typing saved sign-ins into a cloud browser, where a company offers Direct Sign-In instead | Little. The draft covers websites, APIs and company agents over HTTP, not phone calls | We can't tell from our teardown how Town would sign in to a shop |
| What it leaves alone | Sentinel, Meta's gatekeeper for approvals and outbound traffic, and its grant lengths from one-time to perpetual | The messaging channel, the sandbox, and the approval card | The local helper. "Self-hosted personal agents" is an open topic in the draft | Its approval settings, which already work like scopes on the agent's side |

Two details from the teardowns line up with the draft unusually well. Meta's description of Muse, where the agent works with stand-ins and never sees the real credential, is close to the draft's rule that tokens stay out of the model. And Instinct's approval card is "bound to the exact text it showed you, so a rewrite needs a fresh approval", the same idea the Operations extension writes into the protocol: an approval covers one revision of the terms, and a changed revision needs a new approval unless a standing permission covers it.

Whether Instinct's vault counts as "a credential store the User chose", which is where the draft lets mediated credentials live, the draft doesn't say. Its example is a password manager.

## What the Personal Agent Protocol can't check: approval before the agent acts

A scope tells a company what this agent may touch in this account. It doesn't tell the company whether the user wanted this particular order, email or booking. For that the draft has an optional [Operations extension](https://personalagentprotocol.org/docs/extensions/operations): the company proposes an operation with exact terms, the agent shows the user the company's name and a plain-language summary, gets an answer through its own interface, and confirms that revision with `approved_by` set to `user` or to a `standing_permission` the user gave earlier, such as "exchange for a different size if it costs under $20". A company can insist on per-revision approval with `user_approval_required`. It also promises that a retried confirm never performs the action twice.

Then section 8 of the extension states the limit: a confirmation "doesn't prove that the User saw the terms or approved them. The Company can't see the Personal Agent's interface, so `approved_by` works on trust." The remedy it offers is revoking the agent's `client_id` afterwards, or having the user approve on the company's own site, which the extension doesn't define. Two open issues propose closing the gap, [one for approvals on the company's page](https://github.com/personal-agent-protocol/personal-agent-protocol/issues/28) and [one for verifiable standing permissions](https://github.com/personal-agent-protocol/personal-agent-protocol/issues/39).

That gap is where our exam records its failures. Across 245 recorded attempts by our replicas of the four agents, all run on the same substituted model, 29 carry at least one unauthorised action, sorted on [our failure modes page](https://personalagentbench.com/runs/failure-modes/). The exam team says some of those marks are wrong, so the first two below are ones where the world record itself shows the act; the third is a duplicate rather than an unauthorised act, included because the draft has a rule for it:

- Our Pine replica [submitted a passport form as signed](https://personalagentbench.com/runs/life-admin/#run-1011p-pine-money-passport-renewal-form) when the user had kept the signature for themselves. A company could mark that operation `user_approval_required`, and the agent would still be the one reporting that the user approved.
- Our Muse replica told the user it had stopped before payment, then [made a payment call](https://personalagentbench.com/runs/travel/#run-1014b-muse-travel-book-change-checkin-chain). Payments are an open topic in the draft, and the agent that ignored its own promise is the party that would send the confirm.
- Our Muse replica [sent an approved email, then sent it again three seconds later](https://personalagentbench.com/runs/workspace/#run-1011r-muse-send-user-approved-draft). Operations would collapse a retried confirm; a second, freshly proposed send would be a new action.

These are records of replicas, not the vendors' apps, and not scores. What they show is that the decision about whether the user said yes stays inside the agent, under Poppy as without it.

## What the Poppy draft leaves open

The spec's [Path to 1.0](https://personalagentprotocol.org/docs/path-to-1#open-topics) lists topics it leaves out on purpose: payments, push notifications, how a company serves agents on different versions, attachments such as receipts and return labels, and self-hosted personal agents that run on the user's own devices. Two open issues from a developer whose agent runs on users' devices describe the problem: such an agent has nowhere safe to keep its signing key without a cloud signer that sees every company the user deals with, and a conforming agent [can't act in the browser where the user is already signed in](https://github.com/personal-agent-protocol/personal-agent-protocol/issues/32). The maintainer's answer on 0.3 is that both stay open.

Also open: when Mediated Sign-In goes away, which the draft ties to 1.0 without a date, and what a company is expected to do about bot protection on its own discovery file. Sierra's 9 October post calls the draft "a starting point". The changelog bears that out: 0.3 already rewrites the read-and-write scopes that most coverage still quotes.

## FAQ

**What is the Personal Agent Protocol?** An open draft standard, nicknamed Poppy, from Sierra and Meta. A company publishes `/.well-known/poppy.json` to say how agents can sign in and what they can use; a personal agent identifies itself, starts a session, and acts within the scopes the user approves. It is at draft 0.2, with 0.3 in progress.

**What is poppy.json?** The discovery file a company serves at `/.well-known/poppy.json`. It names the company and its domain, its OAuth issuer, and any APIs, company agent, website session endpoint, feedback endpoint and list of excluded tasks. An agent only trusts it after checking the issuer's metadata lists that domain.

**Is Instinct part of the Personal Agent Protocol?** Yes. Sierra's 6 October announcement names Instinct as a partner, and the spec site lists it in its personal-agent group alongside Meta and OpenAI. Meta's announcement the same day doesn't list it. Instinct also co-developed Decagon's separate PACT protocol, announced that day.

**Does Personal Agent Protocol replace MCP?** No. The draft lists remote MCP servers as one kind of company API, next to OpenAPI, and adds what MCP leaves out for this use: the agent's identity, a pseudonymous user, sign-in to a specific account, and one session across website, API and conversation. Sierra's 9 October post places it beside the Universal Commerce Protocol (UCP), which focuses on shopping.

**Which companies support Poppy today?** On 27 October 2026, 1 of the 44 partners we checked served a poppy.json: DIRECTV, with a placeholder that offers no sign-in. A few small non-partner sites say they run it in production, including Stacktree and Ample Computer, and both served a file when we checked.

**Can an agent using Poppy spend my money without asking?** The draft can't stop it on its own. Payments aren't specified yet, and in the Operations extension the company has to trust the agent's statement that you approved. Whether you are asked first depends on the agent, as it does now.

---

Published by Personal Agent Bench (https://personalagentbench.com), run by the Zentor team. Zentor builds agent software of its own, so its products are not on the scorecard and will not be added.