What Is Personal Agent Protocol (Poppy)? How AI Agents Will Shop and Act for You

Key Takeaways

• Personal Agent Protocol (Poppy) is a draft standard linking personal AI agents with businesses through identified sessions, account permissions, and supported interfaces.
• Sierra and Meta introduced Poppy on October 6, 2026; Draft 0.1 followed on October 9, with broader implementation still pending.
• Poppy allows companies to offer website, API, or company-agent routes while users grant read or write permissions through OAuth.
• Poppy does not itself provide universal checkout or payment authorization; payment extensions and broader adoption remain unresolved in Draft 0.1.

Personal Agent Protocol (Poppy) is an open draft for a specific problem: how a personal AI agent can contact a business, identify itself, access an account with permission, and carry out a supported task. It is not another chatbot or a shopping app. For the broader purchasing process, see how AI shopping agents work; Poppy addresses the connection between an agent and the business behind that process.

The useful distinction with Poppy is between telling software what to do and giving it a legitimate way to do it.

Personal Agent Protocol, or Poppy, defines interactions among a User, a Personal Agent acting for that User, and a participating Company. Draft 0.1 specifies service discovery, identified sessions, OAuth-based account authorization, website access, APIs, and agent-to-agent conversations. Poppy standardizes access and interaction; companies still determine available actions and enforce permissions.

That means a request such as “return my jacket” could eventually use a defined handoff instead of relying entirely on a bot clicking through an unfamiliar website. It does not mean every retailer or AI assistant supports Poppy today.

Why Do AI Agents Need the Personal Agent Protocol?

The problem with agents pretending to be human

Most websites are still optimized for a customer holding a mouse or phone. An AI agent can try opening pages, finding buttons, completing forms, and entering an account, but this is a brittle way to handle business tasks. Login challenges, changed page layouts, inaccessible controls, and security checks can interrupt what looked like a straightforward request.

The problem is not just unreliable automation. A merchant or airline also needs to know whether a request comes from its customer, a customer-authorized agent, or an unidentified script. Treating all three as identical creates obvious problems for account access, fraud controls, support escalation, and audit trails. A customer might want an agent to check an order's delivery date without being able to change a shipping address.

Poppy tries to make those distinctions visible in a shared technical process. Sierra and Meta introduced Personal Agent Protocol on October 6, 2026, proposing a common approach that companies could implement through existing sites, APIs, or company agents. It is a proposal under development, not a new legal entitlement for agents to enter any site.

What changes for consumers and businesses

Poppy assigns different responsibilities to each participant. A user selects the agent and grants access. The personal agent identifies its software and the user it represents, obtains appropriate session credentials, and requests the task. The company decides what channels, APIs, and account actions it supports, then enforces its own policies.

That division matters because even a highly capable personal assistant does not possess inherent authority over a user's accounts. A request made in natural language is an instruction to the assistant; permission to act against a business's system is a separate matter. The protocol operates below the consumer-facing interface.

A well-designed implementation could therefore reduce repeated sign-ins and unnecessary handoffs while allowing a company to distinguish an agent from a person. Whether it reduces friction in practice will depend on participating businesses, agent implementations, security rules, and the quality of the underlying service. Poppy also does not determine which model an assistant runs, how it plans tasks, or whether it maintains memory. Those are characteristics of the agent product itself. For a separate look at those products, see personal AI assistants and features.

How Does Personal Agent Protocol (Poppy) Work?

Poppy Draft 0.1 has a recognizable sequence: discover a company, open an identified session, authenticate when needed, choose an interaction channel, and verify an outcome. The protocol documents how these pieces connect; it does not prescribe a single AI model or require every company to offer all three interaction channels.

The distinction between a Poppy session identity and account authority is the heart of the design.

A Poppy Session represents one User visiting one Company through a Personal Agent across supported channels. The Company learns the agent's identity and a separate user identifier; account access begins after authorized sign-in. Session Tokens carry access for web, API, or conversation requests, subject to the Company's accepted scopes and security checks.

In plain terms, a Poppy-enabled business can know that a software agent is present before knowing which customer account, if any, it may access.

Step 1: Discover the business through poppy.json

