Personal Agent Protocol: how support teams prepare

This guide is written for a support operations lead who has to say yes or no to a change request before a spec exists. I do not know what version 0.1 will say, and neither does anyone outside the working group, so I treat the announcement as a statement of direction and plan around the parts that any reasonable protocol must include: identity, consent, limits, and escalation. The primary source for every claim about the protocol is Sierra's announcement, published on October 6, 2026 by Bret Taylor and Clay Bavor.

Where I go beyond it, I say it is my reading.

There is a lot of secondary commentary already. Some of it lists partners that differ from Sierra's list, and some of it describes a spec that does not exist yet. I did not use any of it for facts.

If a claim is not in Sierra's post, it is not stated here as a fact about the protocol.

What was announced on October 6, 2026

Sierra's post describes the Personal Agent Protocol as an open standard that Meta and Sierra are developing with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. The post also mentions Instinct joining. The goal it states is to give consumers' personal agents a standard way to work with businesses: to handle authentication, to put consumers in control, and to give companies visibility into what personal agents do through their websites, APIs, or company agents.

In plain terms, a person's AI assistant needs a sanctioned way to walk up to your front door, and you need to be able to see who walked in.

The post states one principle that I would pin above a support lead's desk: "consumers decide what access to give their personal agents, and companies set parameters for what those agents can do." That sentence assigns the two decisions to two parties. The customer decides what the agent may attempt. The company decides what any agent may do on its side, whatever the customer allowed.

Both limits apply at once, and the stricter one wins. If you have ever configured a role-based permission system, the model is familiar. The customer grants a role to the agent, and your service enforces a policy on top.

The post also gives a timeline. A version 0.1 specification is planned for later this month, which means later in October 2026. Design workshops and a reference implementation are planned after that.

The post names possible future work: more detailed permissions, push notifications, and payments extensions. Those are named as possibilities, so I will not build a plan around them.

Several partners were quoted. Tony Bates, Chairman and CEO of Genesys, said, "Personal AI is creating a new front door to the enterprise," and the quote continues in the post. Kevin Miller, Head of Payments at Stripe, framed the need as a standard way for businesses to recognize their customers' agents.

Mani Fazeli, VP of Product at Shopify, is also quoted in the announcement. I use only the parts I can verify in the post itself, and you should read the full text on sierra.ai before you quote anyone in your own planning documents.

What is confirmed, and what is not

Separating the two matters because a protocol announcement invites every vendor to describe a finished product. The table lists the claims I would plan around and the ones I would not.

The two rows with ✓ and ✗ are the awkward ones. The announcement states them, but they are future items. A date is not a deliverable, and future features are not features.

Plan around the first five rows and watch for the specification.

How a personal agent reaches you: guest, then signed in

The most useful detail in the announcement is the access model. It starts on the website. An agent can arrive as a guest, for example to check availability or read a returns policy.

No account is needed for that, because the information is already public to any visitor. Many support questions live in this tier: what are the opening hours, is this item in stock, what is the refund window, how long does shipping take.

When the agent needs account access, the customer signs in on the company's own page, or uses credentials already set up with their agent. The customer decides whether the agent gets read-only access or write access. That is a clean split, and it maps onto a distinction support teams already use.

Read-only access lets an agent look up an order status. Write access lets it change an address, cancel an order, or start a return.

The post says sessions build on OAuth and carry across channels. The second half is the interesting one for support. A customer who starts with their agent on your website and then continues through your API or your company agent keeps the same session, so you do not make them start over.

If your current channels each keep their own history, that is a gap. A session that crosses channels needs one customer record underneath it.

The reasons this matters for a support lead are mundane. A guest session means your public answers need to be accurate and complete, because an agent will read them and relay them. A signed-in session means your account checks need to be reliable.

Neither is a new problem. Both get worse in volume when software does the asking. Teams that have not organized their public answers should start with structuring the knowledge base for AI and treat the guest tier as a public API for facts.

Three routes in: website, API, and your own agent

