Personal Agent Protocol Lets AI Shop—but Its First Specification Is Pending

In its October 6, 2026 announcement, Sierra introduced Personal Agent Protocol as an open standard being developed with Meta and partners at Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. Its proposed role is to let a customer's personal AI agent identify itself, obtain permission and interact with a business through its website, APIs or company agent. That could support shopping tasks, from checking availability to changing an order, while giving the business a way to recognize the agent and set limits on its actions.

The technical rules are still to come. An October 7 analysis by Metir described the first v0.1 specification as unpublished and due later in October. For developers, the proposed flow gives a direction but lacks the detailed rules needed to build interoperable implementations.

How a customer's agent would get access

The proposed flow starts at a business's website, where an agent would discover what the company offers and begin a session for its user. A guest session may cover a question about stock or a returns policy. An account task would require the customer to sign in on the company's page or use credentials already set up with the personal agent, followed by a choice between read-only and write access.

Customer consent is only one side of that arrangement. The business would define which actions it makes available to agents, so granting write access would not automatically give an agent every action possible on an account. An order change is a useful example of the intended boundary: the customer must authorize the agent, and the retailer must permit that kind of change through a route it offers.

The session is designed around OAuth and would persist across channels. A product question asked as a guest and a later authenticated request could therefore belong to the same visit. The company could serve the agent through its regular web pages, APIs built on standards such as MCP or OpenAPI, or its own conversational agent for a task such as a warranty claim. They are choices for a participating business, rather than a single required integration.

Why recognizing the agent matters

Personal agents often use sites the way people do, loading pages and filling forms; if that fails, they may turn to web chat or a support line. A business receiving those interactions has a practical identity problem: an automated visitor might be acting for a customer, but the site needs to know whose authority it carries and which operations the customer and business have allowed. The proposed session would make that relationship explicit at the point of access.

Visibility also changes how a business can handle the transition from a public question to an account action. Checking whether an item is available may be possible without sign-in; changing a purchase requires customer authentication and a permitted operation. Carrying the session across a website, an API and a company agent is meant to preserve that context when the task moves between routes, rather than forcing each channel to treat the request as a fresh, unexplained visit.

How it fits with OAuth and commerce protocols

OAuth provides the authorization foundation, while the proposed protocol would specify how a personal agent uses that foundation when representing a customer to a business. MCP and OpenAPI concern the interfaces through which an agent can reach a company's APIs. A company agent is another destination for a task; it does not itself establish the customer's grant of authority to the visiting agent. The new proposal puts that grant and the business's limits around whichever route the business offers.

Implicator's reporting quotes Sierra cofounder Bret Taylor saying, “It is kind of chaos until such a standard exists,” and notes that Shopify and Stripe are also involved in other agent commerce efforts. The overlap reflects related work on different parts of a transaction. Commerce protocols can cover discovery, checkout or payment; the announced access design addresses how a business recognizes a customer's agent and what it may see or change while carrying out a task.

That distinction becomes concrete at checkout. Knowing how to hand off payment does not decide whether an agent may view an order history, alter a delivery address or start a return. Conversely, an authenticated session does not by itself provide a payment method or a complete shopping workflow. The proposal places the identity and permission decision before those later operations, with each business retaining control over the services it exposes.

What the first specification must make implementable

The planned OAuth session has been described at a high level, without a public discovery format, message requirements, token rules or a precise mapping from read-only and write access to business actions. It also leaves the mechanics of carrying an agent's authority between a website, API and company agent for the specification to define. Those details matter because two developers can agree on the broad flow yet build systems that cannot recognize each other's requests.

More granular permissions, push notifications and payments without sharing card details are presented as possible extensions, rather than current functions of the proposed protocol. Design workshops and a reference implementation are also planned. The next concrete milestone is publication of the first specification; its text will determine which parts of the announced flow become implementable rules.