Personal Agent Protocol (Poppy): How Your Customer's AI Agent Reaches Your Business
Your customer asks an AI assistant to return a jacket. The assistant can find your store, but then it needs a way into the order without pretending to be the customer or gaining access to everything in the account.
The Personal Agent Protocol, known as Poppy, defines how a person's AI agent discovers a business, identifies itself, signs the person in when needed, and works through the channels that business offers. Those channels can include a website, an API, or the business's own agent. The customer chooses what access to grant. The business decides which actions to offer and enforces those limits.
If you run an agent or service that customers need to find again, HeadlessDomains.com lets you give it a public .agent name connected to its current records and official destinations. The name gives people a reference they can return to even as the software behind your service changes.
Follow the customer through a return
Imagine a customer who wants to return a jacket. They tell their personal agent what happened and ask it to start the return. The agent needs to find the retailer's official route, learn whether returns are supported, and get access to the right order. A password pasted into a prompt or a guess about which support bot is genuine is a poor way to begin.
Under Poppy's draft design, the retailer publishes a discovery document called poppy.json at a standard HTTPS address on its own domain. The document tells a compatible personal agent how to start a session, how the customer can sign in, and which website, API, or company-agent routes are available. The personal agent identifies itself to the retailer. If the return requires account access, the customer signs in and grants the access the task needs.
The retailer then applies its permissions to the work. Looking up an order, starting a return, changing a saved payment method, and issuing a refund are different actions. The company can expose some and withhold others. One session can carry the customer's interaction across the routes the retailer supports, so the agent can continue from a website question into an API call or conversation without losing the thread.
A customer can send an agent to get something done while the business knows an agent is calling and keeps control of what it can do. Poppy's specification remains a draft, and its details can change before version 1.0. A clear customer task and permission boundary give you a useful place to start.
Publish a route the customer's agent can find
Poppy starts with the business's HTTPS domain. A company implementing the protocol publishes /.well-known/poppy.json there. The file identifies the company's sign-in route and the channels it offers to personal agents. That might be the existing website, an OpenAPI or MCP interface, the company's own conversational agent, or a mix that matches the work customers bring to it.
The file gives the agent a route. The business still verifies the caller, connects account access to the customer's sign-in, and enforces the allowed actions in the receiving application. A product lookup may need no account access. A return against an order requires more. A payment or change to sensitive account details may require a separate decision.
Start with one customer task that already reaches your team: checking an order, changing a booking, requesting a warranty repair. Write down what an agent can learn before sign-in, what needs the customer's account, what needs approval, and where a person takes over. That gives the protocol a real job to serve.
Give the service a name worth returning to
Poppy's discovery document lives at an HTTPS address on the company's domain. The business implements that route and the account permissions behind it. Headless Domains gives the agent or service a public name people can use outside that one interaction.
Now consider what the customer sees after the return. Which agent or service handled it, and where can they find that same service next month? A Headless Domains .agent name can connect a business-facing agent to its operator information, public profile, machine-readable records, and current service destinations. Compatible software can inspect those records through the maintained API and command-line infrastructure. The name stays familiar as the service behind it changes.
Suppose a retailer runs a returns assistant and later moves its conversation service or replaces an API. The Poppy document must still point compatible personal agents to the current business routes. The returns assistant's public name can keep pointing people and other agents to the current service information. Keep both records accurate, and the customer does not have to learn your internal rebuild.
Read the Agent Identity Stack guide if you want to connect public names with records, credentials, and permissions. Poppy addresses a particular encounter: a personal agent arriving on behalf of a customer with a job to finish.
Four pieces of the same encounter
An agent's visit crosses more than one boundary. These names come up together because each one helps with a different part of the customer's task.
| Interface or protocol | What it helps answer |
|---|---|
| Poppy | How does a personal agent find a business, identify itself, obtain customer access, and work across the business's offered channels? |
| PACT | How can a personal agent and a business agent exchange requests with explicit, verifiable customer consent? Decagon's PACT work builds on A2A and OAuth. |
| MCP and A2A | How does software call tools, or how do agents exchange tasks and results? The MCP vs A2A guide covers that choice in detail. |
| Headless Domains | What public name and maintained records help people and compatible agents recognize the agent or service behind the interaction? |
PACT's authors have joined the Poppy design effort. The two efforts may influence each other as the drafts develop. For your own service, begin with the customer task and choose the interfaces and permissions that let the customer finish it.
Try it with one customer task
- Choose work customers already bring you. A return, booking change, or service appointment gives you something real to test.
- Mark the access boundary. Separate public information from account data and actions that change an order, spend money, or disclose sensitive details.
- Find the working route. Can your website, API, or company agent complete the task today? Decide which route you want a compatible personal agent to discover.
- Name the service customers will recognize. If you run a public-facing agent, connect its Headless Domains record to the correct operator and current destination. Keep the name useful when the software changes.
- Test the whole trip. Ask a compatible test agent to find the business route, request only the access needed, complete an allowed action, and stop at a disallowed one. Watch what the customer sees at each decision.
If you implement Poppy, build against a named version and follow its published changes. Then test what the customer experiences: did the agent reach the right business and account, take only the allowed action, and return a clear result?
Common questions
Does Poppy replace MCP or A2A?
No. A business can list an MCP interface in its Poppy discovery document, and Poppy can also lead a personal agent to a company agent for conversation. MCP and A2A address ways software interacts after it finds the service. Poppy addresses the personal agent's relationship with the business and the customer account.
Does a Headless Domain automatically make a business Poppy-compatible?
No. Poppy requires the business to publish its discovery document on its HTTPS domain and implement the sign-in, session, and permission behavior it offers. A Headless Domain gives an agent or service a public name and records that compatible software can inspect. Link the public name to the working service and maintain both.
Does Poppy let a personal agent do anything after the customer signs in?
No. The business defines the available routes and enforces access for each action. The customer grants access for the work they want done. A signed-in agent still has to stay within those limits.
People already ask assistants to handle ordinary work: finding an order, asking a question, changing a booking, finishing a return. Give the service on your side a name they can recognize and records that lead to the right destination. Explore a .agent name at HeadlessDomains.com, then connect it to the agent or service you run.
Once you have a name, watch What to Do After Registering a Headless Domain: 7 Next Steps for the work that makes it useful.