Sierra's post names three routes by which a personal agent can work with a company. The first is the website itself. The second is APIs, which the post describes as "interfaces built on standards such as MCP and OpenAPI." The third is the company's own agent, which the post positions for "tasks that need conversation, such as a warranty claim." I read that as a division of labor.

Structured, repeatable operations go through the API. Messy, multi-turn problems go to a conversation, and the conversation partner is your agent.

Each route has a different owner inside a company. The website belongs to marketing and web. The API belongs to engineering.

The company agent belongs to support. A protocol that spans all three forces those teams to agree on one identity and one set of limits, which is harder than any technical detail in the spec.

The API route links this topic to the rest of the agent ecosystem. If you already expose actions to an AI, you have thought about scopes and authorization. The primers on MCP for customer support and on MCP versus API for support automation cover the mechanics.

What changes with a personal agent is that the caller is the customer's software, not yours.

The third route, a company agent that talks to a customer's agent, raises its own set of questions. Who is the agent speaking to, and what should it say about itself? That topic gets a full treatment in agent to agent customer support.

For this article, the point is narrower: your support agent should know when the other side is software.

Identity: recognizing a customer's agent

Kevin Miller of Stripe described the need as a standard way for businesses to recognize their customers' agents. That is the identity problem in one line. Today, when an agent calls your API, you see an API key or a browser session.

You do not see a statement that says this software acts for this person with these permissions. A protocol that carries that statement lets you treat the request differently from a random bot.

Recognition has three parts, and a spec that skips one of them is not enough. First, who is the person. Second, which software acts for them.

Third, what the person allowed. Your system needs all three in one place at the moment of the request, not reconstructed later from logs.

Until the specification arrives, you can prepare the receiving side. Decide how your system will store the link between a customer account and a delegated agent. Decide whether a delegation can be revoked, and how fast revocation takes effect.

Decide whether you want to allow multiple agents per customer, since a person may have a shopping agent, a travel agent, and a banking agent from different vendors.

A support lead can contribute a requirement that engineers may not think of: the support agent and the human agent need to see the same delegation record. When a customer calls to say my assistant did something I did not want, the person on the phone has to be able to see which agent acted, under which grant, at what time. If that record sits in a log that only engineering can read, the call ends with a promise to investigate.

That record is the same kind of trail described in the guide to the AI support audit trail. Add a field for the acting agent and a field for the grant, and you have most of what a dispute needs.

Consent: who decided, and how you can prove it

Sierra's principle assigns consent to the customer. That sounds simple until a complaint arrives. A customer says they never allowed the agent to cancel the subscription.

The agent vendor says the customer approved write access. Your company holds the record of what happened on your side. Without a shared, verifiable record of the grant, you are the one in the middle with the least information.

The announcement does not say how consent is recorded or proven. That is a gap to watch in the specification. In the meantime, treat any grant you receive as evidence you should store, with a timestamp, the scope as presented to you, and the identifier of the session it arrived in.

Storing more is cheap. Reconstructing a grant from memory is not possible.

Read-only versus write is the coarsest useful scope, and it is the one the announcement names. Your own policy should be finer. Separate the writes that are easy to undo, such as updating a preference, from the ones that are not, such as a refund or a cancellation.

Require a stronger confirmation for the second group even when the agent holds write access. A person who clicked a general write grant did not necessarily consent to a specific irreversible action at a specific time.

This is the territory of runtime checks rather than static permissions. A correct grant can still produce a wrong action when an agent retries after an unclear result or combines two permitted calls into a risky one. The patterns in AI agent runtime authorization apply directly: budgets, combination rules, and idempotency keys.

Rate limits and fairness when software asks

A person asks one question and waits. A personal agent can ask fifty, in parallel, to compare your answer against three competitors. The announcement says companies set parameters for what agents can do, and rate limits are the most basic parameter.

They are also the one most likely to catch you off guard, because your current limits were set for human-driven traffic and a few known integrations.

