Personal Agent Protocol (Poppy): What Businesses Should Know

Personal Agent Protocol, called Poppy for short, is a draft standard for how a customer's AI agent works with a company. Sierra announced it on October 6, 2026 with Meta, Genesys, Instinct, NiCE, Rocket, Shopify, Stripe and Walmart. Three days later Sierra published the draft and named 35 more design partners, among them OpenAI, Visa, Mastercard, PayPal, Zapier, Klaviyo, Notion, Okta, Zendesk, 1Password, Bank of America and Wells Fargo.

The problem it targets is simple. When a customer asks their personal agent to return an order or rebook a flight, the agent usually signs in as the customer and clicks through pages built for people. The company either blocks it or cannot tell it apart from the customer. Poppy gives the company a way to say what agents may do, and gives the customer a way to say what their agent may do for them.

We read Sierra's draft announcement, the protocol home page, the Path to 1.0 page and the draft specification on October 18, 2026. The docs were at draft 0.2 that day. Everything about Poppy below comes from those pages.

Poppy is early. The draft can still change in ways that break earlier versions, and payments, push notifications and attachments are not covered yet. Most small and mid-sized businesses should not build for it in production today. What you can do now costs little and helps either way: decide which account actions an outside agent should be allowed to see or change, and make sure your website, APIs and support channels apply the same rules.

Sierra's post lists five building blocks:

1. 1Discovery. The company publishes one file at a fixed address on its website, /.well-known/poppy.json. It tells agents how to start a session, how customers sign in, and which channels the company offers.
2. 2Sessions. The agent starts a session for its customer. It can begin as a guest, which may be enough to check stock or read a returns policy. The agent identifies itself, so the company knows when an agent is acting for a customer.
3. 3Sign-in. When a task needs the customer's account, the customer signs in on the company's own page through OAuth and chooses what access to grant.
4. 4One session across channels. The same session covers the company's APIs, its web pages and conversations with its own agent, so a question asked before sign-in and an order change after it are one visit.
5. 5Getting the job done. The company picks the channels. Agents can browse its regular pages with the customer's permissions applied, call its APIs through OpenAPI or MCP, or talk to the company's own agent for jobs that need back and forth, such as a warranty claim.

The protocol home page frames the choice as a range. At one end agents are blocked. At the other the agent acts as the user with full access. In between, a company can allow, for example, room search for any agent, viewing reservations after sign-in, and booking only with the user's approval.

The specification is built on OAuth, JSON Web Tokens, HTTPS, OpenAPI and MCP. A few parts matter for planning:

• poppy.json must list at least one way to work with the company: its web pages, its APIs or its company agent.
• There are three sign-in types. In direct sign-in the customer signs in on the company's page in a browser. In device sign-in the agent shows a link and code and the customer signs in on any device. In mediated sign-in the agent sends the customer's credentials to the company for them. A company can support any of these, or none and offer only guest sessions.
• Two broad scopes describe account access: poppy:read to view things like orders and bookings, and poppy:write to make changes like exchanging an item. The company decides which actions need which scope and must enforce that across web browsing, APIs and its own agent. It can define its own scopes too.
• Session tokens are short-lived OAuth access tokens, and the longer-lived account token from sign-in is an OAuth refresh token. The spec says this means a company can use its existing authorization server.
• Each customer gets an ID from the agent that is different at every company, so companies cannot match customers with each other.

The security section is worth a read even if you never adopt Poppy. It tells agents to treat everything a company returns as data and never as instructions, to send a company only what the task needs, and to keep tokens and other secrets out of the model's context.

Sierra's post gives three examples. A retailer lets a signed-in customer's agent start a return on the normal returns page but not change the payment details on file. An airline lets an agent rebook a canceled flight through its booking tools over MCP, with the agent confirming the seat with the customer before booking. And at Sierra Summit, Rocket showed Meta's Muse agent finding Rocket's own agent through Poppy and working through a mortgage pre-approval after the user signed in and shared the needed details. We have background on Muse in our post on Muse and other desktop agents.

These are steps we would take. None of them describes a client result.

1. 1Write down the agent permission map. List the account actions customers take today, such as checking an order, booking, rescheduling, returning or updating an address. Mark each as open to a guest, view only after sign-in, change after sign-in, or never for an agent. This is the core of what poppy.json and the scopes would express later, and it is useful now for any agent or chatbot you run.
2. 2Put the rules in one place. If your website, your API and your support chatbot each check permissions their own way, an agent will find the gap. We would move those checks into one service that all three call. That work pays off for your own staff tools too.
3. 3Offer a clean channel for the common jobs. Agents that click through pages are fragile, a point we cover in our post on when an agent should use the browser or MCP. A small, well-scoped API or MCP server for order status and returns, behind your existing customer sign-in, is the piece most likely to carry over to Poppy. Our explainer on what MCP servers are covers the basics.
4. 4Log agent sessions. Record when a request came from an agent, which customer it acted for and what it changed, and send that into your CRM or helpdesk so staff can see it.

If you run a Shopify store, some of this is already happening through Shopify's catalog and checkout tools for agents. See our post on Shopify Shop MCP for what store owners should check.

If your customers do not have accounts with you, or most of your business happens by phone or in person, there is little for an agent to sign in to. Wait. If you do not run your own OAuth sign-in, the sign-in parts of Poppy are a large project, and you should not start it for a draft. If your work depends on agents paying you, note that payments are an open topic in the draft. And until 1.0, anything you build to the spec may need rework. Sierra says it will run design workshops and publish a reference implementation over the next month, which is a better time to start a pilot.

On the other side of the table, a business that wants its own agent to buy things for it has a different problem: keeping cards and passwords away from the agent. Our post on Agent Vault covers one tool for that.

OrchestriAI is not a design partner in Poppy and has no role in the spec. We build the parts underneath it: systems integration to put permission checks in one place across your site, API and support tools, MCP development for scoped servers agents can call, and AI agent systems for customer-facing agents with clear limits. If you want to know which customer tasks are worth opening to agents first, start with the free automation audit.

OrchestriAI is an independent implementation provider. Product and company names are used for identification only. OrchestriAI is not affiliated with, endorsed by, or sponsored by Sierra, Meta, Shopify, OpenAI or any Poppy design partner. This article summarizes the public draft and Sierra's announcement as of October 18, 2026. The specification is a draft and can change, so check the current version before building. This is not legal or security advice.