Personal Agent Protocol (PAP): what Sierra and Meta have shipped so far

What is the Personal Agent Protocol?

I build integrations for eesel, so when a standard promises to say how an agent "authenticates with and acts on" a business, I read it the way I read an API contract: what is defined, what is a sentence of intent. The Sierra announcement is mostly intent, but the intent is specific.

Personal agents are the assistants that work for a consumer, like Meta Muse, Instinct and OpenAI dots. Today, Sierra says, most of them "use websites and apps the way people do," and when that fails they call the support line or open web chat. PAP is meant to replace that with a direct, authorized connection. Three parties want different things from it:

• Consumers want speed, dependability and trust.
• Brands want visibility and control: to know when a personal agent is acting for a customer and to decide what it can do.
• Agent builders want one consistent way to work with participating companies.

The partners named in Sierra's post are Genesys, Instinct, Rocket, Shopify, Stripe and Walmart, alongside Meta and Sierra. Stripe's Kevin Miller framed the business side plainly:

"We're contributing to the Personal Agent Protocol to give businesses a standard way to recognize their customers' agents, efficiently interact with them, and shape their customer relationships."

Kevin Miller, Stripe

How does a PAP session work?

Here is the flow as Sierra describes it, step by step. The protocol starts on the website, where a personal agent can discover what the company offers and how to reach it. The agent then opens a session for its user, and the session can start as a guest. A guest session might be enough to check product availability or ask about a returns policy.

When the task needs account access, the customer signs in on the company's page or uses credentials already set up with their agent. The customer decides whether the agent gets read-only or write access. The session is built on OAuth, the same authorization standard behind "sign in with Google," and it carries across channels, so a question asked before sign-in and an order change made after are one visit.

The business then chooses the door:

That third door is where support teams should look. Sierra's own post says the company agent handles "tasks that need conversation," and a company agent on a helpdesk is exactly that. Meta Business Agent, which David Singleton names in his post, is Meta's version of the same idea on the business side. My read: PAP is a front-door standard, and what stands behind the door is still your policies and your AI customer service workflow.

One more thing worth saying out loud: Sierra, Genesys and Decagon all sell company-side agents or contact-center software, so the "company agent" door is also their product lane. That does not make the idea wrong. It does mean you should read the word "open" as "open spec," and check who writes the first reference implementation.

What has actually shipped and what is only promised?

This is the part most coverage skipped, so I tracked it by date. Everything below links to the publisher's own page.

Read the last row twice. The announcement states the principle that "companies set parameters for what those agents can do," but the finer controls, letting customers and companies limit specific actions, are described as future work. So today's PAP gives you three things on paper: guest versus signed-in sessions, read versus write access, and your choice of door. Per-action limits are not in the first version as described.

Sierra also admits the gap that matters most to a support team. In its fleming-1 post it says that when an agent uses the protocol, "the company knows it's an agent and who it's acting for," and then adds: "Of course, some agents may not respect the protocol." That is why Sierra shipped fleming-1 two days later, a model that scores a caller's speech in real time for signs it was generated by AI. Sierra says it is "tuned to be conservative by default, so real people don't inadvertently get flagged," and it is meant to give information, not a verdict.

Who is in and who is missing?

The partner list depends on whom you ask, and I think that is worth a table, because the differences are the story. I checked each source directly.

Singleton's list adds NiCE and Decagon and leaves out Instinct, whereas Sierra's has Instinct and no NiCE or Decagon. Most likely the working group grew in two days, which is what you would expect from a draft standard. What none of the four posts names is OpenAI, Anthropic, Amazon, Google, Zendesk or Salesforce. Amazon matters most for commerce: it blocked Meta's Muse from its retail site in September, and one commentator on X put the cost of that bluntly.

"Nobody asked the person whose agent stopped working."

Ryan Sarver, X

Reaction on X to the launch was mixed. One reply on Stripe's post reads like a lot of the industry skepticism I have seen:

"like you read the PACT announcement and released this with no spec?"

Jeff Schneider, X

That is a guess about motive, and Sierra's post does not say it. But the dates do line up: PACT's code went public on October 6, the same day PAP was announced without one.

How does PAP relate to PACT?

PACT is the best-defined cousin, so it is worth understanding. PACT stands for Personal Agent Consent & Trust. Decagon co-developed it with Instinct, and the open repository carries the spec, TypeScript schemas, a reference provider, a demo personal agent and conformance tests, all Apache-2.0.

It runs in three steps:

1. Discover and connect. The personal agent reads the business's A2A Agent Card, which lists the endpoint, how to authenticate and the scopes on offer, like orders:read or orders:cancel. The agent signs each request with a short-lived JWT, so the provider can verify which platform is calling.
2. Authenticate the customer. The agent asks for scopes through OAuth's device authorization flow and shows the customer a login link. The customer signs in directly with the business and approves permissions. The agent never sees the password.
3. Act within the grant. Each request carries both the agent's identity and the customer's delegation, and replies include signed receipts that record the scopes used and actions taken.

PACT's design choice I like most is separating identity from authority: "Verify which agent is calling independently of what the customer has permitted it to do." One replier on X flagged why that matters for plain OAuth:

"OAuth tells the business which customer, not which agent process holds the token. A copied bearer token works until it expires, so keep those short."

Mike Moore, X