Decide on three numbers before the specification lands. First, a per-agent request ceiling for guest sessions, which should be generous for reads and strict for anything that triggers work. Second, a per-customer ceiling that applies across all of that customer's agents, so three agents acting for one person do not triple the allowance.

Third, a global ceiling for agent traffic as a class, so a surge in agent visits cannot starve human customers.

Fairness is not only a technical matter. Your service level commitments were written for people. A response time target that applies to a human waiting in a chat window is not the same as one that applies to software that can retry in a second.

The conversation about how to set targets for each class is in support SLAs with AI. The short version is that you can promise different things to different callers if you say so in advance.

Do not rely on the protocol to fix abuse. A standard identity makes abuse easier to attribute, and attribution helps you block. It does not stop a badly written agent from hammering an endpoint.

Your own limits are the defense.

Disclosure, handoff, and the human on the other end

Two obligations do not go away. The first is disclosure. If your company agent replies to a customer's agent, who is it speaking to, and does the customer know?

The rules differ by jurisdiction, and the topic is covered in AI disclosure in customer support. A personal agent adds a new case: the customer may be unaware of what their own agent said on their behalf. Your agent can only control what it says and what it logs.

The second is the handoff to a person. Sierra's post positions the company agent for conversational tasks, and some of those tasks will exceed what an agent should decide. A warranty claim that involves a disputed fact is an example.

The design questions are the same as in AI to human handoff: when to hand off, what context travels with the case, and how the customer is told. With a personal agent in the loop there is one more question. Does the handoff go to the customer's agent or to the customer?

My view is that a human-to-human handoff should reach the person, because only the person can accept a remedy and take responsibility for the decision.

Keep a short list of situations where the answer is always a human. Disputed charges, health or safety claims, legal threats, account takeover reports, and anything where the customer has said they want a person. An agent on either side should not talk its way past that list.

A readiness checklist for support teams

Use this list in order. Each item is useful whether the final specification matches the announcement or not.

• Write down which answers are public. These are the guest tier. Make sure they are accurate, dated, and complete, since agents will read and relay them.
• Split your account actions into read, reversible write, and irreversible write. Give each a clear name that a customer could understand.
• Decide how you will store a link between a customer account and an acting agent, and how revocation works.
• Add the acting agent and the grant to your audit record so a support person can read them without help from engineering.
• Set rate limits per agent, per customer, and for agent traffic as a whole.
• List the situations that always go to a human, and make sure your agent honors the list.
• Make sure a session that crosses channels keeps one customer record underneath it.
• Name an owner for agent traffic. Someone in support should watch the dashboards, review disputes, and attend the protocol's design workshops if the working group opens them.

The product work can start with what you already run. If your agent answers from your own content, data sources is where the guest-tier facts live, and the security page describes the boundaries communicate.so applies to workspace data. I am not claiming the product supports the protocol, because the specification does not exist yet.

The claim I can make is narrower: a team with clean public answers and an auditable agent is closer to ready than one without.

Three tickets you will see once agents arrive

Abstract advice is easy to nod at and hard to apply, so here are three scenarios worked through. They are my illustrations of how the announced model would play out in a queue, not reports of real cases, and none of them is drawn from a customer.

The first scenario is the guest question. A customer's agent asks, as a guest, whether an item ships to a given country and how long a return window lasts. No account is involved, so identity is not the issue.

The issue is whether your public pages give one clear answer. If the shipping page says five days and the product page says seven, the agent will pick one or average them, and the customer will blame you for whichever it repeats. The fix is editorial: one source of truth for each fact, with a date.

The second scenario is the read-only account question. The customer has given their agent read-only access, and the agent asks where an order is. Here the grant works in your favor, because the agent cannot do harm with it.

The risk is volume and exposure. An agent that polls order status every minute generates load, and an agent that returns the full order record to a third party may reveal more than the customer meant to share. Return the fields the question needs and no more.

