Personal Agent Protocol: PAP, PACT and permission

On this page

We want to be able to send our own agent to a business and have it get something done.

Move the appointment. Find the order. Resolve the return. Carry our instructions into the company's systems without making us repeat the entire conversation at every handover.

That is the promise we see in Personal Agent Protocol (PAP) and Personal Agent Consent & Trust (PACT). The interesting shift is who gets to bring the assistant. A customer could arrive with an agent of their own choosing, while the business decides how to receive it and what it may do.

Sierra and Meta announced PAP on 6 October with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. Decagon announced PACT, co-developed with Instinct, the same day and said it was joining the PAP working group. We read the announcements, then followed PACT's specification to see how far the promise goes.

Our view: this could be an important step towards customers carrying their authority across businesses. Adoption will mean very little, though, if “we support agents” still ends with the customer doing the work.

The customer should be able to bring the assistant

Consider a repair appointment. We ask an agent to move it to Tuesday, with no extra charge. This is an illustrative job, but it exposes the problem quickly. The repair business has to recognise the customer, accept permission to change the booking and preserve the limit on the price.

PAP's announced flow starts at the business website. The agent can ask public questions as a guest. The customer then signs in and grants read-only or write access through OAuth. That session can carry across channels, while the business chooses a website route, an MCP/OpenAPI interface or its own agent. Sierra's launch outline describes those choices.

We like that flexibility. A straightforward date change might be best handled by an API. A disputed cancellation might need the business's support agent. The business knows which systems can fulfil the request; the customer shouldn't have to discover that architecture just to move an appointment.

The harder question is whether the chosen route can finish the job. Recognition is only the entrance. A business that welcomes our assistant and then sends us back through the same manual process has improved very little.

PAP remains a proposal at the launch stage: Sierra plans v0.1, workshops and a reference implementation later in October. We haven't tested those routes at participating businesses. Our earlier personal-agent comparison looked at the assistants customers might bring. Now the receiving side needs to become useful.

Recognising an agent isn't the same as authorising a booking change

PACT makes a separation we think every business should take seriously. Who is calling, and what has the customer allowed them to do?

It builds on Agent2Agent (A2A) and OAuth 2.0. The personal agent identifies itself with a signed token. For customer account access, the person signs in directly with the business and approves permissions. The agent doesn't handle that login. A separate delegation token binds the customer account, personal-agent platform, business and approved scopes, or named permissions for allowed actions. Subsequent delegated requests carry both tokens. Decagon describes this flow.

That distinction matters in our booking example. An agent platform could be recognised and allowed to ask about opening hours. Changing our appointment requires our authority as well. Our instruction to the assistant needs to become a permission the business can verify.

There is an easily missed detail in the specification: PACT Identity and PACT Delegated are separate profiles. Identity supplies the identity and messaging requirements. Delegated adds customer-authorised account access, and it is optional. The provider hosting the business agent can support Identity alone. Admission of personal-agent platforms also remains a provider policy, potentially including an allowlist.

So a PACT badge could mean “your agent can discuss our public returns policy”. It could also mean “your agent can act on your order with your permission”. Those are very different offers.

We would rather see businesses name the jobs they support and the profile that enables them. That tells a customer something a protocol logo cannot.

Our price limit has to survive the conversation

“Move the booking” sounds simple until Tuesday carries a higher call-out fee.

PACT lets businesses define their own scopes: named permissions such as reading an order or changing a booking. Its Delegated profile requires checking the grant, including revocation, and restricting actions to the approved scopes. The conversation can ask for more authority when necessary.

The design gives the business a place to express permission. The business still has to make that permission mean something at the moment of action.

In our example, a broad booking-change scope could leave the charge unresolved. The customer said no extra cost. A friendly exchange confirming that instruction is useless if the underlying booking tool ignores it. Permission has to reach the system that changes the record or makes the commitment.

We think this is where the commercial work sits. Businesses need to decide what customers can delegate, what requires another approval and what happens when a valid request can't be completed within the limit. Those decisions give a scope its meaning.

This is the same question we raise in what an AI agent should be allowed to do. The value of autonomy depends on the job the agent can finish while preserving the customer's instructions.

A receipt should help us establish what happened

PACT requires signed receipts for replies under delegated authority, recording the grant, scopes and actions. We see real value in an attributable record, especially when several systems share responsibility for a task.

But we still want the Tuesday appointment in the booking system. A signed description of an action helps investigate a dispute; it doesn't independently prove that the appointment changed or that a charge settled. If the conversation succeeded while the booking failed, the customer needs a useful explanation and a way forward.

Payments make that problem more demanding. Stripe is involved in PAP, which makes the payment work worth following. Sierra places payment extensions, finer permissions and push notifications in future work. The launch announcement does not establish a payment capability for the forthcoming v0.1.

Before we call this agent commerce, we want to see how amount approval, payment processing and failed-purchase recovery connect to the permitted task. The partner list creates interest. The implementation will determine what a customer can rely on.

The useful destination wins

PAP and PACT are worth watching because they could give businesses a shared way to receive the customer's own assistant. We think that direction matters more than adding another chatbot to the company's website.

The obvious objection is fragmentation: optional profiles, business-specific scopes and provider admission rules could leave customers uncertain about where an agent will work. An open format helps, but it doesn't make every business reachable or every task available.

Our answer is to judge adoption through completed jobs. A date changed within the approved price. An extra charge referred back to the customer. A failed action explained clearly enough to recover. Those outcomes would make the protocols valuable.

For service businesses, that is the opportunity we see. Become a place your customers' agents can use. Give them an offer, a clear grant of authority and a dependable result. The customer should come away thinking about the problem that got solved.

Source note: we read the Sierra and Decagon announcements, PACT specification and reference repository on 8 October 2026. The repair booking is illustrative; we haven't run the reference implementation or tested a live provider interaction.