A participating company publishes a machine-readable document at https://company.example/.well-known/poppy.json. The file advertises where the agent should establish a session, how a customer can sign in, and which website, OpenAPI, MCP, or company-agent interfaces the company offers.

This discovery document is closer to a reception desk than a universal action list. It tells an agent where the approved entrances are; the actual business systems still determine the available products, orders, policies, and capabilities. An agent must also validate specified issuer and domain information rather than blindly trusting a file from an unrelated host.

Step 2: Start an identified session

The agent begins with an identified software client and a stable, opaque user ID specific to the company. Poppy deliberately specifies distinct user IDs across companies so unrelated businesses cannot use that identifier alone to correlate the same person. A guest session can be enough for public information, such as checking whether a jacket is in stock or reading a return policy.

Poppy's technical design uses signed client assertions, OAuth infrastructure, and sender-constrained tokens. Readers do not need to manage those credentials manually; the important point is that a business can evaluate an identified agent request under a defined session instead of guessing whether browser traffic represents an authorized user.

Step 3: Sign in and grant the right level of access

Account-specific tasks need a separate sign-in. Poppy defines two broad optional scopes: poppy:read for viewing details such as orders or bookings, and poppy:write for changes such as exchanges or updates. A company may also define narrower custom scopes rather than grant broad access. The agent cannot simply declare it has permission: the company issues and validates the credentials.

The Poppy Draft 0.1 specification describes direct and device sign-in paths, in which the user authenticates on the company's own page, as well as a mediated option subject to stricter conditions. Permission is not necessarily permanent: account tokens can expire or be revoked, and a new task may require another sign-in for additional scope.

Crucially, read versus write is not the same thing as “observe versus charge my credit card.” A broad write scope is a gate to actions the company accepts under it, not an independent universal authorization for purchases.

Step 4: Work through the company's website, APIs, or agent

Poppy keeps different interaction routes within the session. The personal agent may browse the website, call a listed OpenAPI or remote MCP interface, or talk with the company's own support agent. The company can provide one route or several, depending on the nature of the task.

An API might expose an order lookup more directly than a webpage. A conversation may be better for a disputed warranty claim. A website can remain useful when the company has not exposed a particular function through an API. None of these paths automatically bypasses the merchant's refund policy, booking conditions, or existing permission checks.

Step 5: Confirm the result, not just the intention

A personal agent has not finished a return simply because it says, “Done.” It needs a recorded outcome from the retailer, such as a return reference, updated order status, or confirmation of the submitted request. If a transaction is pending, failed, or awaiting a person, the agent should report that state accurately.

Poppy also proposes an optional operations extension for consequential changes. In that design, a company proposes the exact terms of an action, the agent obtains user approval or applies previously granted permission, and the company performs the confirmed revision. The extension tracks one operation across channels and specifies at-most-once execution for retries. It is not mandatory for all Poppy implementations, so it must not be described as a universal built-in purchase approval screen.

What Can AI Agents Actually Do With Poppy?

Poppy concerns the access path for tasks that companies choose to support. That makes shopping a visible example, but the protocol's scope is considerably wider than commerce. An implementation might allow an agent to ask general questions as a guest, look up an order after sign-in, or propose a booking change that needs confirmation.

Shopping, exchanges, and returns

Shopping tasks frequently involve actions before and after payment. A person may ask for a different size, check a warranty, or replace an out-of-stock item. These tasks require order context and sometimes authority to change an existing transaction. Poppy can help a business recognize which agent is acting, which account it may view, and which action paths it offers.

For example, Sierra describes a jacket-return flow in which a customer authorizes the agent, which then accesses the retailer's ordinary return interface. The retailer can allow a return without allowing changes to saved payment details. This example illustrates policy enforcement by the business, not a guarantee that any connected agent may initiate all returns.

Travel bookings and customer support

Airline disruptions show why the protocol is not merely a shopping standard. An agent asked to replace a canceled flight may need to see the booking, find alternatives, confirm fare differences, and ask for the passenger's decision. Using a supported MCP or API endpoint could reduce repetitive navigation, but it cannot manufacture available seats or override airline rules.

