What is the Personal Agent Protocol?

An open standard, announced by Sierra and Meta on 6 October 2026, for how personal AI agents interact with businesses on a customer's behalf. It covers discovery (a company publishes a file describing how agents can reach it), sign-in through OAuth, read-only or write access chosen by the customer, and one session that carries across the company's website, APIs and its own AI agent. It is also known by its codename, Poppy.

Who supports the Personal Agent Protocol?

Meta and Sierra, with launch partners Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. On 9 October Sierra named 35 more design partners, including OpenAI, Visa, Mastercard, PayPal, Target, United Airlines, Bank of America, Okta, Cloudflare and Zendesk.

Is the Personal Agent Protocol final?

No. It is a draft. Sierra's announcement said a v0.1 specification would follow later in October 2026; a draft was published at personalagentprotocol.org on 9 October, and its example already reads protocol_version 0.2, so check the current version before you build. Payments, finer-grained permissions and push notifications are listed as future work.

Does the Personal Agent Protocol use MCP?

It can. A company chooses how agents reach it: through its regular website, through its APIs using standards such as MCP and OpenAPI, or through its own AI agent for conversational tasks. The protocol adds the layer around those channels: discovery, sign-in, the customer's choice of read or write access, and a session token that works across all of them.

What should a business do about the Personal Agent Protocol now?

Nothing irreversible until the spec settles, but the groundwork is the same either way: expose the tasks customers actually do (order status, returns, bookings, account changes) as clean, permissioned APIs or an MCP server, put OAuth sign-in with separate read and write scopes and a revoke endpoint in front of them, and make sure your logs can tell an agent acting for a customer from the customer.

Personal Agent Protocol (PAP) Explained for Businesses

A small shop with a key-card reader at its door, an assistant orb approaching with a card, and three entrances: a door, a socket hatch and a speech-bubble window

The Personal Agent Protocol (PAP, codenamed Poppy) is an open standard from Sierra and Meta, announced on 6 October 2026, for how a customer's personal AI agent deals with a business. The agent finds a file the company publishes describing how to reach it, starts a session (as a guest for simple questions), and, when the task needs the customer's account, the customer signs in through OAuth and chooses read-only or write access. One session token then works across the company's website, its APIs (MCP or OpenAPI) and its own AI agent. It is a draft, payments are not in it yet, and the partner list already runs from Shopify and Walmart to OpenAI, Visa and Bank of America. Below: how it works, what is still open, and what a business can prepare now without betting on the details.

What was announced

6 October: Sierra's announcement, by Bret Taylor and Clay Bavor. Meta and Sierra are developing the protocol "with industry partners", and anyone can implement it. Launch partners: Genesys, Instinct, Rocket, Shopify, Stripe and Walmart.
9 October: a published draft, at personalagentprotocol.org, with 35 new design partners, among them OpenAI, Adyen, Visa, Mastercard, PayPal, Plaid, Bank of America, Wells Fargo, Target, Nordstrom, United Airlines, Hertz, Okta, Cloudflare, Zapier, Notion and Zendesk.
Next: design workshops over the following month, and a reference implementation for developers.

Versions are moving fast. The announcement promised a v0.1 later in October; the draft site's example already reads "protocol_version": "0.2". Read the current draft before building anything against it.

How it works

From Sierra's posts and the draft spec:

Discovery. The company publishes /.well-known/poppy.json. It names the organization, says how to start a session and sign in, and lists the APIs and company agent on offer. The OAuth details live at the standard /.well-known/oauth-authorization-server, including token and revocation endpoints.
Session. The personal agent starts a session for its customer and identifies itself. The company always knows when an agent is acting, and for whom.
Guest first. Simple questions, such as "is this in stock?" or "what's your return policy?", don't need a login.
Sign-in and consent. When the task needs the account, the customer signs in on the company's own page through OAuth and chooses the access: in the draft's example, poppy:read, poppy:write, or both.
One session, every channel. A short-lived session token, a signed JWT, works across the company's APIs and its agent, and the agent's browser can prove which session it belongs to on web pages. A question asked before sign-in and an order change after it are one visit.
Until revoked. Access lasts until the customer or the company revokes it.

