Blog · Agent protocols
Poppy (Formerly PAP): Why Personal Agent Protocol Matters to Businesses
Poppy (formerly PAP) is a proposed standard for personal AI agents to connect with businesses. Learn how discovery, sign-in and permissions work.
Maintained by：Frontvia · Published · Updated
Imagine a customer tells their personal AI agent: My flight has been cancelled. Find another flight, keep me within my budget, and check the options before I confirm.
The agent may understand the request perfectly. But understanding a task is not the same as being allowed to carry it out.
The airline needs answers to a different set of questions: Which agent is contacting us? Is it acting for a real customer? What has that customer authorized? Which account can it access? When must it ask for confirmation?
These are not questions a better language model can answer on its own. They require rules that are understood on both sides of the interaction.
That is the industry problem behind the Personal Agent Protocol—initially known as PAP and now commonly called Poppy.
Why personal AI agents need a business-side protocol
Much of the internet was designed for people navigating websites.
A person can recognize a brand, sign in, read a product page, click through checkout and contact support. A personal agent can attempt many of those steps through a browser, but the business may not know whether the visitor is an authorized agent or what the customer intended.
Giving an agent unrestricted access to a customer’s account would create its own problems. Blocking all automated access prevents useful tasks from being completed.
The more interesting possibility lies between those extremes: a company publishes how agents may interact with it, and the customer grants the specific access needed for a task.
Poppy is an attempt to make that relationship work through a common protocol.
Sierra and Meta announced the initiative in October 2026. The published Draft 0.1 appeared on October 9; the official documentation is developing Draft 0.2. The specification is evolving, and publication of a draft does not mean that every personal agent or business platform already supports it. See the official protocol specification.
First, a terminology clarification: What is a “PAP agent”?
PAP stands for Personal Agent Protocol. It is not a separate category of AI agent.
A personal agent works for an individual. A business or enterprise agent represents a company. Poppy describes ways those two sides can discover one another, establish a session and interact under the right permissions.
You may see people say “PAP agent” to mean an agent that implements the protocol. That is shorthand, not a formal distinction between personal and business agents.
The name Poppy is important for search and documentation: earlier articles use PAP, while the newer project materials use Personal Agent Protocol or Poppy. Both names refer to the same initiative.
Five building blocks of an agent-to-business relationship
The protocol’s design can be understood without reading its wire-level details.
1. Discovery: Find the official business entrance
Before an agent sends a sensitive request, it needs to know how a company expects to be contacted.
Poppy defines a discovery document at /.well-known/poppy.json on the company’s domain. The document advertises relevant endpoints and interaction choices.
This is more useful than asking an AI model to guess which form, API or third-party account is the official one.
Discovery is only the beginning, however. An official endpoint is not proof that a visitor has permission to access a private customer account.
2. Sessions: Recognize an ongoing visit
An agent may first ask a public question—whether a product is available or whether a booking can be changed.
That question does not necessarily require sign-in. A session can start with limited, guest-level interaction and progress when more access is needed.
The company can recognize that it is dealing with an agent and maintain context across parts of the journey.
3. Sign-in and authorization: Keep the customer in control
Suppose an agent needs to read a customer’s flight reservation or order history.
The company must authenticate the relevant customer and determine what the agent is allowed to do. Poppy builds on OAuth, an established authorization framework, rather than asking the customer to disclose a password to every agent or service.
Crucially, identifying the agent does not automatically authorize the agent to act for the customer.
The business sets the available permissions. The customer approves the access they want to grant. Read access, account changes and higher-risk actions need distinct checks, even when the same agent is involved.
4. Multiple channels: Use the website, API or business agent
Not every business needs to create a conversational AI agent from scratch.
The Poppy design allows companies to offer interaction through existing websites, APIs or an agent of their own. API interfaces may use standards such as MCP or OpenAPI.
That flexibility matters. A small retailer might begin with product and order-status interfaces. A travel provider may already have reservation APIs. A service company might prefer to handle complex exceptions through a business agent or a human employee.
The common requirement is that access permissions continue to apply when the channel changes.
5. Outcomes: Complete the task and preserve accountability
The goal is not simply to create a conversation between two AI systems.
The customer wants something done: a delivery question answered, an order located, a return started or a booking changed.
The company needs a reliable record of what was requested, what was approved, which system handled it and what result came back.
The protocol can help define the interaction, but the underlying business systems still own the actual transaction and its correctness.
A simple example: Returning a pair of shoes
Consider this possible future interaction:
- A customer asks their personal agent to return an item purchased from an online store.
- The agent discovers the store’s official Poppy entrance and checks the public returns policy.
- The store identifies the agent and starts a session. The customer signs in through the store’s authorized flow when order access is needed.
- The customer grants the permitted access to the relevant order.
- The agent requests a return. The store checks its rules and asks for any required confirmation.
- The store’s order or returns system creates a reference, which the personal agent reports back to the customer.
Notice the separation of responsibilities:
The customer owns the decision. The personal agent carries the request. The business controls its rules and account access. The business system confirms the result.
This is an illustrative workflow, not a claim that all participating platforms already provide an interoperable end-to-end return service.
How is Poppy different from MCP, A2A and commerce protocols?
It is tempting to treat every new agent standard as a competitor to every other one. In practice, their focus differs.
| Protocol | Primary question it addresses |
|---|---|
| Poppy / PAP | How does a personal agent establish a permitted relationship and interact with a business for a customer? |
| MCP | How can an AI application access tools, resources and capabilities? |
| A2A | How can agents communicate and coordinate tasks with one another? |
| UCP | How can participants express commerce capabilities such as shopping and checkout? |
| ANP | How can agents use an open network for identity, discovery and communication? |
These are simplified boundaries, not claims of automatic compatibility. A business still has to implement the relevant endpoints, security model and workflows.
For example, an MCP endpoint may expose an order lookup, but the surrounding business relationship must still answer which customer’s order the caller may look up. A commerce protocol may define checkout operations, but a business must still validate prices, availability, payment status and the required approvals.
Poppy’s value proposition is the relationship and authorization layer between a customer’s agent and a business across different ways of working.
What the protocol does not guarantee
Early standards can create excitement well before deployment catches up. It helps to distinguish four claims:
- Specification support: An implementation follows a particular draft version.
- Interoperability: It has been tested end to end with a named personal-agent client.
- Distribution: The relevant platform can actually discover or route users to that business.
- Business results: Customers use the path and complete real, authorized tasks.
Passing the first milestone does not guarantee the next three.
Poppy is also not itself a payment processor, a product search engine or a promise of traffic. Shopping, payments, refunds and fulfilment still require the company’s operational systems and any applicable commerce integrations.
As of this article’s publication, the specification remains a draft. Developers and merchants should verify the current version before making interoperability claims.
What should a business do now?
A business can prepare for agent-led interactions before choosing a specific implementation.
Start with a single real workflow. Public product questions, an authenticated order enquiry or a customer-approved return request are useful examples.
Publish trustworthy information. Product details, policies and operating rules should have identifiable owners and update paths.
Design permissions around actions. “The customer signed in” is insufficient by itself. Identify which read and write operations are allowed and how authorization can be withdrawn.
Connect to the system of record. Order updates, inventory checks, payments and service tickets should reflect real systems rather than conversational guesses.
Demand clear evidence of interoperability. Ask which protocol draft, which agent client, which business action and which approval path were tested.
The broad goal is simple: make it possible for customers to send the agent they trust without forcing the business to surrender control of its accounts, data or operations.
Frequently asked questions
Does a company need to build its own AI chatbot to support Poppy?
No. The protocol’s design allows a company to provide website access, APIs or an agent of its own. The suitable path depends on the business task and the access controls it can enforce.
Does Poppy replace MCP?
No. MCP can provide tools and data interfaces; Poppy addresses the broader relationship between a personal agent, its customer and a company. A company may choose MCP as one of its permitted interfaces.
Does using Poppy mean that an AI agent can automatically pay for things?
No. The protocol does not by itself provide a payment network or remove the need for customer authorization, payment integration and merchant-side transaction checks.
A more open front door for business
Personal AI agents could change how people seek help from companies. Rather than discovering a service and then completing every step manually, a person may increasingly ask an agent to coordinate the journey.
For that experience to be safe and useful, businesses need more than AI-generated answers. They need discoverable entrances, explicit permissions, accurate information and accountable outcomes.
Poppy is an important attempt to establish those shared expectations. The specification and adoption still have work ahead, but the problem it addresses is real.
Frontvia is exploring official, business-controlled entrances for customers’ personal agents. Its planned PAP/Poppy integrations are subject to protocol and client-specific validation, and live commerce outcomes are not yet claimed.
Merchants interested in evaluating a real use case can learn about Frontvia, read the business guide to PAP/Poppy or request an early pilot conversation.
Further reading
Continue exploring
Choose the next step for your business.
Understand the roles, then choose between connecting a store and creating an agent-native storefront. Frontvia is in development; pilot scope will be agreed around real needs.