Poppy 1.0 asks merchants to define what personal agents can actually do

Public developments and original analysis · Announcement date: 2026-11-13 · Sources

When a customer asks a personal AI assistant to check a merchant’s returns policy, should it read the website, call an API or contact the merchant’s support agent? Sierra released Personal Agent Protocol 1.0, or Poppy, on November 13 to provide shared discovery and interaction rules for that encounter. The immediate business task is to describe existing services clearly enough that an external assistant can find their entry points and access conditions.

Sierra also says Shopify merchants now publish Poppy files and Meta’s Muse checks for the protocol first. These are the publisher’s adoption statements. They do not establish that an agent can complete every merchant’s after-sales work. A discovery file describes an entry point; order lookup, return acceptance and payment handling depend on the services and rules a merchant actually exposes.

Connecting discovery to existing services

The 1.0 specification covers discovery, identity, account access and interaction through APIs, websites and conversations. Companies publish entry points through poppy.json. The specification explicitly says its components are not sequential adoption levels: companies choose their channels. A merchant with an accessible website can begin by describing that channel without building every possible interface.

Consider a hypothetical seller of customized goods that wants assistants to ask about delivery dates and after-sales requests. A public production-time estimate may come from a website; whether one order has entered production requires current order data. Both requests may sound like “check delivery,” but their evidence and access requirements differ. A broad capability label can promise more than the underlying service can provide.

Review existing services by the object being requested. Does a public policy have a clear entry point? Can an account query return the correct customer’s record? Can an action distinguish acceptance from completion? A missing API can leave room for a website or support channel. If support only has general policy information, explain how order-specific details can be obtained. Available fulfillment determines the scope that the discovery file describes.

Multiple channels give assistants a way to follow the company’s intended route rather than guess. They also create maintenance work. A changed web address, API field or support responsibility needs a corresponding update to the discovery information. Without someone owning that work, publishing another file can create another stale source.

Account access and individual actions

Poppy uses OAuth for account access and separates request identity, session continuity and access to an account. Reading a public policy and obtaining permission to inspect one customer’s orders have different requirements. A business can clarify public inquiries first, then expose account functions where demand justifies them. That is an implementation choice, not a mandatory protocol ladder.

For the hypothetical seller, looking up status, requesting an address change and canceling goods already in production have different consequences. Broad permissions spanning all three can give an assistant more authority than its current task requires. A conversational warning cannot compensate for that service design. The executing system should limit which records can be read and which actions can be performed.

Account consent also needs to be distinguished from consent to a particular business action. Permission to access an account grants the relevant access rights; whether an order remains editable depends on its current state and the merchant’s rules. Actions that incur costs, change fulfillment or are difficult to reverse can justify showing the specific object and consequences before obtaining confirmation. Protocol adoption cannot replace those business checks.

The number of exposed actions is therefore a poor early target. Public entry points may be sufficient when demand concerns policies. Substantial account inquiries can justify the ongoing work on identity, sessions, tokens and support. Opening modification functions should follow the service’s error handling and customer-confirmation capabilities, rather than the arrival of a 1.0 protocol label.

Unavailable tasks and transaction status

Poppy’s task-coverage design lets companies list unavailable tasks and alternatives; its conversation channel also defines human handoff. An unavailable service and an individual order that fails a business condition need different explanations. The specification leaves account-dependent restrictions to the response for the actual request.

If the customized-goods seller never accepts a particular alteration through agents, it can identify a human channel that can explain the options. If address changes are supported but one order has shipped, the result should explain that order’s restriction. Reporting every unsuccessful request as “unsupported” leaves customers unsure whether to switch channels, supply information or accept a changed business condition.

Initiation and completion also need separate states. A handoff request does not establish that a person has joined, and a submitted return does not establish approval. The specification says closing a conversation does not cancel orders or returns initiated during it. Business records must continue under their own rules after a customer ends a chat; interface state must not substitute for transaction state.

For an existing online business, a useful starting point is one genuinely frequent service: where the customer enters, when account access becomes necessary, what result is delivered and how a restriction is handled. The official company implementation kit includes a validator, while retaining manual checks such as logging and consent wording. Protocol checks can find implementation gaps; the complete service journey establishes whether the customer’s work is actually handled.

Mokyun Editorial · neo@mokyun.com