Personal Agent Protocol: how to get your community ready for AI agents
On October 6, Meta and Sierra announced Personal Agent Protocol (PAP), an open standard for how a person's AI agent signs in to a business and what it's allowed to do there. Shopify, Stripe, Walmart, Genesys, Instinct and Rocket signed on as launch partners. The first version of the spec is due later this month.
Most of the coverage is about shopping. I run demand gen at Bettermode, where our customers run communities, so I read it with one question: what happens when these agents show up in a community, where everything they do lands in front of other people? This piece covers what PAP is, why a community is a harder case than a checkout, and the decisions community teams can make now, before the spec settles.
What Personal Agent Protocol is
PAP answers a narrow question: when an AI agent shows up on someone's behalf, how does a business know who sent it and what it's allowed to do?
The answer is built on OAuth, the standard behind every "sign in with Google" button. An agent opens a session as a guest, which is enough to check stock or read a returns policy. When the task needs an account, the customer signs in and chooses whether the agent gets read-only or write access. The business sets what agents can do at each level. The session carries across channels, so a question asked before sign-in and a change made after it count as one visit.
The business also picks the route. Agents can use the regular website, standard APIs like MCP or OpenAPI, or the company's own agent.
Some things are deliberately left for later. Payments, push notifications and permissions for individual actions are all listed as future work. Genesys CEO Tony Bates described personal AI as "a new front door to the enterprise," which explains why contact-center and commerce companies signed on first. Stripe and Shopify are also members of Visa's Trusted Agent Protocol, which focuses on agent payments, so expect the two standards to meet at checkout.
Why a community is a harder case than a checkout
A checkout has two parties. A customer's agent changes an order, the business records it, and nobody else is affected.
A community has an audience. When an agent posts an answer, the people reading it are other members who never agreed to talk to software. When it reacts or upvotes, it changes what everyone else sees first. When it earns points, it changes who looks like an expert.
Automated traffic is already the majority of the web. Imperva's 2025 Bad Bot Report found automated activity made up 51% of all web traffic in 2024. PAP gives the useful agents a way to say who they are and who sent them, which is exactly what a community needs to know before it decides what to let them do.
More use, fewer visits
If agents read your community to answer members' questions, the knowledge gets used more while page views drop. A dashboard built on visits will report a decline during your best quarter. Support deflection, onboarding help and product feedback can all go up while sessions go down.
Trust lands on other members
Authorization tells you an agent is allowed to post for Maya. The person reading the reply still can't tell whether Maya wrote it. In a store, that gap only affects the customer and the brand. In a community, it affects every member who reads the thread and decides whether to trust the answer.
More volume to moderate
Automated participation adds volume, and some of it will be noise. Communities will need to tell useful help from unwanted automation without making real members jump through hoops.
Separate reading from participating
The most useful line to draw is between an agent that reads and an agent that participates. Here's how PAP's access levels could map onto a community:
| PAP access level | What it would cover in a community | Where I'd set it |
|---|---|---|
| Guest | Public threads, search, help docs, event listings | Open. This is the knowledge you want found. |
| Read-only, signed in | Private spaces the member belongs to, their notifications, saved posts | Allowed, scoped to exactly what the member can already see |
| Write | Posts, replies, reactions, direct messages, RSVPs | Allowed per action, labeled, with the member accountable |
Per-action permissions are on PAP's roadmap, and community actions are a good test case for them. Letting an agent RSVP to an event is low risk. Letting it message other members is a much bigger ask. Those should be separate switches.
Four rules to set before agents arrive
Label every agent contribution
Anything an agent posts should say so, and say whose agent it is. "Posted by Maya's agent" is enough. Members can decide how much weight to give it, and moderators can spot patterns.
Keep reputation human
Points, badges, leaderboards and top contributor status should only count what people do. Anyone who has run a points program knows people will game it. An agent can game it around the clock.
Measure answers as well as visits
Split reporting into human and agent activity, and start counting the content agents retrieve. If more questions get resolved through agents while traffic dips, you had a better quarter, and your report should say so.
Keep a person accountable
The member who authorized the agent owns what it posts. Your code of conduct applies to them, and moderation actions land on their account.
What to do this quarter
The spec will change, but these steps hold up whatever v0.1 says:
- Add a line about agents to your community guidelines. Something like: "Members may use AI agents to read and search. Anything an agent posts must be labeled, and the member who sent it is responsible for it."
- Look at your public content the way an agent would. If your best answers sit in private spaces or in long threads with no accepted answer, agents and AI search can't use them. Our community visibility playbook covers how to fix that.
- Baseline your traffic now, including how much of it is already automated. You'll want the before picture once agents start arriving with names attached.
- Decide where your brand's own agent fits. If you run a support agent, point it at your community's answers first.
Where Bettermode stands
We shipped an MCP server in August so community admins can run their community from Claude, ChatGPT or any AI tool that speaks MCP. That covers the people who run a community. Member agents raise different trust questions, and they need their own rules rather than a stretched version of admin access.
None of PAP's launch partners runs community software. Sierra says design workshops with interested parties will follow v0.1, and community teams should be represented there. When the spec is published, I'll write up what it means in practice.
FAQ
What is Personal Agent Protocol?
An open standard from Meta and Sierra, announced October 6, 2026, that defines how a person's AI agent authenticates with a business and what it's allowed to do on that person's behalf. It's built on OAuth.
Who supports Personal Agent Protocol?
Meta and Sierra lead it. The launch partners are Genesys, Instinct, Rocket, Shopify, Stripe and Walmart.
When will the Personal Agent Protocol spec be available?
Version 0.1 is due later in October 2026. Design workshops with interested parties and a reference implementation for developers are planned after it.
Does Personal Agent Protocol handle payments?
Not in the first version. Payments and push notifications are planned as extensions.
How is Personal Agent Protocol different from MCP?
MCP is a way for an AI tool to call a service's functions. PAP covers who an agent is acting for and what it's allowed to do. A business can offer MCP as one of the routes PAP agents use.
Should online communities support Personal Agent Protocol?
For reading, yes, once the spec is stable: community answers are what members' agents will be looking for. Posting should wait until labels, human-only reputation and member accountability are in place.
Sources: Sierra, Introducing Personal Agent Protocol; The Next Web; Techzine; Imperva 2025 Bad Bot Report.
TL;DR
- Personal Agent Protocol is an open, OAuth-based standard from Meta and Sierra for how personal AI agents authenticate with businesses and act for their users. Version 0.1 is due in October 2026.
- Agents start as guests. Once the customer signs in, the customer picks read-only or write access, and the business decides what the agent may do.
- In a community, reading and participating are different problems. Let agents read what their member can read, and label anything an agent posts.
- Keep reputation human, and split human and agent activity in reporting so a community that answers more questions doesn't look like it's shrinking.
- None of the launch partners is a community platform. Community teams should have a voice in the design workshops that follow v0.1.