The third scenario is the write request that looks routine. The agent holds write access and asks to cancel a subscription. The grant allows it, yet the action is irreversible and has a cost to both sides.

This is where your own policy matters more than the protocol. A sensible rule is a short confirmation step that reaches the customer, not the agent, for cancellations, refunds, and address changes after shipment. That step adds seconds and prevents the dispute that would otherwise land on a support person two weeks later.

Notice what the three have in common. In none of them did the protocol answer the hard question. It carried identity and consent to your door.

What you did with them was a matter of content quality, data minimization, and a confirmation policy that you control today.

Measures worth tracking from day one

A new traffic class needs its own numbers, or it will disappear into your averages. You do not need a new tool to start. You need a way to label a request as coming from software acting for a person, even if the label is crude, such as a user agent pattern or a header your gateway can see.

Track the share of conversations and API calls that come from agents. Track how many of them resolve without a human, using the definition in AI resolution rate versus deflection rate, so you do not count an agent that gave up as a success. Track the rate of reversals, meaning actions that an agent took and a customer later asked you to undo.

A high reversal rate points to a consent or confirmation problem, not to a traffic problem.

Track latency and error rates separately for agents and people. A person will wait ten seconds for a chat reply. An agent with a timeout of five seconds will fail and retry, and the retry doubles your load.

If the numbers diverge, you have found a case for a faster path or a clearer retry policy.

Finally, track disputes. Count the tickets where a customer says an agent did something they did not intend, and read each one. The patterns in those tickets will tell you more about the right scopes than any specification.

The analytics page describes what communicate.so reports on conversations today, and you can add your own labels on top.

What I would not do yet

Do not build to a leaked draft or to a vendor's interpretation. A protocol in its first week is a moving target, and every implementation guess made now is a guess about syntax that the specification will settle in a few weeks.

Do not announce support. A press line that says your company supports the protocol, before a specification and a reference implementation exist, promises something nobody can verify. Say that you are following the work and preparing.

Do not change your terms of service in a hurry. If agents will act for customers, your terms need to say who is responsible for an action taken through a delegated agent. That is a job for counsel after the spec is read, not a paragraph copied from a blog post.

Do not treat the guest tier as harmless. Information that was easy for a human to ignore, such as a stale price on an old page, becomes a factual claim when an agent reads and repeats it. Clean it up now.

Do not forget the humans. Most of your customers will still use a chat window or a phone for a long time. Time spent on agent readiness should not come out of the quality of the human channel.

Where the evidence stops

The announcement is the only primary source I could find, and it is a blog post, not a specification. It tells you who is involved and what the intent is. It does not tell you the token format, the signing model, the way consent is recorded, the revocation flow, or the way liability is shared when an agent acts wrongly.

Those details decide whether the protocol is useful to a support team.

When version 0.1 does appear, read it with five questions in hand. How is an agent identified? How is consent recorded and shown to you?

How is a delegation revoked? What happens when an agent exceeds its limits? Who is told when something goes wrong?

A spec that answers all five is one you can plan a launch around.

Secondary coverage of the announcement exists, and parts of it disagree with each other on the partner list and on whether a spec is available. I treated that as a reason to rely on Sierra's own text. If you read other coverage, check each claim against the original post.

I also have no data on adoption. Nobody does yet. Whether personal agents will arrive at your door in meaningful numbers this year is a forecast, and the people announcing the protocol have an interest in the answer.

Watch your own logs for traffic that behaves like software acting for a person, and let that evidence set the pace.

For the commerce side of this, where the agents are shoppers and the stakes include payments, see support for AI shoppers. For a plan to keep your own answers crisp enough for any reader, human or not, see the guide to training an AI on your help center.

One last practical point. Whatever protocol wins, your agent will work better if it can hand a case to a person without losing context. A shared inbox where AI and people see the same thread is the plain way to do that, and it does not depend on a specification.

Frequently asked questions

What is the Personal Agent Protocol?

It is an open standard that Meta and Sierra are developing with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. It aims to let a person's AI agent authenticate and work with businesses under permissions the person grants.

