Two weeks ago I wrote about AI agents that phone businesses on a person's behalf — Google's assistant sitting on hold so you don't have to. That's the clumsy version of a real shift: people are starting to hand everyday errands to an AI, and many of those errands end at a company.
On 6 October, Sierra and Meta proposed the less clumsy version. The Personal Agent Protocol — "Poppy" for short — is an open standard for how a person's AI agent works with a company: how it finds you, signs in, gets limited access to the customer's account, and talks to your systems or your own agent. It's being developed with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart, and draft 0.1 of the specification is now public under the Apache 2.0 licence.
Here is what it actually specifies, read from the draft rather than the launch posts, and what I'd do about it.
The problem: today it's all or nothing
The spec's introduction puts it well. Right now, an agent either passes as the user — signing in with their password and clicking through pages built for people — or the company blocks it and it can't do anything. The user can't limit what the agent does once it's in, and the company can't tell an agent from a person or offer it a better path. When neither works, the agent falls back to calling your support line or opening your web chat.
Poppy's answer is to put points between those extremes. In Sierra's words: "consumers decide what access to give their personal agents, and companies set parameters for what those agents can do." An airline might let any agent search flights, let a signed-in agent see the user's trips, and still require the user's approval to buy a ticket.
How it works, in five pieces
1. Discovery: one file. A company publishes a JSON document at https://yourdomain/.well-known/poppy.json. It names your OAuth issuer, the sign-in methods you support, and the ways an agent can work with you. A personal agent reads it first. (I built a poppy.json generator and validator that follows the draft section by section.)
2. Sessions: the agent always identifies itself. Every agent has its own identity and signs its requests, and its session tokens are normally bound to its own keys (DPoP), so a copied token is useless to anyone else. (MCP servers take plain Bearer tokens instead, each issued for that one server.) Before the customer signs in, you see them only as an opaque ID that is stable for your company and different at every other company — you can recognise a returning user without learning who they are, and companies can't cross-match people.
3. Sign-in: the user chooses the access. The draft defines three ways to sign in — on your own page (direct), with a code on another device (device), or by the agent passing credentials to an endpoint you control (mediated) — and two standard scopes, poppy:read and poppy:write. You can add your own, narrower scopes such as "manage saved addresses", or drop the broad ones entirely. The customer approves what the agent gets, and you enforce it.
4. Three front doors, your choice. You decide how an agent does the work:
- through your website, which it browses in the same session;
- through your APIs — OpenAPI or a remote MCP server — which is faster and cheaper than clicking through pages;
- through your own agent, for things that need a conversation, like a warranty claim.
You can start with only one and add the others later.
5. Conversations that know who's human. When an agent talks to your company agent, every message is marked as written by a human or an AI. When both sides are AI they can skip the small talk and exchange structured data; when a person is on either side, the other side writes for that person. Either side can bring in a human: the agent can ask for a person at your company (a defined handoff with a queue status), and your company can ask to speak to the customer directly, which the agent offers to the user rather than forcing.
That last piece is the part I find most interesting, because it's what I argued phone lines need: know whether you're talking to a machine, and have a clean path to a person. Poppy builds both into the protocol instead of leaving them to etiquette.
Isn't this just MCP?
No — and it uses MCP. The Model Context Protocol is how a model calls tools. It says nothing about which company those tools belong to, whose account they act on, or what the account holder agreed to. Poppy is the layer around that: discovery, identity, consent and scopes, plus the human-or-AI conversation channel. A company can list its MCP server in poppy.json, and the draft spells out how that server accepts Poppy's tokens.
What it doesn't do yet
Be clear-eyed about the status:
- It's draft 0.1. The spec says any part can change before 1.0, including in ways that aren't backward compatible.
- Payments aren't in it. Sierra lists payments without sharing card details, push notifications (an airline telling the agent the moment a flight is delayed) and finer-grained permissions as future extensions. The draft's "Path to 1.0" page lists payments as an open topic.
- It isn't the only effort. Agentic commerce has several competing proposals, and partner lists overlap. Standards like this are decided by adoption, not announcements.
What I'd do now
If you're a small business with a website and no API: nothing urgent. Make sure your site works without JavaScript tricks and your key information — prices, stock, hours, policies — is on real pages, because the first wave of agents will browse. That's good SEO anyway.
If you already run OAuth and an API: publishing a minimal poppy.json is cheap. Start with your website and one API, read-only scopes only. You'll learn what agents ask for before you've committed to letting them change anything.
Whatever your size, decide your policy before the traffic arrives. Which tasks can an anonymous agent do? Which need the customer signed in? Which changes need the customer's explicit approval? Those are business decisions, and the protocol only works if you've made them.
If you already have a customer-service agent — chat or voice: that's your "company agent" waiting to happen. The same brain that answers your phone can answer a personal agent, faster, with structured data instead of speech. That's the piece I'd prototype first, because it's where personal agents will need you most: the conversations a form can't handle.
The phone call from an AI was the warning shot. A front door built for agents is the version businesses can actually control — worth understanding now, while it's a draft and the design partners are still taking feedback.
References: Personal Agent Protocol specification, draft 0.1 · Introduction and principles · Path to 1.0 · Sierra: Introducing Personal Agent Protocol (Bret Taylor and Clay Bavor, 6 October 2026) · Stripe's announcement as a founding partner · Specification repository on GitHub.