SignorCrypto note · AI
Personal Agent Protocol Explained: What Poppy Does
How Poppy links personal agents to company websites, APIs and service agents—and why its draft status matters.

Personal Agent Protocol (Poppy) is a draft protocol for a personal AI agent to work with a company on behalf of one customer. It standardizes how a company can publish agent-facing entry points, establish a shared session, authenticate a customer and limit access across its website, APIs or service agent. Poppy complements protocols such as MCP and commerce-focused UCP rather than replacing them. As of 19 October 2026, the public specification is version 0.2 and explicitly remains a draft; revisions before 1.0 may break compatibility.
Sierra announced the effort with Meta and industry partners on 6 October 2026. The useful question for builders is not whether every business will adopt it, but which parts of the customer–agent relationship Poppy proposes to standardize—and what remains unfinished.
What Personal Agent Protocol standardizes
A participating company publishes a discovery document at /.well-known/poppy.json. The file can identify the company, describe supported sign-in methods, and point to the website, APIs and company-operated agent interfaces that a personal agent may use. The specification defines a common path for discovery, sessions and authorization, web browsing, APIs, conversations and optional extensions.
The two sides retain different controls:
- The company decides whether to accept personal agents, which sign-in options and channels to expose, and which permissions are available.
- The customer decides whether the agent may view account information, make changes, or do both—within the options the company has configured.
That is broader than simply exposing a chatbot or API. The design aims to let one customer task continue across a company's site, API and support agent without treating each channel as an unrelated visit. See the Poppy 0.2 specification and its introduction.
How a Poppy session works
- Discover the company. The agent retrieves
poppy.jsonfrom the company's HTTPS domain. The draft requires checks that the document's domain and its OAuth issuer correspond, reducing the risk of accepting another company's configuration as authentic. - Start with limited access. A session can begin signed out. Depending on what the business exposes, the agent may be able to answer a public question or check availability before the customer signs in.
- Authenticate and grant scopes. The customer signs in using an option the company offers. The draft describes direct sign-in, device sign-in and mediated sign-in; the chosen flow affects where credentials are entered. Permissions can distinguish read access from write access, with company-defined scopes also possible.
- Use the available route. The company may offer its website, APIs described with formats such as OpenAPI or MCP, or a conversation with its own agent. The protocol is intended to carry the customer's session across these routes.
- Limit or revoke access. Poppy defines short-lived session tokens and a longer-lived account credential for returning sessions, with revocation mechanisms. Those controls still depend on the company's configuration and the agent's implementation.
For businesses, the practical value is a more consistent way to recognize an agent acting for a customer and apply the company's chosen permissions. It does not require every company to expose every route: the company chooses what to support.
Poppy vs MCP, A2A and UCP
These protocols address adjacent layers, not interchangeable products.
| Protocol | Main role | Relationship to Poppy |
|---|---|---|
| Personal Agent Protocol (Poppy) | Discovery, customer sign-in, sessions and scoped access between a customer's personal agent and a company across web, APIs and a company agent. | Defines the company–customer-agent relationship. |
| MCP | Connects an AI application to external context and tools. | A company can expose an MCP endpoint for a Poppy-connected agent to use; MCP itself is not the complete cross-channel customer-session model. See the official MCP specification. |
| A2A | Supports communication and task handoffs between agents. | A company agent may use an agent communication protocol; that is a different concern from discovering a business and carrying a customer's authorization across channels. Our MCP vs A2A guide explains those roles. |
| UCP | Standardizes agentic commerce across shopping activities, from product discovery and checkout to post-purchase support. | Poppy's draft describes UCP as complementary: Poppy focuses on how a personal agent identifies itself, receives customer permission and works with a company across different tasks. |
The distinction matters: a company may use MCP to expose a tool, but still needs its own decisions about who the agent represents, which customer account it may access and what actions it may take. Likewise, a commerce protocol can describe shopping flows without being the same thing as a general customer-agent session layer. Google announced UCP on 11 January 2026 as an open standard for agentic commerce; the Google announcement describes its commerce scope.
What the draft does not promise
The project calls version 0.2 a draft. Its Path to 1.0 says revisions before 1.0 can be incompatible, so a pilot built against today's details may need changes. The same page lists payments, push notifications, version negotiation and attachments as open topics. A team should not assume those capabilities are already part of the stable core.
Nor does using OAuth make an integration secure by default. Poppy specifies domain and issuer checks, scoped access and token mechanisms, but companies still need to implement and test consent, authorization, token storage, revocation and error handling. The IETF's RFC 9700 sets current security practice for OAuth 2.0; it is guidance for implementations, not a certification of Poppy deployments. Agent identity and account permission are also separate controls, as discussed in our guide to least privilege for AI agents.
A practical evaluation checklist
Before a company builds on Poppy, its product and security teams can:
- Identify one low-risk customer task and begin with read-only access where possible.
- Map each requested action to a narrow company-defined scope; do not treat a broad
writepermission as a substitute for action-level limits. - Test the full journey across web, APIs and company support, including sign-in, denied permissions, expired sessions and revocation.
- Verify that the company domain, OAuth issuer and metadata stay aligned, and test how tokens are protected and handled across redirects.
- Decide when a human must confirm a consequential action, such as changing an account or completing a transaction.
- Re-check the draft version and open topics before treating a prototype as a supported production interface.
FAQ
Is Personal Agent Protocol the same as MCP?
No. MCP standardizes connections between AI applications and tools or context. Poppy focuses on how a personal agent discovers a company, signs in for a customer and carries scoped access across company channels. A Poppy implementation can use MCP as one available API route.
Is Poppy a finalized standard?
No. The public specification is version 0.2, and the project identifies it as a draft on the path to 1.0. The authors warn that pre-1.0 revisions may break compatibility.
Does Poppy handle payments?
Payments are listed as an open topic in the project's Path to 1.0. Companies should not assume that the core draft provides a complete payment flow.
The SignorCrypto view
Poppy is best understood as a proposed handshake and permission layer between a customer, that customer's personal agent and a company—not as another general-purpose AI agent or a universal checkout API. Its potential value is continuity: a business can declare how an agent discovers its services and what access it may request. The principal uncertainty is whether the evolving draft can make those permission boundaries work consistently across different companies and channels. A narrowly scoped pilot against the company's own identity and security requirements is a stronger signal than a partner list alone.
Sources
- Personal Agent Protocol v0.2 specification
- Personal Agent Protocol: Path to 1.0
- Sierra: Introducing Personal Agent Protocol
- Google: New tech and tools for retailers in an agentic shopping era
- Model Context Protocol specification, 28 July 2026
- IETF RFC 9700: Best Current Practice for OAuth 2.0 Security
For a team evaluating how Poppy would fit its identity stack and customer-facing APIs, talk with SignorCrypto about integration architecture and a safely scoped pilot.