Home  ›  Insights  ›  Personal Agent Protocol for service
Field Note

Personal Agent Protocol for Salesforce service: the call

Your customers’ AI agents are about to ask to sign in to your service portal. Meta and Sierra published the first draft of a standard for it yesterday, with banks, insurers, OpenAI, Visa, and Zendesk on board. No CRM is on the list. Here is what it is, the count nobody is running, and what to settle before the spec lands.

The call

WATCH: real, and arriving at your service desk, but there is no specification, licence, or Salesforce position yet. The Salesforce service lead and the CISO should write an agent access policy now, so the v0.1 spec lands on a decision, not a blank page.

Sierra and Meta announced the Personal Agent Protocol (PAP) on 6 October with Genesys, Instinct, Rocket, Shopify, Stripe, and Walmart (independent, PYMNTS). On 9 October Sierra published the draft and added 35 design partners, including Bank of America, Wells Fargo, Visa, Mastercard, OpenAI, Okta, and Zendesk (vendor, Sierra). It made the week’s top AI stories list the same day (independent, Tech Startups).

What it is, and is not

It is a proposed open protocol for how a customer’s personal agent identifies itself, gets the customer’s permission, and works with a company (vendor, Sierra). It builds on OAuth, JSON Web Tokens, HTTPS, OpenAPI, and MCP. A company publishes a discovery file at /.well-known/poppy.json, the customer signs in on the company’s own page, and the agent holds a session token limited to what the customer approved. The company chooses the channel: its website, its APIs, or its own agent. Agents may browse as guests; account access needs sign-in (independent, Implicator). The v0.1 spec is due later in October with read-only access as the default (independent, HuggingNews).

It is not a published standard. There is no specification text, licence, or governing body yet (independent, Implicator). It does not cover payments or push notifications in the first version. It is not the only contender: Visa’s Trusted Agent Protocol, Google’s Universal Commerce Protocol, and OpenAI’s Agentic Commerce Protocol all compete for the same traffic (independent, Implicator). And it is not hypothetical. Amazon blocked Meta’s Muse agent 12 days after its 8 September launch, saying it did not identify itself and appeared to store customer credentials (independent, Implicator). That is the problem PAP exists to fix.

The number nobody is quoting

Coverage leads with Meta, Walmart, and OpenAI. Count the partner list instead. It tells you whose service desks get agent sign-ins first, and whose platform has not said a word.

FigureValueLabel
Named partners on 9 October7 at launch + 35 added = 42, plus Sierravendor
Banks, card networks, payment firms, and insurers among themBank of America, BBVA, Chime, Synchrony, Wells Fargo, Visa, Mastercard, Stripe, Adyen, PayPal, Venmo, Plaid, Cigna, GEICO, Liberty Mutual, Insurify: 16 ÷ 42 = 38%our maths, on the vendor list
Customer-service platformsGenesys and Zendesk: 2 of 42, plus Sierra itselfour maths
CRM platforms0 of 42. Salesforce, Microsoft, Google, Amazon, and Anthropic are absentour maths
Partners also tied to a rival protocolVisa (Trusted Agent Protocol), OpenAI (Agentic Commerce Protocol), Stripe, Shopify, and Walmart (already backing rivals): at least 5 of 42independent, count is our maths
Muse launch to a first PAP spec8 Sep to 31 Oct = 53 days of personal agents with no common sign-in; 21 days from todaydates independent; days are our maths

More than a third of the partners run regulated service desks. Those are the desks where an agent asking to change an address, dispute a charge, or file a claim is a compliance event, not a convenience. Five partners are hedging across protocols, so you may be asked to support more than one. And the CRM that holds most of those customer records has no seat at the table. Salesforce published its own view the same day: businesses can use Agentforce so “their own agents greet personal agents as they arrive” (vendor, Salesforce). It does not name PAP.

Missing:

  • The specification text. v0.1 is promised by the end of October.
  • A licence and a governing body.
  • Scope names and token lifetimes, so you know what “read-only” means in practice.
  • How a company verifies which agent, and which vendor, is on the other end.
  • Revocation: how a customer, or you, kills an agent session mid-task.
  • Audit requirements and what each side must log.
  • Liability when an agent acts within its scope and the customer disputes it.
  • A stated position from Salesforce, Microsoft, Google, or Amazon.

Who owns what

The protocol is their job. What an agent may do inside your org is ours.

In a Salesforce estate, the sign-in lands on your Experience Cloud site, so the OAuth app that issues agent tokens should be its own External Client App, separate from your human customer login, so you can scope it, rate-limit it, and revoke it on its own. The discovery file sits on your public domain, owned by whoever runs the website. Writes go through Flow with the same approval rules a human request gets. If you run an Agentforce Service agent, decide whether personal agents talk to it or to your APIs; PAP lets you pick. Log agent sessions with Event Monitoring, and keep the logs long enough to cover a dispute window, not one day.

Monday morning

  • Step 1. Check the last 30 days of Experience Cloud login history and Web-to-Case for automated or headless sessions. You may already be serving agents that do not identify themselves. Owner: Salesforce admin with security.
  • Step 2. Write a one-page agent access policy: which tasks an agent may read, which it may change, and which always go to a person (refunds, address changes, claims). Owner: service operations lead and CISO.
  • Step 3. List the OAuth scopes your customer-facing apps grant today and design a separate, revocable app for agents. Owner: Salesforce architect.
  • Step 4. Ask your Salesforce account team, in writing, for its position on PAP and the rival protocols. Owner: CIO.
  • Step 5. When v0.1 publishes, compare it against the Step 2 policy and decide in one meeting. Owner: Salesforce architect.

What would change our call: we move this to PILOT when the v0.1 spec and reference implementation are public and Salesforce, or your contact-centre platform, states support.

Living page. Last updated 10 Oct 2026. What would change our call: the v0.1 spec, a licence, and a Salesforce position.

Frequently asked questions

What is the Personal Agent Protocol?

An open protocol, drafted by Sierra and Meta, for how a customer’s personal AI agent identifies itself to a company, signs in with the customer’s permission, and completes tasks. It builds on OAuth, JSON Web Tokens, HTTPS, OpenAPI, and MCP, and companies publish a discovery file at /.well-known/poppy.json. The first draft was published on 9 October 2026 with 42 named partners.

Does Salesforce support the Personal Agent Protocol?

Not as of 10 October 2026. Salesforce is not among the 42 named partners. On 9 October Salesforce published a piece saying businesses can use Agentforce to greet personal agents as they arrive, but it does not name the protocol. Ask your account team for a stated position before you plan around it.

When can we implement the Personal Agent Protocol?

Not yet. The v0.1 specification and a reference implementation are expected by the end of October 2026, after design workshops. There is no published licence or governing body. Use the next three weeks to write your agent access policy, so the spec lands on a decision rather than a blank page.