By Scott Sumner | AI at Work | Published October 7, 2026

A personal AI assistant presents a letter at a business reception desk while the customer stands behind it, illustrating customer-authorized representation.

Your next customer interaction might arrive through a personal AI assistant. Sierra and Meta’s newly announced Personal Agent Protocol makes a practical question harder to ignore: how will your business recognize that assistant and decide what it can do?

Personal Agent Protocol is a developing standard for personal AI agents to connect with businesses on a customer’s behalf. Sierra says it covers authentication and access across websites, APIs and company agents. Its first specification is planned for later in October 2026.

The useful response is not to rush into a new integration. It is to separate finding your business, reading customer information and changing something for that customer. Those are different jobs, with different requirements.

Jump ahead

What Sierra and Meta announced

On October 6, 2026, Sierra cofounders Bret Taylor and Clay Bavor announced Personal Agent Protocol, being developed with Meta and partners including Genesys, Instinct, Rocket, Shopify, Stripe and Walmart.

According to Sierra, the proposed approach starts on a company’s website. A personal agent discovers what the business offers and begins a session on the user’s behalf. A guest session may be enough to ask about availability or a returns policy. Account-specific tasks require the customer to sign in or use credentials already set up with the personal agent.

The session is built on OAuth, an established authorization standard. Sierra describes customers choosing read-only or write access, while businesses decide which routes to make available: ordinary web pages, APIs or a company agent.

That is the proposed design, not evidence that every named partner already supports every task. The announcement says the v0.1 specification is planned for later this month, along with design workshops and a reference implementation. The Next Web’s coverage also highlights that payments are future work, rather than part of the initial specification.

The customer relationship behind the protocol

Imagine a client asking their assistant to move a consultation from Tuesday to Thursday. This is a hypothetical service-business example, not a reported deployment.

The assistant may need to discover available times, identify the correct booking and request a change. Your business needs to know whether the client authorized that change, whether a rescheduling fee applies and where the confirmation should go.

A public answer about office hours does not need the same access as changing an appointment. Reading the client’s booking is another distinct step. Treating all three as one generic chatbot conversation hides the business decisions.

My take: the important shift is not that software can click a calendar. It is that customers may expect their chosen assistant to be a recognized representative, without giving it unrestricted control of their account.

Businesses already understand versions of this distinction when an assistant or colleague calls on someone’s behalf. Software makes the interaction faster and potentially more frequent. It does not remove the need to establish who is represented and what has been authorized.

Why the website still matters

Sierra’s proposed flow begins at the website and can continue through it. It also allows businesses to expose APIs or their own agent. Nothing in that description makes a company chatbot mandatory or makes the website obsolete.

For a service business, the website can remain the public explanation of what is available, where the service applies and how a customer starts. The account system handles private records. The booking or service system handles the transaction.

These roles need to agree. If the service page promises free rescheduling but the booking system charges a fee, connecting an agent will not resolve the contradiction. It may simply bring it to the surface sooner.

This is where agent-ready website work meets ordinary customer experience. Clear offers, accurate policies and functioning service routes matter before a particular protocol is adopted. They are also part of AI Findability: helping a buyer or assistant understand the business before deciding what to do next.

What to prepare before buying an integration

I would begin with one customer task and a short decision sheet. Not a project to make the entire business agent-accessible.

Write the task in customer language

Use something like “move my consultation” or “check the status of my project.” Avoid starting with “implement agent interoperability.” The first version gives a team something concrete to design and test. The second can occupy several meetings without helping a customer.

Separate public facts from private account information

Which answers can anyone read? Which require an authenticated customer? For the consultation example, general rescheduling terms might be public. A named client’s appointment details should not become public just because an assistant asks politely.

Define the change and its confirmation

Document what the customer is agreeing to: the old appointment, the new appointment, any fee and the final result. This is my recommended implementation checklist, not a claim that the announced protocol already provides action-specific controls.

In fact, Sierra lists more detailed permissions as a possible future extension. Read-only versus write access is a useful distinction, but a business may need narrower controls for a particular workflow.

Ask your existing vendors what they actually support

Talk to the booking, CRM or customer-portal provider that already owns the process. Ask whether it has a supported integration route, how delegated access is recorded and how a customer can withdraw it. Ask what happens if a change fails halfway through.

A roadmap slide is not a working connection. If a vendor claims Personal Agent Protocol support, ask which published specification version it implements and which operations have been tested. As of this article’s source check on October 7, Sierra’s announcement still describes v0.1 as forthcoming.

What this announcement does not prove

It does not establish that agent-originated purchases are a significant share of your revenue. It does not guarantee a business will get recommended by ChatGPT or any other assistant. And it is not a new Google ranking requirement.

Sierra’s claims about faster completion describe the ambition of the design. The announcement is not an independent performance study of your software or your customers.

There is a real development worth following here: major companies are trying to make customer representation by AI more explicit. There is also unfinished work. Sierra names more detailed permissions, push notifications and payment extensions as possible next steps.

Both can be true. You can prepare a useful customer process now without pretending the standards discussion is settled.

One useful next step

Choose one recurring request customers already send to your inbox. Write down what an assistant could learn publicly, what requires sign-in and what would change a customer record. Add the confirmation the customer should receive.

That one-page map will help you question vendors and spot gaps in the current journey, whether this particular protocol wins broad adoption or not.

If the public website and the service process do not line up, start there. A Findability OS Audit can examine how buyers and AI systems find and understand the business, then identify the website work worth doing before an integration project. Contact Sumner.ai to discuss that starting point.

Sources

Sources checked October 7, 2026. Recommendations and the consultation example are Sumner.ai analysis, not claims of a tested deployment.