PACT answers that with signed agent JWTs and short-lived delegation tokens. PAP's announcement does not say yet how it handles it, which is one more reason the v0.1 text matters. For the product built on PACT, including detection and the airline example, see my earlier breakdown of the Decagon Personal Agent Gateway. One correction to that post: it said the PACT spec was not public. It is now, with the repository published on October 6.

How does PAP compare with the other protocols?

The honest answer is that these protocols mostly answer different questions, and the comparison is lopsided because only some have text you can read. This is the table I would screenshot.

Two things jump out. First, PAP is aiming at the row nobody has finished: consent and scope between a consumer's agent and a business, across every channel. Second, nothing in the payments row talks to support at all. Visa's protocol uses signatures bound to the domain and the specific operation, and Mastercard's score is about whether a transaction was AI-initiated. Neither tells your helpdesk that a customer's agent wants a refund. Sierra's own post lists "payments extensions" as future PAP work, which tells you where the protocol families may eventually meet. If you sell online, the agentic commerce protocol and Stripe's version are the checkout side of the same story.

Which protocol covers your case?

Pick the job you care about. The widget shows which standard speaks to it, how ready it is, and what I would do now.

What should a support team do before the spec lands?

Most support teams will not be early adopters of a protocol that has no spec. The useful work is on your side of the door, and it is the same work whether the standard ends up being PAP, PACT or both. Customers' agents are already reaching queues through chat, email and phone, as OpenAI dots for customer support and Instinct for customer support show, so I would do this in order:

1. List every action your support AI can take. Sort each into read, reversible write, money-moving or account control. Most teams have never written this down, and it becomes your scope list.
2. Put approvals on money and account changes. A refund is a refund whether a person or an agent asked. The Zendesk advanced AI actions and Gorgias AI actions guides show what native tools can gate.
3. Count your agent traffic. Tag conversations that look agent-sent and measure the share before you buy detection. Sierra itself says a high-volume company "might start by measuring how often it happens."
4. Write escalation with two exits. Your AI should hand off to a person and also say what it needs from the customer's agent. The AI escalation management guide covers the person side.
5. Keep a way in for APIs. If you already publish an AI customer service API or helpdesk API, that is door number two. Scope it before you advertise it.
6. Replay past tickets before go-live. Run real refund and cancellation tickets against your AI and see where it bends. A customer's agent will find the soft spot faster than any customer.

The sixth point has a scar behind it. One support lead on a sales call told eesel what they needed from an AI before they would trust it:

"I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

A CX lead at a DTC supplements brand on Gorgias and Shopify, about 7,000 tickets a month

That sentence is a scope definition in plain words. It is also the right test for a personal agent on the other end: if your AI cannot say "this one is not mine," it cannot safely meet an agent that will ask five different ways.

Commerce teams have one more job. If you run Shopify, which is in the partner list, the Shopify AI customer service strategies guide and Muse for Shopify customer support show how agents already reach those queues. For Meta's own side of the story, see Meta Muse for customer support.

Where does eesel fit?

I will be direct about the limits. eesel does not detect personal agents, and it does not implement PAP, PACT or A2A. If you need a vendor that is building an agent-to-agent channel with customer-granted scopes, Sierra and Decagon are the two to look at, and the Decagon vs Sierra comparison and Sierra alternatives roundup lay out the trade-offs. When v0.1 is published I will read it against what eesel does and write up the gap, not guess at it now.

What eesel does is the permission layer on the helpdesk you already run. The AI helpdesk teammate joins Zendesk, Freshdesk or Gorgias like a new hire. Every action it can take is set to Auto, Needs approval or Disabled, grouped into Read and Write, per eesel's actions docs. You can say it in plain words: "look things up on your own, but ask me before any refund."

That is the same read-versus-write split the protocols formalize, aimed at your own AI. If PAP does land with per-action limits, these are the settings I would map them to. And because the protocols talk about APIs and MCP, one more detail: every eesel workspace is also an MCP server, and the eesel CLI drives the same teammate from a terminal. A coding agent like Claude Code can run eesel integrations <platform> actions to see every action and its approval setting, or eesel approvals to approve or deny held actions. The CLI follows the same permissions as the dashboard, so a write set to "needs approval" stays held until a person approves it.

What are people saying?

The public reaction to PAP itself is still thin, which makes sense three days after launch. The wider argument about agents contacting support is louder. On Hacker News, the most useful comment I found came from a customer's side of the table:

"The solution for both sides is for the companies to implement support bots that have more power to address my problem than the humans they replaced were ever given."

CamperBob2, Hacker News

Put that next to Simon Taylor's read of PAP on X, where he called it an alternative to blocking and said it lets a business "recognize it, give it read-only by default, and route anything that moves money to your own agent." That is his interpretation, not Sierra's wording, but it is the version I would build toward. Blocking turns away the customer, and an open door with no limits is worse. The scopes are what let both sides get something.

Try eesel

If customers' agents are about to start asking your queue for refunds, the first job is deciding what your own AI may say yes to. eesel's AI helpdesk teammate plugs into Zendesk, Freshdesk or Gorgias, learns from your past tickets and help center, and keeps refunds and cancellations behind an approval until you have watched it hold the line. You can run it on past tickets in a simulation before it touches a customer.

The free plan includes 100 credits and every integration, and paid plans start at $299 a month for 500 credits, where a ticket or a chat is 1 credit, on the eesel pricing page. Try eesel on your own queue.