Personal Agent Protocol: Customer Agents Meet Business

Personal Agent Protocol is a proposal for making customer agents recognizable participants in business interactions. Announced on October 6, 2026 by Meta and Sierra, it describes a customer-controlled session that can work across a company's website, APIs or agent. The useful business question is how to accept that delegation without confusing access to an account with authority to perform every possible action.

The announcement said a v0.1 specification and reference implementation were still to come. This guide therefore separates the proposed direction from the operational decisions a business can make now. The transaction examples are design exercises, not evidence that a production PAP integration already implements them.

A customer might ask a personal agent to move a delivery to next week. The request sounds simple, but the business needs to know which order is involved, whether the customer controls it, which dates are available and whether the change creates a fee. An agent that can navigate the website has not automatically answered any of those questions. It has only found a route to the same decision points a human would encounter.

Sierra's October 6 announcement describes Personal Agent Protocol as a way to connect that personal agent with participating businesses. It proposes discovery on the website, a session on the user's behalf and access through existing pages, APIs or a business agent. The first specification was planned for later in October. Those are announced intentions; the post does not establish a deployed implementation across the named partners.

That distinction changes what a team should do next. There is useful preparation work in listing the actions a customer can delegate, but little value in inventing a PAP endpoint from an announcement. The existing business guide to agent protocols explains the broader landscape. Here the distinctive question is customer delegation across a business boundary, rather than how any two software agents exchange messages.

A business needs to distinguish the person whose account is being used from the software acting for that person. If those identities are collapsed, the record may show only that the customer changed an order, with no indication that an agent performed the steps. Keeping the distinction gives support staff a clearer explanation when the customer later asks what happened or revokes the delegation.

The proposal describes OAuth-based sessions and a distinction between read-only and write access. OAuth supplies established authorization mechanisms; it does not by itself define the business meaning of a delivery change, a refund or a purchase. The OAuth security best current practice discusses restricting access-token privileges and protecting authorization flows. A business still has to map the granted access to its own operations.

For example, a customer could permit an agent to inspect order status without permitting it to change the delivery address. An application that treats a successful login as permission for both actions has erased the useful boundary. A better design resolves the account, identifies the delegated actor, checks the requested operation and only then exposes the allowed action. This is a design recommendation, not a claim about a finalized PAP permission schema.

People delegate outcomes in everyday language. A customer may say to sort out a delayed order, while the business offers several possible operations: check its status, change a date, cancel an item or request a refund. The agent should not treat that phrase as a blank authorization to choose whichever operation is easiest. It needs a way to connect the proposed action to the customer's actual preference.

Write down the information that can change the decision. For a delivery change, that might include the new date, the address, a fee and whether the original booking can be restored. If any of those values differs from what the customer approved, the agent needs a fresh decision or a clearly authorized rule for handling the difference. A convenient channel transition must not silently widen the scope.

A useful internal exercise is to write the confirmation as a receipt before implementing the action. Could the customer understand what will happen from that short statement? If it only says that the agent will manage the order, the action is underspecified. If it identifies the order and the exact change, the team has a concrete boundary to enforce and test. This is also where the agent brief method becomes useful: the important constraints should survive the move from a request to an executable task.

• Identify the record and operation the customer intends.
• Expose consequences that could change the customer's choice.
• Reconfirm a material change instead of interpreting silence as broader permission.

The announcement imagines continuity across a website, an API and a business agent. That is appealing because a customer should not have to explain the same problem repeatedly. But conversational continuity and authorization continuity are different concerns. Carrying the question forward does not prove that the next system has permission to see every detail from the previous one.

Consider an agent that begins with a public question about a returns policy and later signs into an account to inspect an order. The public part of the conversation may be safe to carry between channels, while account details require narrower handling. The application should preserve the useful context without treating the whole transcript as public or sending it to every integration merely because the session continues.

