The Personal Agent Protocol is a draft standard for how a person's AI assistant gets into a company's website, APIs and support agent, and what the company lets it do once inside. Sierra and Meta announced it with partners including Stripe, Shopify and Walmart (Sierra announcement), and a first draft, nicknamed Poppy, went public a few days later (Sierra on the draft). It is not a product you can switch on today.
If you run a business, the useful reading is this: nothing breaks and nothing is required. But AI assistants are already visiting sites on behalf of customers, and this draft is the first serious attempt at giving you a say in how. Knowing the shape of it now costs an hour. Ignoring it could cost you a messy few years of improvised bot rules.
This piece covers what the draft defines, how it differs from MCP, A2A and the commerce protocols, who signed up and who didn't, and a short list of things worth doing now.
What is actually public, and what isn't
Three things exist. There is Sierra's announcement, which names the partners and the design goals. There is a draft specification, marked Draft 0.1, licensed Apache 2.0 (spec). And there is a promise of design workshops and a reference implementation, none of which had appeared in the sources checked for this piece (Sierra).
What isn't public yet: any named company running it in production, a governing body, or a settled answer on payments. When the news broke, one report noted that no governing body or license had been identified (FourWeekMBA). The license part has since been answered by the draft itself. The governance part, in the pages checked, has not.
So treat it as a proposal with serious backers. Meta framed the ambition with an email comparison: "Email took off because everyone agreed on addressing, message transport and delivery. No one owns it, anyone can build on it" (VKTR). Email also took years, and plenty of businesses ran their own odd mail rules in the meantime. Expect the same patchwork here: early adopters will set the conventions the rest copy.
The problem: block everything or hand over the password
The project's own site describes today's choice bluntly. Companies either block agents entirely, or an agent signs in with the user's full credentials and can do anything the user can (personalagentprotocol.org). Neither is good. Blocking annoys the customer who sent the agent. Full access is a security review waiting to happen.
Blocking is real. One roundup of the announcement lists Amazon, Delta, United, Zillow and eBay among sites that block agents, and mentions a Cloudflare anti-bot policy that caught some by accident (AI Weekly). Stripe's Kevin Miller made the customer's side of it plain: people who send an agent "expect the same service they would get themselves" (Unite.AI).
The draft's answer is a ladder. The site uses a hotel example: block the agent, let any agent search rooms, let it see reservations after sign-in, let it book a room only with the person's approval each time, or give it full access. You pick the rung per action.
The middle rungs are the point. Most companies will want agents to browse and read freely, and to change things only when a human says yes.
How a session works
A company publishes a file at /.well-known/poppy.json that says how agents can deal with it. The agent reads it, opens a session (as a guest if nobody is signed in), and, when it needs more, sends the person through an OAuth-based sign-in (Sierra). The draft names three sign-in types: direct, where the person signs in on the company's own page, device, where they use a code on another device, and mediated, where the agent submits credentials itself (spec).
Two details matter for security people. Session tokens are short-lived and bound to a key with DPoP, and the draft says agents must not send tokens in a URL and companies must not accept them there. It also admits the weak spot: "Accepting credentials from a Personal Agent puts more responsibility on the Company" (spec).
The other idea worth knowing is that one token covers everything. Sierra says the same token works for the company's APIs, its website and conversations with its agent (Sierra). A question asked before signing in and an order changed afterwards count as one visit (The Next Web).
Three ways in, and your choice
You don't have to build all of it. A company picks how agents reach it: through the website, through APIs described with OpenAPI or an MCP server, or through its own agent for conversations. A retailer with a good API can skip the browsing route. A small shop with only a website can start there.
The conversation route has one rule that customers will like: each message says whether a human or an AI wrote it, and the draft covers handoffs to a person. If you already run a support agent, say from the customer support board, this is the route that touches you first.
How it fits with MCP, A2A, ACP and AP2
It doesn't replace any of them, and it shouldn't be read as competing with them. They cover different jobs, and the draft leans on MCP itself.
| Protocol | Made by | Job |
|---|---|---|
| MCP | Open-source standard | Connects AI apps to tools and data (MCP docs) |
| A2A | Google, now Linux Foundation | Lets agents from different vendors talk to each other (A2A) |
| ACP | Stripe and OpenAI | Agent checkout and payment credential sharing (ACP) |
| AP2 | Signed mandates that prove a user authorized a purchase (AP2) | |
| Personal Agent Protocol | Sierra and Meta (draft) | Discovery, sessions, sign-in and permissions between a personal agent and a business |
The stack above is our reading, not an official diagram. The clean way to say it: MCP is how an agent calls a tool, A2A is how agents talk, ACP and AP2 are about paying, and this draft is about getting in the door and being recognized. Payments are listed as a future extension, so a checkout would still run on something like ACP or AP2 today. The overlap that will cause arguments is MCP, since both the draft and a plain MCP server can expose a company's actions.
There is a rival on the access side too. Visa runs a Trusted Agent Protocol that launched earlier this year, and The Next Web reported that Stripe and Shopify had already joined it (The Next Web). Visa is now also on the Personal Agent Protocol design-partner list, so the two efforts may overlap rather than compete head on. Whether the industry ends up with one standard or two is open.
Who is in, and who is missing
The announcement named Genesys, Instinct, Rocket, Shopify, Stripe and Walmart alongside Sierra and Meta (Sierra). The draft post also lists NiCE in that first group and adds 35 more design partners, including Adyen, Bank of America, BBVA, Cloudflare, Mastercard, OpenAI, PayPal, Target, United Airlines, Visa and Wells Fargo. Sierra says they will take part in the design process, which is not the same as shipping support (Sierra). That changes an earlier story: on announcement day, reports flagged OpenAI as absent, and Bret Taylor, Sierra's co-founder, chairs OpenAI's board (AI Weekly).
Amazon, Anthropic and Google are not among the partners listed at launch or in the draft post. Absence from a list isn't proof they're out, so check Sierra's pages again before you quote this. Claude, ChatGPT and Perplexity would all be natural personal agents, and a standard with no major assistant behind it stays a company-side checklist. On announcement day, The Next Web noted that no European retailer, bank or payment company had been named (The Next Web). The longer list now includes BBVA and Adyen.
What it means for developers and marketers
Developers get the clearer deal. If your product already has OAuth and an OpenAPI description, you're most of the way to the API route, and the draft's token rules (short-lived, key-bound, never in a URL) read like ordinary good practice. The new work is the discovery file and deciding scopes.
Marketers get a measurement question. Today an agent that researches your pricing page for a customer looks like a bot, or like nothing. A session that identifies the agent, and a customer behind it, turns that traffic into something you can count and treat differently from scrapers. Whether that's good news depends on what you want agents to say about you, which is a content question as much as a technical one.
What a business can do now
Nothing here requires the protocol. All of it helps whether the draft wins or fades.
- Look at your logs and bot tooling and find out which agent traffic already reaches you. If you use Cloudflare, check what its bot rules do to agents acting for a customer.
- Write down, per action, what an agent may read and what it may change. Use the ladder above: browse, see account, act with approval.
- Check that customers can sign in through a standard OAuth flow. Agents will lean on it.
- Put your top actions (order status, returns, bookings) behind a documented API or an MCP server. A well-described OpenAPI file is worth having anyway.
- If you sell on Shopify, watch for what the platform ships rather than building it yourself.
- Give one person the job of following the draft. Read the spec's Open topics page when it changes.
The scorer below turns that list into a quick self-check. It's our own checklist, not part of the protocol.
Who shouldn't bother yet: a business with no logins, no API and no support agent. You have nothing to expose. If you're a customer-service shop, the nearest comparison is the AI agent you already run (Sierra AI Agents is one; the AI support chatbots board lists others). Neighboring reads: our AI agent platform buyer's guide and the top AI agents board.
The open questions
Identity. The draft lets companies require agent registration, keep allowlists and blocklists by client ID, and revoke a client ID that misuses the protocol (spec). Who vouches for an agent, and how a small shop checks one, is left to each company. At announcement time, reporting said there were no details on how agents prove identity (FourWeekMBA). The spec does not describe a shared registry of trusted agents.
Consent. Direct sign-in shows requested scopes and lets the person approve some, all or none. That's good. What isn't settled is how often agents ask, and whether people will click through.
Liability. If an agent books the wrong flight, someone eats the cost, and the spec doesn't say who. It doesn't mention liability at all. Neither does it mention payments, which are flagged for later.
Spam and abuse. Companies may rate-limit session creation by client ID. Whether that holds against agents that rotate identities is untested.
Frequently asked questions
Is the Personal Agent Protocol live?
Not as a shipped standard. A Draft 0.1 spec is public and Sierra has promised workshops and a reference implementation. No production deployment had been named in the sources checked.
Does it replace MCP?
No. It points to MCP as one of the ways a company can expose its actions. MCP connects an AI app to a tool. The draft governs who the agent is and what it may do at a given company.
Do I need to publish a poppy.json file?
Not yet. The draft says companies publish it for discovery, but nobody has to until the spec stabilizes and agents start reading it. Preparing the underlying decisions is the useful part.
Can I still block AI agents?
Yes. Blocking is the first rung on the ladder. The draft's pitch is that you get options between blocking and full access.
Does it handle payments?
Not in the draft. Sierra lists payments without sharing card details as a future extension. For checkout today, look at ACP or AP2.
Who controls it?
The draft is Apache 2.0 and was published by Sierra with Meta. No governing body appears in the published pages, so who steers it long term is an open question.
