A personal agent meets a business
A customer wants to know when an order will arrive or exchange an item. Their personal agent needs a way to reach the merchant, communicate the request and, where necessary, access the customer account. Today each business has its own interfaces and rules for that work.
On November 13, Sierra announced version 1.0 of the Personal Agent Protocol, known as Poppy. It describes how a personal agent can work for a person with a business through its website, APIs or company agent. Sierra originally announced Poppy with Meta and other partners.
Sierra calls this the 1.0 release. The linked technical specification also labels itself Draft 1.0 and says fixes can include incompatible changes. Teams implementing it should check the actual specification they are building against.
What happens when an agent arrives
A business publishes a file at `/.well-known/poppy.json`. The specification says an agent can use it to discover available routes and sign in methods. The subsequent interaction can take place through a website, an API or a conversation with the company’s agent.
Poppy uses OAuth for account access. The business describes permissions and the customer can decide on the requested access during sign in. Reading and changing are different tasks. An agent checking delivery status does not automatically need the same rights as one requesting an exchange.
Imagine a customer asks for a jacket in a different size. Their agent first needs to find the right order and then check which sizes are available. Whether it can initiate a change depends on the offered functions, the permissions granted and the applicable approval flow. The protocol alone confirms neither stock nor a successful return.
How Poppy and UCP fit together
Poppy describes access and collaboration between a personal agent and a business. Sierra says a commerce extension connects it to the Universal Commerce Protocol: UCP handles tasks such as product selection, baskets and checkout. The protocols address different parts of the journey.
In How protocols become a purchasing journey, I look at how components come together around an offer, payment and service. A shared standard helps, but it does not replace a working stock check, a valid price or a decision about who can approve an action.
What has been announced
Sierra says Meta’s personal agent Muse looks for Poppy first on sites it visits. Sierra also names Mercury and Turkish Airlines as examples. It describes Mercury offering account information and initiating payments or transfers subject to the account’s approval policy. For Turkish Airlines, it names flight information, booking lookup and upgrade searches, with customers approving payment.
These are the provider’s descriptions of specific uses. They do not establish that every agent can reach every merchant or that each business offers the same functions. The announcement does not describe general Shopware support.
A practical first test
I would start with a bounded service question: where is my order? A team can check how the agent discovers the route, what it can learn without signing in, and how a customer grants and revokes account access. A change such as an exchange can follow after that.
The guide to shopping agents, merchant agents and copilots distinguishes whose task each agent carries out and what information it needs. That distinction matters here too: the personal agent acts for the customer, while the merchant remains responsible for its own offers, permissions and service processes.
Security depends on the protocol and its implementation working together. Publishing a document does not by itself protect an account or guarantee that a task succeeds. Verified identities, appropriate permissions, understandable approvals and a clear way to handle failures all matter.
Source and further reading
Read the original announcement ↗