Personal Agent Protocol: What Sierra and Meta's PAP Means for Brands

What Is the Personal Agent Protocol?

The Personal Agent Protocol (PAP) is an open standard that defines how personal AI agents interact with businesses. Meta and Sierra announced it on October 6, 2026, alongside industry partners Genesys, Instinct, Rocket, Shopify, Stripe, and Walmart, and designed it to handle authentication, keep consumers in control, and give companies visibility into what agents do across their websites, APIs, and company agents. It is open for anyone to implement. Source: Sierra

• Who is behind it: Meta and Sierra are developing PAP with launch collaborators Genesys, Instinct, Rocket, Shopify, Stripe, and Walmart, and the standard is open for any company or agent builder to adopt.
• What it governs: PAP covers how a personal agent authenticates on a user's behalf and the terms under which it can read information or take action with a business.
• Who announced it: Sierra co-founders Bret Taylor and Clay Bavor published the announcement, framing PAP as the foundation for an era when consumers routinely send agents to act for them.
• What it is not: PAP is not a product or one company's private API. It is a shared specification, with a v0.1 draft and a reference implementation promised for later in October 2026.

For businesses, PAP reframes the question from whether AI agents will arrive to how a company recognizes them when they do. Rather than forcing every brand to build a bespoke integration for each agent platform, PAP proposes one consistent way for a personal agent to identify itself, prove what it is authorized to do, and get work done. Source: Sierra

What Problem Does PAP Try to Solve?

PAP exists because personal agents today mostly use websites and apps the way people do, loading pages and clicking through forms, and fall back to a company's support line or web chat when that fails. Sierra argues this is slow and can leave the task unfinished, while a direct connection could complete the same job securely in seconds. Source: Sierra

The gap is not hypothetical. When an agent cannot finish a task through the interface, it either abandons the job or escalates to a channel built for humans, where it waits on hold or types into a chat widget never designed for a machine. Every one of those detours is slower and more failure-prone than a direct, authorized connection, and each one hides from the business the fact that an agent was involved at all. Source: Sierra

To be adopted at scale, Sierra says that connection has to serve three groups whose needs pull in different directions:

• Consumers want speed and trust: they want the job done right the first time by an agent they can count on to act in their best interests, not a bot that stalls in a phone queue.
• Brands want visibility and control: they need to know when an agent is acting for a real customer and to decide for themselves what that agent is allowed to do.
• Agent builders want efficiency and access: the companies building personal agents want one direct, consistent way to work with every participating business instead of scraping each site.

The design goal is a single connection that works for all three at once, because a standard that serves only the agent or only the brand will not reach scale. That tension, speed for the consumer set against control for the business, is the core problem PAP tries to resolve with one shared set of rules. Source: Sierra

How Does the Personal Agent Protocol Work?

A PAP interaction begins on the company's website and runs through an OAuth session that carries across channels. The personal agent first discovers what the company offers and how to reach it, then opens a session for its user, either as a guest or signed in. A guest session may be enough to check product availability or ask about a returns policy, and when a task needs account access the customer signs in and decides whether the agent gets read-only or write access. Source: Sierra

From there, the company chooses which of three routes the agent uses to get the job done:

• Through its website: the agent navigates the company's regular web pages, the same surface a human visitor uses, when that is the best path.
• Through its APIs: the agent connects to interfaces built on established standards such as MCP and OpenAPI, giving it a structured, machine-readable route into the business.
• Through its own agent: the company can route conversational tasks, such as a warranty claim, to an agent of its own that works directly with the personal agent.

A simple errand shows the shape of it. A shopper's agent lands on a retailer's site as a guest to confirm a jacket is in stock and check the returns window, then the shopper signs in so the agent can start a return on an existing order. Because the session persists, the retailer sees one authorized visit rather than two disconnected bots, and it decides whether that return runs through its website, an API, or its own support agent. Source: Sierra

Because the session is built on OAuth and persists across channels, a question asked as a guest and an account change made after sign-in count as one visit. The company decides what it exposes, the personal agent gets a consistent way to connect, and the customer gets a faster path to the outcome. Source: Sierra

Why Does It Matter That Personal Agents and Company Agents Meet Here?

PAP is interesting less for any single feature than for the handshake it formalizes: the point where a consumer's personal agent meets a business and its systems. Sierra's announcement draws a clear line between the personal agent acting for a shopper and the company's own website, APIs, or agent acting for the business, and PAP is the contract that lets the two sides work together on terms each one sets. That is a different problem from moving a payment or listing a product. Source: Sierra

Two sides, one connection. The consumer side brings intent and authority, since the personal agent knows what its user wants and carries the permission to act. The business side brings the catalog, the account, and the rules. PAP defines how those meet so neither side has to guess about the other, which is why Sierra frames it as handling authentication and visibility rather than commerce.

A coalition that spans the flow. The named partners are not arbitrary. Shopify and Walmart bring merchants and catalog, Stripe brings payments, Genesys brings contact-center and support, and Rocket brings a regulated financial workflow. Between them they cover most of what a personal agent would actually try to do on a business's behalf, which is what a connection standard needs to be tested against.

A standard, not a walled garden. Because PAP is open for anyone to implement, a business is meant to support it once and become reachable by any compliant personal agent, rather than negotiating a separate deal with each AI platform. That is the same promise MCP made for tools, applied to the consumer-to-business relationship. Source: Sierra

How Does PAP Compare to ACP, UCP, MCP, and A2A?