Support conversations offer another route. The company's own agent can handle questions, request account permission, or transfer a discussion to a person when a dispute or sensitive decision requires one. Under Poppy, that conversation can remain associated with the same overall session instead of forcing an agent to start from zero at each channel change.

Financial services: an example, not universal availability

Sierra reported a live October 6 demonstration involving Meta Muse and Rocket: a presenter asked Muse to pursue mortgage pre-approval, then signed in to share the income and credit information required for the process. That was an announced demonstration, not evidence that any Muse user can receive mortgage approval through Poppy today.

The scenario does show why identity, account authorization, and handoff to a company's own agent matter beyond retail. Readers seeking a detailed breakdown of the assistant used in that demonstration can examine Meta Muse's agent capabilities; the demonstration's availability and financial eligibility conditions should not be generalized beyond what Sierra disclosed.

Can Poppy Let AI Agents Shop and Pay Without You?

Not by virtue of Poppy alone. An agent can have permission to look up an order or request a change without possessing a valid payment method, an approved checkout route, or authorization for a particular charge. Draft 0.1 specifies identity, sessions, account access, and business interaction; it does not define an end-to-end payment protocol.

The crucial boundary in Poppy is between permitted access and an approved transaction.

Poppy Draft 0.1 defines account scopes such as poppy:read and poppy:write, but it leaves payment support outside the core specification. The optional operations extension can represent specific action terms and confirmation, including actions with financial effects. Neither mechanism supplies payment credentials, universal checkout support, or overrides merchant transaction controls.

A consumer should therefore ask three separate questions about any agent-enabled purchase: Can the agent access this business? Can it initiate the requested action under the granted permissions? And what specific checkout and payment authorization will the merchant accept?

Read access, write access, and purchase approval

Read access can allow an agent to inspect order details. Write access may allow a supported exchange or booking amendment. A purchase may introduce additional obligations: payment credentials, total price, taxes, merchant risk decisions, and a final confirmation. Those obligations are not erased because the interaction starts in a natural-language conversation.

The optional operations extension adds a more precise model for confirming a stated action, which is important when a price, flight, or cancellation fee can change during execution. Its approval logic can reflect a decision by the user or permission previously given. An implementation still has to communicate meaningful limits and obtain whatever authorization the transaction requires.

What happens before a payment is made?

There is no universal Poppy checkout sequence in Draft 0.1. Payment may be handled through a merchant's existing checkout or a separate compatible commerce and payment flow, if one is actually supported. Poppy's own roadmap identifies payment extensions as an open topic, alongside push notifications and message attachments.

The official Path to 1.0 roadmap explicitly lists these unresolved areas and warns that revisions can break compatibility before a stable specification. Claims that Poppy already allows automatic purchases across all retailers would therefore confuse intended future interoperability with deployed functionality.

Risks that the protocol does not eliminate

Recognizing the agent is a useful security improvement, but it is not a substitute for sound authorization. A compromised account token, excessive permissions, erroneous agent interpretation, or a misleading business interface can still lead to unwanted actions. The business must enforce access controls, and the agent must accurately distinguish proposals, approvals, and completed outcomes.

Consumers should also examine how an agent handles sensitive account information, how permissions are revoked, and whether the business provides a human escalation path. A protocol can standardize interaction; it cannot independently prove the quality of a model's reasoning or the fairness of a company's policies.

Poppy vs MCP, UCP, ACP, AP2, and PACT

These names sound interchangeable because they all appear in discussions of agentic AI. They answer different questions. Poppy focuses on how a personal agent establishes an authorized relationship with a business. Other specifications focus on exposing tools, organizing shopping interactions, or authorizing payments. Some may be used in the same workflow rather than replacing one another.

Poppy's specification explicitly lists MCP as a possible remote API type. That does not make an MCP server a Poppy implementation automatically; the business must also support the session, token, and discovery requirements that Poppy defines. Similarly, a checkout standard is not proof that a personal agent has permission to alter a customer account.

The practical distinction is whether a system can discover an interface, invoke a tool, access a particular customer's data, or complete a financial transaction. Each step raises a different technical and legal question, so calling all of them “agent protocols” hides useful differences.

