Personal Agent Protocol: How to Prepare Your Site for poppy.json

On October 6, Sierra and Meta announced the Personal Agent Protocol, nicknamed "Poppy", an open standard for how a customer's own AI agent identifies itself to a business, signs in and gets permission to act. A draft spec followed within days, and the project site now shows Draft 0.2 with design partners that include OpenAI, Shopify, Stripe, Walmart, Target, Visa and Mastercard (Path to 1.0).

For site owners, the Personal Agent Protocol comes down to one file: /.well-known/poppy.json. It tells a visiting agent who you are, how sign-in works and which doors (web pages, OpenAPI, MCP) it may use. Here's what it contains and what to do about it now.

TL;DR

The Personal Agent Protocol gives personal AI agents a standard way to discover a business, prove who they are and get scoped read or write access through OAuth.
Discovery starts at /.well-known/poppy.json. A website-only business can publish that file without any auth section, according to the project's own implementation kit.
It's still a draft that can break between versions, so prepare the groundwork (clean APIs, crawlable discovery paths, readable pages) rather than betting on exact field names.

What the Personal Agent Protocol actually is

Today most AI agents that act for a person do it the hard way. They log in as the customer and click through pages built for humans, and the business has no reliable way to tell an agent from a person or know what the customer approved. PYMNTS notes that only 23% of merchants can clearly identify AI-driven traffic (PYMNTS).

Poppy tries to fix that with a few building blocks:

Discovery: a JSON file at a standard address describing how agents connect.
Identity: the agent always identifies itself. Before sign-in, the business only sees a stable per-company ID, not personal data (introduction).
Sign-in and scopes: sessions are built on OAuth, and the customer picks read-only or write access (Sierra).
Interfaces: the business chooses whether agents use its website, its APIs (OpenAPI or MCP) or a company agent.

Payments are out of scope for now. TNW reports that payments, push notifications and finer permissions are future extensions (TNW).

Why it matters for websites

Agents are already visiting stores and service sites, and the platforms are fighting about it. PYMNTS points out that Amazon blocked Meta's Muse agent in September. Poppy is Meta's and Sierra's answer to that standoff: give businesses a declared, permissioned front door instead of anonymous scraping.

That changes the question site owners need to answer. It used to be "do I block this bot or not?" Now it's "what do I want agents to be able to do here, and through which channel?" A retailer might allow signed-out agents to check stock and return policies, require sign-in for order changes, and route everything through an API instead of the checkout UI.

It also isn't the only protocol in play. Google's Universal Commerce Protocol uses /.well-known/ucp and focuses on catalog, cart and checkout, while Poppy focuses on identity, sessions and permissions. UCP Checker found that neither spec references the other yet (UCP Checker). Expect your site to serve more than one discovery file in the next year.

Inside poppy.json: a technical breakdown

The discovery file

This is the example on the project homepage for Draft 0.2 (personalagentprotocol.org):

{
  "protocol_version": "0.2",
  "organization": {
    "name": "Manzanita Supply",
    "domain": "manzanitasupply.example"
  },
  "auth": {
    "issuer": "https://auth.manzanitasupply.example",
    "direct": { "scopes": ["poppy:read", "poppy:write"] }
  },
  "agent": {
    "protocols": [
      {
        "type": "poppy",
        "endpoint": "https://api.manzanitasupply.example/poppy/conversations"
      }
    ]
  }
}

The auth.issuer has to match the issuer in your OAuth metadata at /.well-known/oauth-authorization-server, and that metadata must list your domain in poppy_domains:

{
  "issuer": "https://auth.manzanitasupply.example",
  "poppy_domains": ["manzanitasupply.example"]
}

UCP Checker's read of Draft 0.1 also describes an apis list (OpenAPI or MCP entries) and a browser_session_endpoint for web access. The 0.2 homepage example doesn't show those, so check the current spec before you copy field names.

Trade-offs to weigh

Choice	Effort	What agents get
Website only, no `auth`	Low	Discovery plus your normal pages
Signed-out sessions	Medium	Identified agents, no account access
Full sign-in with scopes	High	Account actions under `poppy:read` or `poppy:write`

Full implementation isn't trivial. The kit lists DPoP-bound tokens, verification of each agent's signed identity and a browser session endpoint that turns an agent's assertion into your normal cookie (company kit). That's identity team work, not a weekend task.