PAP sits at a different layer from the agentic commerce protocols it will share a page with. It governs identity, authorization, and routing between a consumer's agent and a business, and it explicitly builds on OAuth for authentication while naming MCP and OpenAPI as API routes. The commerce and payment standards, by contrast, define how a purchase or a payment is structured once an agent is already connected. Source: Sierra

Protocol	What it standardizes	Layer in the agent stack	Created by
Personal Agent Protocol (PAP)	How a consumer's agent identifies itself and connects to a business	Identity, session, and channel routing	Meta and Sierra (2026)
Model Context Protocol (MCP)	How agents connect to tools and data sources	Transport and context	Anthropic (2024)
Agent2Agent (A2A)	How independent agents discover and delegate tasks to each other	Agent-to-agent transport	Google (2025)
Agentic Commerce Protocol (ACP)	Product discovery and delegated checkout inside assistants	Commerce and checkout	Stripe and OpenAI (2025)
Universal Commerce Protocol (UCP)	The full shopping lifecycle across any AI surface	Commerce lifecycle	Google with retail partners (2026)
Agent Payments Protocol (AP2)	Verifiable, mandate-based payment authorization	Payment authorization	Google (2025)
x402	Internet-native, HTTP-based machine payments	Payment settlement	Coinbase, now the x402 Foundation

Read together, this shows PAP is a complement, not a competitor, to the commerce stack. Stripe, Shopify, and Walmart each appear across several of these efforts, Stripe on ACP, all three on UCP or PAP, which signals that the same companies are standardizing different parts of one flow. PAP also leaves payments to a future extension, so it overlaps with ACP or AP2 only at the edges rather than replacing them. Source: Sierra

Each standard in the table is defined by its originator's own documentation, which is where the details above are specified. Anthropic (MCP), Google (A2A), Stripe (ACP), Google (UCP), Google (AP2), Linux Foundation (x402)

The overlap is worth watching rather than fearing. A business that already supports ACP for checkout or exposes an MCP server is not starting over for PAP, because PAP reuses those same routes. The risk is not redundant work but fragmented identity, where each protocol authenticates an agent its own way, and that seam is exactly what PAP is trying to own. Source: Sierra

What Does PAP Mean for Agent-Ready Businesses?

The most important detail for businesses is where PAP begins: on the website. In Sierra's design the personal agent starts on the company's site to discover what it offers and how to reach it, which means the same work that makes a site legible to AI agents is the foundation PAP builds on. A site an agent cannot read is a site PAP cannot start on. Source: Sierra

• Discoverable, structured content: an agent has to understand your offers, policies, and inventory from the page itself, which rewards clean structured data and machine-readable content over visual-only design.
• Real API routes: PAP names MCP and OpenAPI as its API channels, so publishing a working MCP server or an OpenAPI description is directly on the path to supporting it.
• Scoped, standards-based auth: PAP sessions run on OAuth with read-only or write scopes, so an OAuth setup that grants limited, revocable access is groundwork rather than throwaway work.
• Clear, current answers: an agent acting as a guest asks about availability, shipping, and returns before anything else, so accurate, machine-readable policies and inventory are the difference between a completed task and a dead end.
• One investment, many protocols: the same legibility that serves PAP also serves ACP, UCP, and MCP-based assistants, so agent-readiness compounds across standards instead of being rebuilt for each.

None of this is speculative infrastructure. Structured data, an OpenAPI description, and an OAuth flow are mature, well-documented building blocks, and a business that has them is already most of the way to being reachable by PAP, by ACP, and by any MCP-based assistant. The specification will set the exact discovery file and scopes, but it will not change the fact that an unreadable site is the one failure no protocol can route around.

This is why the proliferation of protocols is less daunting than it looks. A business cannot reliably bet on which standard wins, but it can make its site and services legible to agents once and satisfy the shared requirements underneath PAP, ACP, and the rest. Agent-readiness is the common denominator, and it is buildable today. Source: Sierra

What Comes Next for the Personal Agent Protocol?

PAP is early. Sierra and Meta plan to publish the v0.1 specification later in October 2026, host design workshops with interested parties, and release a reference implementation to help developers start building. Instinct is joining the effort, and the group says it welcomes more partners. Source: Sierra

• A v0.1 specification: the first draft is promised for later in October 2026 and will be the first place the discovery format, session details, and scopes are defined in full.
• Design workshops and a reference implementation: Sierra plans working sessions with adopters and sample code, which is how the practical shape of PAP will be set.
• Granular permissions: a planned extension would let customers and companies set limits on specific actions, beyond today's single read-only or write choice.
• Push notifications: a future version could let a company tell an agent the moment a flight is delayed or an order ships, rather than waiting to be asked.
• Payments extensions: Sierra describes a path for an agent to complete a purchase without sharing credit card information, which is where PAP would meet the payment protocols directly.

Three questions will decide how much PAP matters in practice: whether the discovery format is something a business can publish once and forget, whether the OAuth scopes are granular enough for brands to trust an agent with write access, and whether the major personal-agent platforms actually implement it instead of keeping their own private integrations. The v0.1 draft and the reference implementation are where those answers start to appear. Source: Sierra

What is not yet public matters as much as what is. Until the v0.1 specification lands, the exact discovery mechanism, the shape of the OAuth scopes, and how PAP will interoperate with ACP or AP2 are open questions. That makes the next few weeks the moment to put the durable groundwork in place rather than to wait for a finished standard. Source: Sierra