Who announced it and when?

Sierra published the announcement on October 6, 2026, written by Bret Taylor and Clay Bavor. The post says Meta and Sierra are developing the standard together with the named partners.

Is there a published specification?

Not as of October 8, 2026. Sierra's post says a v0.1 specification is planned for later in October, followed by design workshops and a reference implementation.

Who decides what a personal agent can do?

Both parties do. The post says consumers decide what access to give their personal agents, and companies set parameters for what those agents can do. The stricter of the two limits applies in practice.

How does an agent get access to my customer account?

According to the post, the customer signs in on the company's page or uses credentials already set up with their agent, and chooses between read-only and write access. Sessions build on OAuth.

Can an agent use my site without an account?

Yes. The post says an agent can begin as a guest, for example to check availability or a returns policy. Account access is needed only for account-specific tasks.

What are the three routes a personal agent can take?

The company website, APIs built on standards such as MCP and OpenAPI, and the company's own agent, which the post positions for tasks that need conversation, such as a warranty claim.

Does the protocol use MCP?

The post names MCP and OpenAPI as examples of standards that company APIs may be built on. It does not say that the protocol itself is built on MCP, so do not assume that.

Does my business need to support it right now?

No. The specification does not exist yet. Preparing is reasonable, such as cleaning public answers and adding audit fields, but announcing support before the text is out is premature.

What should I change first in support operations?

Start with the guest tier and the audit record. Make public answers accurate and dated, and make your logs show which agent acted under which grant, in a form support staff can read.

How should I set rate limits for agents?

Use three layers: a per-agent ceiling, a per-customer ceiling across all that customer's agents, and a global ceiling for agent traffic. Be generous for reads and strict for actions that trigger work.

Do I have to tell customers when my agent talks to their agent?

Disclosure rules depend on your jurisdiction and your own policy. Treat disclosure as the default, log which side is software, and have counsel review the wording once the specification is available.

When should a case go to a human?

Disputed charges, safety or health claims, legal threats, account takeover reports, and any case where the customer asks for a person. Keep that list short, explicit, and enforced by your agent.

Who gets the handoff, the customer or their agent?

In my view the person, for decisions that carry responsibility. The announcement does not address this. Only the customer can accept a remedy, so a human handoff should reach the human.

What did the partners say about the protocol?

Tony Bates of Genesys said personal AI is creating a new front door to the enterprise. Stripe's Kevin Miller spoke of a standard way to recognize customers' agents. Shopify's Mani Fazeli is also quoted.

What is not yet known?

Token formats, scopes, signing, how consent is recorded, revocation, and who bears liability when an agent acts wrongly. The announcement lists detailed permissions, push notifications and payments extensions as possible future work.

How is this different from an API key?

An API key identifies a caller. The protocol aims to identify a customer, the software acting for them, and what the customer allowed, in one request, so a company can treat the call accordingly.

Will personal agents replace chat widgets?

There is no evidence for that yet. Most customers will keep using chat and phone for some time, and agent traffic will probably add to those channels. Measure it in your own logs.

Where can I read the primary source?

Sierra's blog post titled Introducing Personal Agent Protocol at sierra.ai, dated October 6, 2026. Check it again when the v0.1 specification is published, because details may change.

How can communicate.so help me prepare?

It can answer customers from your own content and hand cases to people in a shared inbox. It does not claim support for this protocol, because no specification exists to implement against.

Conclusion

The Personal Agent Protocol is real as an announcement and unfinished as a standard. That combination calls for modest, ordered work. Clean the public answers, separate read from write actions, record who acted and under which grant, set limits for software callers, and keep a human path for the cases that need one.

When the v0.1 specification appears later this month, read it with this list beside you and mark what it settles. Until then, spend the effort on the parts of agent readiness that do not depend on syntax. If you want an AI agent that answers from your own content and hands difficult cases to your team, look at communicate.so AI agents, or compare plans on the pricing page.