Who Is Building Poppy, and Is It Available in 2026?

Sierra, Meta, and the design partners

Sierra and Meta publicly announced Personal Agent Protocol on October 6, 2026. Sierra's October 9 post then published Draft 0.1, gave the protocol its short name Poppy, and named 35 additional design partners. The companies span personal AI agents, banking, travel, commerce, payments, identity, and enterprise software.

For example, the expanded list includes OpenAI, PayPal, Visa, Mastercard, United Airlines, Target, and Cloudflare. Their inclusion signals participation in design discussions, not evidence that all products associated with those companies already accept Poppy sessions. The dated Draft 0.1 announcement from Sierra is the appropriate source for that distinction.

Draft 0.1 is a proposal, not universal deployment

As of October 16, 2026, the official documentation identifies itself as Draft 0.1. It invites implementations and feedback; the roadmap notes that interfaces may change incompatibly before version 1.0. Reference implementations, broader partner deployment, and stable cross-company compatibility should not be assumed from the existence of an open specification.

Companies also retain discretion. They can choose supported channels, restrict permissions, require prior client registration, or block agents that misuse access. Poppy is designed to define how cooperation works when a company participates, rather than forcing every business to serve every personal agent.

Can you use Poppy with Muse or ChatGPT today?

Neither participation in the design process nor a public demonstration establishes general end-user Poppy support. Sierra showed a Muse-and-Rocket workflow, but that does not document a universal Muse feature that consumers can enable at every bank, airline, or retailer. Likewise, OpenAI's name on the design partner list is not a statement that ChatGPT supports Poppy across arbitrary sites.

The useful consumer question is currently which AI tools can accomplish a particular errand through their available browsers, connectors, and approvals. For that separate task, compare personal AI agents for everyday tasks. Poppy could improve interoperability over time, but an agent's real-world capabilities still depend on released integrations and supported businesses.

Personal Agent Protocol FAQ

Is Poppy an AI app you can download?

No. Poppy is a published draft protocol for AI agents and participating businesses to implement. It is not a standalone assistant, browser, or consumer shopping app. Users would encounter its capabilities through compatible products and businesses rather than through a universal “Poppy” application.

Is Poppy the same as Personal Agent Protocol (PAP)?

Personal Agent Protocol is the protocol's formal name, and Poppy is its documented short name. “PAP” may appear as an informal abbreviation, but the official draft calls the standard Poppy. It should not be presented as a separate competing specification.

Does Poppy replace MCP?

No. Poppy can list a remote MCP server as one of the APIs a company offers. MCP provides tool interfaces; Poppy adds company discovery, user-specific session handling, and account permissions around supported routes. An MCP endpoint alone does not provide the full Poppy relationship model.

Can a Poppy-compatible agent purchase something without asking?

The draft does not impose a universal “ask every time” rule, nor does it make every purchase automatically permissible. Any purchase depends on supported merchant functions, granted authority, applicable checkout or payment requirements, and any additional confirmation rules. The optional operations extension supports approval of precise terms or pre-granted permission for specified actions.

Is Personal Agent Protocol open source?

The protocol documentation is publicly available, and the official project invites implementations and contributions under its published licensing and contribution terms. Public specification access is not the same as a mature, widely deployed ecosystem of interoperable implementations.

When will Poppy become widely available?

No verified universal rollout date exists as of October 16, 2026. The protocol authors describe an implementation-and-feedback process before version 1.0. Adoption will depend on businesses, agent developers, security testing, and the resolution of currently open topics such as payments and notifications.

The Bottom Line: What Poppy Changes for AI Agents

Personal Agent Protocol addresses an obstacle that language models alone cannot solve: an intelligent assistant still needs a recognized identity, legitimate account access, and a business willing to accept a specific action. Poppy proposes a shared method for creating that relationship across websites, APIs, and company agents.

The reason to watch Poppy is not the promise of instant, autonomous shopping everywhere. It is the possibility of fewer improvised browser workarounds and clearer boundaries between what an AI agent can ask, what a customer authorizes, and what a business actually agrees to do. Draft 0.1 makes those boundaries more concrete; widespread, reliable operation remains something to prove.