How PAP Could Connect Personal Agents With Businesses

TL;DR

We read Sierra’s October 6, 2026 PAP announcement as a proposed design for connecting personal agents to businesses, not a finalized or widely deployed specification. An agent would discover how to connect through a business’s website.
The agent could start a guest session to check product availability and continue the conversation without signing in.
Account actions, such as changing an order, would require customer sign-in or previously configured credentials. Sierra describes OAuth-based authorization for account access.
The customer could grant read-only or write access, but the business would still decide which actions it makes available.
A business could connect through its website, an API such as MCP or OpenAPI, or its own company agent.

What Sierra’s Personal Agent Protocol proposes to solve

Sierra introduced the proposed Personal Agent Protocol (PAP) in its October 6, 2026 announcement. PAP addresses a practical connection problem. A personal agent needs a way to find a business through its website and start talking to it, while the business needs to decide what it makes available. Sierra describes a proposed design, not a finalized or broadly deployed specification.

That connection could let an agent ask whether a product is in stock without accessing a customer account. Changing an existing order would require account access and permission for that action. PAP’s proposed connection and session design does not, by itself, establish an agent’s identity or authorize a payment. At Skyfire, we treat agent identity and transaction-level payment authorization as separate concerns that can complement how an agent connects to a business.

How a personal agent discovers and starts talking to a business

Sierra’s proposed Personal Agent Protocol starts discovery at a business’s website. The personal agent would use information available through that website to find how to contact the business, then start a guest session. Sierra presents this as a proposed design, not a feature available across business websites today.

Suppose you ask your agent whether a retailer has a jacket in your size. Under Sierra’s proposal, the agent could find the retailer through its website and ask about availability as a guest. A public product question would not require the agent to sign in to your account or use stored credentials.

The guest session would let the agent carry context into a follow-up question. If you ask about a different size, the agent could continue the exchange without starting over, and the business could understand which jacket you mean. We would treat that continuity as conversational context, not permission to view your orders or change account details.

When account access requires sign-in or stored credentials

A guest session can answer a product-availability question, but changing an existing order requires access to the customer’s account. In Sierra’s proposed PAP design, the customer can sign in when the agent reaches that step, or the agent can use credentials the customer previously configured. The guest conversation may continue, but it does not itself authorize account access.

Sierra describes OAuth-based authorization for the account-access handoff. For example, a personal agent helping a customer change an order would need authorized access to that order before it could request the change. We would not treat sign-in as blanket permission to modify the account. The customer’s authorization and the actions the business makes available still determine whether the agent can complete the request.

Previously configured credentials offer a path that does not require the customer to sign in during every conversation. Sierra’s announcement does not establish the detailed credential-handling steps, so businesses should not assume a particular storage or token flow from the proposal alone.

Who controls what the agent can see and do

We separate two decisions in Sierra’s proposed PAP design. The customer controls whether a personal agent receives read-only access or permission to request changes through write access. After signing in, a customer might let an agent check an order while withholding permission to change it.

The business independently decides which actions it makes available to personal agents. A retailer could offer order lookup but decline to offer order changes. In that case, a customer’s write permission would not give the agent a way to change an order. If the retailer does offer order changes, the agent would still need the customer’s authorization before requesting one.

How a business connects: website, API, or company agent

We read Sierra’s PAP announcement as giving businesses three connection options, not a sequence they must follow.

A business could use its website as the place where a personal agent discovers how to connect. Sierra describes this website route as an alternative to offering a direct software interface.

A business could instead expose an API that the personal agent can use, including an MCP or OpenAPI interface. The API route gives the agent a defined way to make requests without treating the website as its only point of interaction.

A business could also connect its own company agent to the customer’s personal agent. Under that option, the two agents interact directly. Sierra presents the website, API, and company-agent routes as choices for the business, but the announcement does not establish a preferred route for every use case.

What PAP leaves unspecified today

We read Sierra’s October 6, 2026 announcement as a proposed design for PAP, not a complete specification or a deployment guide. Several details remain open.

Permissions. Sierra describes customer-controlled read-only and write access but leaves finer-grained controls for particular data or actions unresolved.
Notifications. Sierra identifies notifications as a possible extension without defining how businesses would send them to personal agents.
Payments. Sierra treats payments as future-looking. The announcement does not define how an agent would receive authorization for a specific purchase.
Specification mechanics. The announcement does not establish a ratified standard, a governance process, or commitments from other businesses to adopt PAP.
Implementation. Sierra’s examples explain the proposed interaction, but the announcement does not supply all the technical details a business would need to deploy an interoperable connection.

A business can use the proposal to frame questions about agent access. It should not treat the announcement alone as evidence that PAP works across businesses today.

Where agent identity and payment authorization fit separately

Sierra’s proposed PAP design describes how a personal agent would connect to a business and how a customer could authorize account access through OAuth. That customer authorization differs from verifying which agent is acting or approving what the agent may spend. For example, access to an order could let an agent request a change, but it would not, by itself, authorize a later purchase.

At Skyfire, we position our KYA token and Agentic Wallet as controls for agent identity and payment authorization. Those controls could complement a connection protocol, but Skyfire has not claimed PAP support or integration.

FAQ

Is PAP live or in production today? Sierra’s October 6, 2026 announcement presents PAP as a proposed design. The announcement does not establish that PAP is a finalized specification or broadly deployed in production.

Does PAP require a customer account? No. Sierra proposes guest sessions that could let a personal agent ask a business about product availability without signing in. Accessing an account, such as to change an order, would require customer sign-in or previously configured credentials.

Does PAP handle payments? Sierra describes payments as a possible future extension, not a defined capability of the announced design. A business evaluating agent purchases would need to consider payment authorization separately.

How does PAP relate to MCP? Sierra names MCP as one possible API interface a business could use to connect with a personal agent. PAP’s proposal also allows website and company-agent connections, so MCP is not a required path.

Does PAP establish agent identity? Sierra’s proposal describes how an agent connects to a business and obtains customer-authorized account access, but it does not specify a way to verify the agent’s own identity. We treat that as a separate concern. Skyfire’s KYA addresses agent identity, while its Agentic Wallet addresses payment authorization, without implying either integrates with PAP.

Conclusion

Sierra’s PAP proposal gives businesses a reason to consider how customers’ personal agents might reach them. Its specification and adoption remain unsettled, so you should watch how the proposal develops before committing to an integration path.

At Skyfire, we treat agent identity and payment authorization as separate planning concerns. PAP’s proposed connection and customer authorization flow does not establish which agent is acting or authorize a particular payment. Businesses that expect agents to transact should plan for those controls alongside access, without assuming PAP will provide them.