Personal Agent Protocol: how businesses can work with customers’ AI agents

Suppose a customer asks their personal AI agent to move an appliance-repair visit to next Tuesday morning. In this fictional example, the repair company needs to know which appointment belongs to that customer and what changes the agent may make. A request to reschedule shouldn’t give it control of the company’s calendar.

Personal Agent Protocol (PAP) proposes a shared way for businesses to handle that relationship. Meta and Sierra are developing it with partners including Stripe and Shopify. The design lets a customer delegate access while the business decides how the agent can interact with its services.

The 6 October 2026 announcement describes the intended approach and says the version 0.1 specification is planned for later that month, alongside a future reference implementation. The announcement doesn’t establish tested interoperability across the named partners.

One customer session across different channels

Sierra describes a personal agent starting on the business’s website, discovering what it offers and how to reach it. The agent can begin as a guest, which may be enough to ask about availability or a returns policy.

Account-specific work requires more access. The announcement describes customer sign-in through the business’s page or credentials already configured with the personal agent. The customer decides whether to allow read-only or write access, and an OAuth-based session carries across channels so earlier questions and later account actions remain part of the same visit.

The business can offer its regular website, APIs built around standards such as MCP and OpenAPI, or its own agent for tasks needing conversation. PAP’s proposed session would help carry the customer’s delegated access through those routes. A business offering an API could handle a supported task through that interface.

OAuth already provides a way to limit an application’s access to an account. Its scope mechanism lets a service grant particular permissions, but OAuth doesn’t prescribe a universal vocabulary for them. A business still has to decide what its permissions mean and enforce them.

Agree on the appointment change before making it

For the fictional repair company, I’d begin with one supported action: moving an existing appointment within the customer’s account. Checking public availability could stay separate from viewing that customer’s booking details.

After the customer grants account access, the agent could retrieve the existing visit and offer an available Tuesday slot. Before changing anything, the business should make the proposed time and any fee clear and obtain the customer’s confirmation through an agreed process.

That confirmation process is a proposed safeguard for this example, not a feature the announcement establishes. The company also needs to apply its normal booking rules, including whether a change is still allowed and whether the slot remains available when it processes the request.

A customer might authorize the agent to move this one visit but leave other appointments untouched. That narrower limit would need an enforceable business rule or permission mechanism; the announcement’s read-only/write distinction doesn’t show how to express it. Sierra lists more detailed action permissions among possible future developments.

The agent should receive an unambiguous result from the booking service, with the confirmed time and a reference the customer can use. Keep an action record that staff can investigate without storing bearer tokens in routine logs.

Account access still needs checks on each action

Knowing an appointment identifier shouldn’t let an agent change someone else’s visit. OWASP’s object-level authorization guidance calls for checking whether the user can perform the requested action on the requested record. A hard-to-guess booking reference doesn’t replace that check.

The service must also distinguish a customer’s rescheduling permission from administrative calendar access. OWASP’s function-level authorization guidance recommends denying access by default and requiring explicit permission for each function. The booking service needs to apply those checks even when the company’s agent handles the conversation.

Suppose the service changes the appointment but the response never reaches the personal agent. A timeout leaves the outcome uncertain; treating it as a failed change and immediately trying again could trigger an unintended second action.

AWS’s guidance on safe retries describes service-side handling of a stable request identifier so repeats don’t create additional effects under the API’s contract. Ask whether your booking service supports that behavior, including its limits, or offers a reliable way to check the action’s status. If neither can establish what happened, hand the case to staff instead of issuing another write. PAP’s announcement doesn’t establish a retry or transaction guarantee.

Prepare one customer action, then evaluate the implementation

A business can start by identifying a customer task it already supports and writing down the data and actions an agent would need. For rescheduling, that includes which booking it can access, what it may change and which requests must go to staff. Keep payment access separate unless the chosen task genuinely requires it.

Use actual customer requests to judge whether this work deserves priority. The founding-partner announcement supplies no business-specific demand forecast or evidence that an integration will reduce your support costs.

Before buying an implementation, ask the supplier which published specification revision it follows and which customer-agent combinations it has tested. Request demonstrations of denied access and uncertain outcomes, alongside the successful appointment change. Agree on what happens when the agent can’t finish.

Sierra discusses push notifications and payment extensions as possible future work, along with finer permissions. Don’t include those capabilities in a rollout plan merely because they appear in the announcement.

For a first controlled trial, choose one action whose permissions and result your staff can explain. Keep the existing customer-service route available when the agent needs help or the system can’t confirm what happened.