The company decides how agents reach it: its website (the agent browses ordinary pages), its APIs (OpenAPI or MCP), or its own agent, for tasks that need a conversation, like a warranty claim.

What it doesn't cover yet

Payments. Listed as a future extension, so that agents can complete purchases without sharing card details. Until then, buying is out of scope.
Fine-grained permissions. Today the choice is read or write. Limiting an agent to specific actions ("can change delivery dates, can't cancel orders") is future work.
Push notifications, such as a flight delay or a shipped order, are future work too.
How MCP is declared. The draft says companies can offer MCP, but its example discovery file has no MCP entry and doesn't describe MCP sign-in. Expect this to be filled in.
Shopping flows. Sierra describes PAP as complementary to Google's Universal Commerce Protocol, which handles product discovery, checkout and orders. PAP handles identity, permissions, and tasks of any kind.

It also isn't the only agent standard in play: Visa's Trusted Agent Protocol and the Stripe and OpenAI Agentic Commerce Protocol cover overlapping ground, and several companies sit in more than one camp.

What to prepare now

The spec will change. The groundwork under it won't, and it's useful whether PAP wins or not:

Pick the tasks. Not "make us agent-ready", but the five things customers actually do with your company: order status, returns, bookings, address changes, a quote. Those are what agents will ask for.
Expose them as clean, permissioned tools. An API or an MCP server where each task is one typed operation, with validated inputs and an honest error when it can't be done. A personal agent can't use a workflow that only exists as a sequence of web forms, or it will scrape it badly.
Put OAuth in front, with read and write separated. The customer signs in on your page, grants read or write, and can revoke it. If your APIs today run on shared keys, this is the biggest piece of work, and it's the one PAP leans on.
Previews and confirmations on anything that matters. Read access is easy to grant. Write access is where "the agent cancelled my order" support tickets come from. Destructive actions should show what will change before they do it.
Logs that know who acted. Every action recorded as "the agent of customer X, in session Y", not as the customer. You'll need it for disputes, and PAP requires agents to identify themselves for exactly that reason.
Watch the spec, not the headlines. The discovery file is minutes of work once the rest exists. Publish it when the spec settles.

What we've already built

We built the OAuth half of this on our own CRM in August 2026, so that assistants such as Claude could connect to it with each person's own login instead of a shared key. It is close to what PAP asks for:

PAP draft	Our CRM's MCP server
OAuth authorization-server metadata at a `.well-known` path	Served at `/.well-known/oauth-authorization-server`, plus protected-resource metadata
Customer signs in on the company's page and approves access	Sign-in and a consent screen in the CRM itself
`poppy:read` / `poppy:write`	`crm:read` / `crm:write`, enforced on every tool call
Access until revoked, revocation endpoint	Token, refresh and revoke endpoints, plus a "Connected apps" page where each user sees and revokes every grant
APIs offered over MCP	167 tools over MCP, each one a typed operation

Two design choices carry over directly. The scope a tool needs comes from the tool's own definition: read-only tools need read, and everything else, including a tool nobody labelled, needs write, so a forgotten label can't hand a read-only agent the power to change data. And destructive tools accept a dry run that shows what would change before anything happens. More in what MCP OAuth is and how we run our CRM inside Claude.

What we don't do yet: we haven't implemented PAP's discovery file or session tokens, because the draft is still moving. When it settles, adding them in front of a server like this is the small part of the job.

Where we fit

We build the part underneath: the MCP server or API that exposes your company's real tasks as permissioned tools, the OAuth sign-in with read and write separated, previews on destructive actions, and logs that tell an agent from a person. It works with Claude and ChatGPT today, and it's the foundation PAP builds on. Scoping a first workflow costs $2,300 to $4,700, and a first workflow in production starts at $17,500, priced here.

Related: What is MCP?, WebMCP, and MCP security.

Personal Agent Protocol: What Meta and Sierra's Standard Means for Your Business

Your customers' AI agents are about to knock on your door: checking stock, changing an order, filing a claim. A new open standard from Meta, Sierra and 40-odd partners defines how they get in. Most of what it asks for is work you can do now.