What it means for site owners right now

You probably don't need to ship full Poppy sign-in this quarter. The spec says a revision before 1.0 can break compatibility with earlier drafts, and there's no published timeline.

What you can do is make the cheap parts of agent readiness true today, because every one of these protocols leans on them:

Your pages still matter. Poppy explicitly keeps the website as a valid door. If an agent lands on a product page, it needs real headings, labelled forms and JSON-LD to understand what it's looking at.
Your APIs need to be findable. Poppy points agents at OpenAPI and MCP rather than inventing a new API format. If your OpenAPI spec lives behind a login or nobody links to it, the discovery file can't help much.
Your well-known paths need to be reachable. Bot protection that challenges every non-browser request on /.well-known/ will break discovery for all of these standards at once.

How to get ready: a practical checklist

Decide your stance for each task: what signed-out agents may do, what needs sign-in, and what stays human-only.
Confirm /.well-known/ returns plain JSON to non-browser clients. Test with curl -sI https://yoursite.com/.well-known/oauth-authorization-server and make sure your WAF isn't serving a challenge page.
If you're website-only, consider a minimal poppy.json with just protocol_version and organization, as the kit describes for companies that stop "after publishing poppy.json without auth." Validate required fields against Section 3 of the 0.2 spec first.
Publish your OpenAPI spec at a stable public URL and link it from your developer docs.
If you run an MCP server, make it discoverable on its own. Our guide to remote MCP server discovery covers server cards.
Audit the pages agents will use most (product, pricing, returns, account) for semantic HTML and structured data.
Watch the GitHub repo for breaking changes before 1.0.

You can check steps 4 to 6 in a minute: a free AgentReady scan reports whether public OpenAPI specs and developer docs show up under the API & Docs pillar, whether a discoverable MCP server exists under MCP Presence, and flags missing JSON-LD or unlabelled forms under Browser Readiness.

Check your own site

Poppy routes agents to three doors, and the Agent Readiness Score measures all three: Browser Readiness for your pages, API & Docs for OpenAPI specs and developer docs, and MCP Presence for server discovery. A low API & Docs or MCP Presence score usually means agents can only reach you by scraping, which is exactly what Poppy is trying to replace. Read how the Agent Readiness Score works, then run a single-page scan. It's free and takes about a minute. Scan your site free.

Key takeaways

The Personal Agent Protocol is a draft open standard from Sierra and Meta for agent identity, sign-in and permissions.
Discovery lives at /.well-known/poppy.json, tied to your OAuth metadata through issuer and poppy_domains.
Website-only businesses can publish discovery without building OAuth sign-in.
Payments aren't covered yet, and drafts may break before 1.0.
Public OpenAPI specs, discoverable MCP servers and clean page markup pay off under Poppy, UCP and whatever comes next.

FAQ

What is the Personal Agent Protocol?

The Personal Agent Protocol, or Poppy, is an open standard from Sierra and Meta that defines how a consumer's personal AI agent discovers a business, identifies itself, signs in through OAuth and gets read or write access. It's published under Apache 2.0, is currently a draft, and has design partners including OpenAI, Shopify, Stripe and Walmart.

What is poppy.json?

poppy.json is the discovery file a business publishes at /.well-known/poppy.json. It lists the protocol version, the organization's name and domain, and optionally an OAuth issuer, supported scopes and agent endpoints. Agents read it first to learn how to connect. The issuer must match the business's OAuth authorization server metadata.

Does the Personal Agent Protocol handle payments?

Not yet. The current draft covers discovery, identity, sessions, sign-in and conversations. Payments, push notifications and attachments are outside its scope, and Sierra has listed payment extensions as possible future work. Checkout today still runs through your existing site, APIs or other commerce protocols such as UCP.

Is the Personal Agent Protocol the same as UCP?

No. Google's Universal Commerce Protocol uses /.well-known/ucp and focuses on catalog, cart, checkout and orders. Poppy focuses on agent identity, sessions, permissions and conversations. They overlap on discovery and OAuth sign-in, but neither spec currently references the other, so a store may end up publishing both files.

Start with the boring part: make sure /.well-known/ is reachable, your OpenAPI spec is public and your key pages are readable to agents. Then decide what you'd put in a poppy.json once the spec settles. Run a free AgentReady scan.

Personal Agent Protocol: What poppy.json Means for Your Site