The same distinction applies to errors. If the API path fails and the agent falls back to a web form, the fallback should honor the original scope and pending state. It should not create a second request because the first response was unclear. Record what was attempted, whether it may have taken effect and which channel can verify the outcome. The agent handoff guide covers the related problem of retaining responsibility when work moves between participants.

A reassuring message is not evidence that a change occurred. The agent needs a reliable observation of the business state, and the customer needs a concise explanation of the result. A useful receipt identifies the action, the affected record, the relevant final values and any remaining work. It should also distinguish a submitted request from an accepted or completed transaction.

Suppose a delivery system accepts a date-change request but the carrier has not confirmed the new slot. Saying the delivery has been moved overstates the result. The honest outcome is that the request was accepted and confirmation remains pending. This distinction is familiar in ordinary customer service; agents make it more important because fluent language can conceal an incomplete transaction.

Design the failed receipt too. If the address update succeeds but the date change fails, the customer should not receive a single generic failure message that hides the completed part. Nor should the agent repeat both actions without checking. The business needs a state model that can represent partial outcomes and a recovery path that acts only on unresolved work. PAP may help establish the session, but your transaction semantics still decide what success means.

A customer should be able to stop an agent's access, but the application also needs to decide what that means for work already underway. Preventing a new lookup is different from cancelling an accepted delivery change. A completed transaction cannot necessarily be undone simply by revoking the credential that initiated it. Treat access revocation and business reversal as separate operations.

For a proposed implementation, list the places where delegated access is checked: when the session begins, when account data is requested and immediately before a consequential action. Then consider long-running work. If the customer revokes access while a task is waiting, the system should not resume later using authority it only checked at the beginning. The exact enforcement mechanism depends on the eventual protocol and the surrounding authorization system.

Support staff also need a way to understand and resolve the situation. A customer who says that an agent made the wrong change should not have to diagnose a token or a tool call. Provide a human-readable action history and a route to the responsible business process. The design succeeds when the customer can stop future access and the business can explain what already happened, without making either party reconstruct a hidden technical conversation.

• Check current authority before a new consequential action.
• Keep the action history separate from credentials and secrets.
• Explain whether stopping access also stops a pending business operation.

The most durable preparation is an inventory of customer actions and the conditions under which each action is allowed. Separate public information, account-specific information, reversible changes and changes that create a commitment. Identify which operations already have reliable APIs and which still depend on a person interpreting an exception. This work remains valuable even if the first PAP specification differs from expectations.

Choose one journey with a clear beginning and end. A public availability question followed by an authenticated order lookup is easier to reason about than a general-purpose promise to handle every service request. Write down the expected evidence, the escalation point and the receipt. Use synthetic accounts until the authentication and authorization boundaries are demonstrated. The goal is a coherent transaction path, not a large catalogue of agent-accessible actions.

Avoid building a shadow API based on guessed field names or treating a partner logo as a deployment commitment. When the specification is published, compare its actual mechanisms with the requirements you have written. Our AI transformation work uses this sequence because business rules often outlive the first integration choice. A team with clear rules can evaluate a protocol; a team without them can only evaluate a demonstration.

When v0.1 becomes available, look for concrete answers rather than more examples of what agents could do. How is the delegated actor identified? What permissions can be expressed? How does a session move between channels? What information is available to explain a completed action? Which parts are mandatory, optional or left to the business? Those details determine whether two implementations can actually cooperate.

Also ask what the protocol leaves outside its scope. An authorization mechanism does not decide refund policy. A discovery document does not guarantee a service-level commitment. An authenticated agent can still misunderstand the customer's request. Keeping these limits explicit prevents the protocol from becoming a substitute for ordinary product and operational judgment.

The opportunity is real but specific: a customer agent could interact through a more consistent, inspectable business boundary. The defensible next step is to prepare that boundary and evaluate the published mechanisms when they arrive. That approach serves both parties better than promising universal agent access before the specification, implementation and business rules have caught up.

• Verify the published specification and actual implementation status.
• Test one complete customer journey, including rejection and recovery.
• Expand only when the customer and the business can both inspect the outcome.