The Personal Agent Protocol, Explained: What Sierra and Meta Shipped, and What Your Support Stack Has to Expose
The Personal Agent Protocol (PAP) is an open, OAuth-based standard for how a consumer's personal AI agent finds a business, signs in with the customer's consent, and acts on their behalf. Sierra and Meta announced it on 6 October 2026, and a Draft 0.1 followed three days later.
TL;DR: PAP's Draft 0.1 standardises discovery, agent identity and OAuth sign-in, but per the draft overview it leaves per-action permissions and audit undefined — so the hard work lands on the helpdesk and CRM you already run.
Methodology & sources
- Primary sources: Sierra's announcement and draft post, the PAP docs, Decagon's PACT post, and the MCP, A2A, AP2 and WebMCP specifications.
- Meta's partner list is taken from CMSWire's report; Meta's own post blocks automated reading.
- All facts verified 13 October 2026. This page will be updated as the draft moves.
- Disclosure: this is Aissist's blog. Aissist sells an AI operational layer that runs on existing helpdesks, and Sierra competes with us.
What is the Personal Agent Protocol, and how does a session work?
PAP is a shared handshake: one file tells agents what a company allows, OAuth lets the customer grant read or write access, and one token then works across the company's website, APIs and its own agent. Sierra's draft post, signed by Bret Taylor and Clay Bavor, nicknames the protocol "Poppy."
A session runs in four steps:
- Discovery. The company publishes
/.well-known/poppy.json, describing how agents may interact, how customers sign in and what an agent can do. - Guest session. The agent opens a session and identifies itself. Until sign-in, the PAP docs say the company sees only an ID with no personal information, and that ID differs at every company.
- Sign-in. For account tasks, the customer signs in on the company's own page via OAuth and chooses view access, change access, or both. Access is revocable.
- Action. The agent works through whichever channel the company offers: its website, its APIs (OpenAPI or MCP), or its own agent.
The pitch to businesses is economic: connect once, rather than once per personal agent. The pitch to consumers is speed. Today a personal agent clicks through your checkout like a very patient intern; a direct connection does the same job in seconds.
"Brands need a trusted way to know who an AI agent represents." — Tony Bates, Chairman & CEO, Genesys, in Sierra's announcement
Note what the session gives a business: who the agent is and what the customer agreed to. It does not tell you whether this particular refund should go through.
What has actually shipped, and when?
A draft has shipped; a finished standard has not. Sierra promised a v0.1 within October when it announced PAP on 6 October, published the draft on 9 October, and the docs carried a Draft 0.1 label by 13 October. Workshops and a reference implementation come next.
| Date | Event | Primary source |
|---|---|---|
| 16 Sep 2025 | Google announces AP2, the Agent Payments Protocol | ap2-protocol.org |
| 6 Oct 2026 | Sierra and Meta announce PAP; v0.1 promised for October | Sierra |
| 6 Oct 2026 | Decagon open-sources PACT and joins the PAP working group | Decagon |
| 7 Oct 2026 | NiCE says it is co-developing PAP with Meta | IT Brief |
| 9 Oct 2026 | Sierra publishes the draft ("Poppy") | Sierra |
| 9 Oct 2026 | WebMCP Community Group draft updated | W3C WebML CG |
| 13 Oct 2026 | PAP docs labelled Draft 0.1 | PAP docs |
| Next month | Design workshops and a reference implementation | Sierra |
The draft names no standards body and no governance process. Sierra's announcement lists finer-grained action permissions, push notifications and payments as possible extensions — all future tense.
Who is backing PAP, and why do the partner lists disagree?
The three founding announcements name overlapping but different companies: Sierra lists Instinct, Meta lists NiCE and Decagon instead. Five partners — Genesys, Rocket, Shopify, Stripe and Walmart — appear on every list.
| Company | Sierra post, 6 Oct | Meta list, per CMSWire | Stripe post, per eesel |
|---|---|---|---|
| Genesys | Yes | Yes | Yes |
| Rocket | Yes | Yes | Yes |
| Shopify | Yes | Yes | Yes |
| Stripe | Yes | Yes | Yes (founding) |
| Walmart | Yes | Yes | Yes |
| Instinct | Yes | No | Yes |
| NiCE | No | Yes | No |
| Decagon | No | Yes | No |
The likeliest explanation is mundane: the working group grew between drafting and posting. Either way, two of Sierra's direct competitors in customer-service AI, Decagon and NiCE, are now in the room. Contact-centre vendors clearly read PAP as a support-channel event, not a commerce one.
"Personal agents already work for consumers." — Philipp Heltewig, Chief AI Officer, NiCE, via IT Brief
Absent from every list: Zendesk, Salesforce, Intercom, Google, OpenAI and Anthropic. A standard for how agents enter a business, without the companies that host most support queues, is still a proposal.
How does PAP compare with MCP, A2A and AP2?
Each protocol answers a different question: PAP asks who the agent represents and what the customer allowed; MCP connects an agent to tools; the agent to agent protocol (A2A) lets agents talk to agents; AP2 proves a payment was authorised.
| PAP | MCP | A2A | AP2 | |
|---|---|---|---|---|
| Question it answers | Who is this agent, and what did the customer allow? | How does an agent call my tools and data? | How do two agents exchange tasks? | How do I prove this purchase was authorised? |
| Status (Oct 2026) | Draft 0.1 | Spec 2026-07-28 | Linux Foundation project | v0.2 |
| Led by | Sierra, Meta | LF Projects (Linux Foundation) | 8-company steering committee | Google; FIDO Alliance groups |
| Consent model | OAuth sign-in; view, change or both | OAuth 2.1, optional | Schemes declared per agent (OAuth 2.0, OIDC, mTLS) | Signed checkout and payment mandates |
| Per-action audit | Not in draft | Not defined | Not defined | Chained mandates form an audit trail |
Sources: MCP authorization spec, MCP governance, A2A spec, AP2.
They stack rather than compete. PAP explicitly routes API work through MCP and OpenAPI. AP2 describes itself as an extension of A2A and MCP. Two neighbours matter too. WebMCP, edited by engineers at Microsoft and Google, lets a web page register JavaScript tools for agents — a tidier "website" channel. And Decagon's PACT, built on A2A, already defines per-action scopes such as orders:cancel and signed receipts of every action taken: precisely the parts PAP's draft defers.
"…this standard could develop quickly much like Model Context Protocol did." — Larry Dignan, Editor in Chief, Constellation Insights
What does your support stack have to expose?
You expose actions, not systems: each thing an agent may do needs an endpoint, a rule for guest versus signed-in access, a ceiling on what it can change, and a record of what happened. The OAuth handshake is the easy part. Your identity provider has done it for years.
| Action class | Helpdesk example | Access needed | What you must decide and expose |
|---|---|---|---|
| Public answers | Returns policy, stock, shipping times | Guest | Knowledge base or read API; rate limits per agent |
| Account reads | Order status, ticket history | Signed in, view | Map the pairwise ID to a CRM contact; scope to one customer |
| Reversible writes | Change address, reschedule, open a ticket | Signed in, change | Idempotent endpoints; tag every write with the agent's identity |
| Money or irreversible | Refund, cancel plan, waive a fee | Signed in, change, plus your policy | Amount caps, approval rules, escalation path |
| Handoff | "I need a person" | Any | Ticket with transcript, agent identity and the scopes used |
Rows four and five are where PAP's draft is silent and where a bad call is expensive. If an action can't be undone, give it a cap and an approval rule, because a customer's write grant says nothing about amounts. An agent with a valid token and no refund ceiling is a polite way to give away inventory.
Inside Aissist we grade every AI action on a four-step severity scale: S0 for a business outcome that can't easily be undone, such as agreeing a deal that shouldn't be agreed, down to S3 for cosmetic wording. Our target is under 0.01% S0 errors. That same scale is a usable PAP policy: S0-class actions should never ride on a customer's write grant alone, whoever's agent is asking.
None of this requires a new helpdesk. The rules belong in an AI operational layer that already reads and writes your Zendesk or Intercom data. Aissist's gateways connect to 50+ systems and deploy in about 10 minutes, by our own count — the place your AI agent's action limits already live.
PAP standardises the door, not the decisions behind it
PAP has a real chance of winning: it has Meta's distribution and two of the largest contact-centre vendors, Genesys and NiCE. But the draft solves identity and consent, not judgement. Which actions an outside agent may take, under what limits, and what the audit trail records, stay yours to define. Start with an inventory of actions by severity, not an integration project. Replatforming to the standard's author is the one move the standard makes unnecessary; lock-in is a choice. For the purchase side of agent traffic, our agentic commerce platform comparison and Claude for Commerce explainer go further.
Want to see where agent action limits live on your stack? Aissist runs on the helpdesk you already have, with caps, approvals and escalation per action. Book a free demo →
Frequently asked questions
Is the Personal Agent Protocol specification published?
Yes, as a draft. Sierra published it on 9 October 2026, and the docs at personalagentprotocol.org were labelled Draft 0.1 on 13 October. Design workshops and a reference implementation are promised within a month.
Is PAP the same as the agent to agent protocol (A2A)?
No. A2A, a Linux Foundation project, defines how agents exchange tasks. PAP defines how a personal agent identifies itself to a business and acts within the access a customer granted. Decagon's PACT is the protocol that builds on A2A.
What is WebMCP, and how does it relate to PAP?
WebMCP is a W3C Community Group draft that lets a web page register JavaScript tools for AI agents. It describes what a page can do; PAP describes who the agent is and what the customer authorised. Neither Sierra's draft post nor the PAP overview mentions it.
Do I need Sierra or Meta to implement PAP?
No. Sierra describes PAP as open for anyone to implement. A business publishes a discovery file, supports OAuth sign-in and chooses its channels.
Does PAP handle payments?
Not yet. Sierra lists a payments extension only as a possible future addition. Google's AP2, at v0.2, covers agent payment authorisation today with signed checkout and payment mandates.
Do I need to replace my helpdesk to support PAP?
No. PAP sits in front of the systems you run. The work is defining which actions an agent may take, their limits, and what gets logged — policy that belongs on top of your existing helpdesk and CRM.
