Personal Agent Protocol Explained for Business Owners

Your customers are starting to hand everyday tasks to AI assistants: "track my order", "move my delivery to Friday", "book a table for four". Today those assistants mostly click through websites built for humans, and they often get it wrong. The Personal Agent Protocol is the first serious attempt to give them a proper front door to your business.

The short answer: the Personal Agent Protocol (nicknamed "Poppy") is an open, draft standard announced by Sierra and Meta on 6 October 2026. It defines how a customer's personal AI agent finds a business, opens a session, signs the customer in with standard OAuth, and then uses the business's website, its APIs (OpenAPI or MCP) or the business's own AI agent. It is not finished yet, but the groundwork it needs (clean APIs, proper sign-in and clear permissions) is worth doing now.

This guide explains what the protocol is, how it works, where it stands in November 2026 and what a business should do about it.

What is the Personal Agent Protocol?

A personal agent is an AI assistant that acts for one person: Meta's assistant, ChatGPT or a similar tool that a customer uses across many companies. The Personal Agent Protocol is a shared set of rules for how such an agent talks to a company, so each company doesn't need a different integration for every AI assistant, and each assistant doesn't need to scrape every website.

It was announced by Sierra (Bret Taylor and Clay Bavor's customer-service AI company) and Meta, with partners including Genesys, Shopify, Stripe and Walmart. The official partner list now also names OpenAI and Instinct among personal agents, companies such as Bank of America, Target and United Airlines, and technology providers including Cloudflare and Okta. The specification is open source under the Apache 2.0 licence and is developed in public on GitHub.

The idea in Sierra's words: consumers decide what access to give their personal agents, and companies set parameters for what those agents can do.

How does the Personal Agent Protocol work?

The specification splits the job into four parts.

1. Discovery: a file on your website

A company publishes a poppy.json document at https://yourdomain.com/.well-known/poppy.json. It tells agents who you are (name, domain, logo), how sign-in works, and which channels you offer. A personal agent that is asked to "check my order at Acme" starts there.

2. Sessions: one visit across every channel

Every request from an agent carries a signed Poppy-Session header. You don't need a separate step to start a session, and the same session continues whether the agent browses your website, calls your API or talks to your support agent. Each customer appears to you under a stable ID that is different for every company, so agents can't be used to track people across businesses.

3. Sign-in: standard OAuth

When a task needs the customer's account, the protocol uses standard OAuth, the same technology behind "Sign in with Google". The preferred method is Direct Sign-In, where the customer signs in on your own page; there is also a device-code flow (a link and a short code). Many tasks don't need sign-in at all: a signed-out agent can do what a signed-out visitor can do on your website, such as check stock, prices or a returns policy.

4. Channels: website, APIs or your own agent

You choose which channels to offer, and you can start with just one. The spec calls this progressive adoption: "start with only a website, only APIs, or only an agent" (introduction).

Who decides what an agent can do?

Early coverage said the customer simply picks read-only or write access. The spec has moved on. Since version 0.3, the protocol no longer defines its own read and write permissions: each company defines its own scopes, usually the OAuth scopes it already has (changelog). Companies can also label each scope with hints, for example whether it makes no changes, reversible changes or irreversible changes, and whether it touches personal data.

In practice that means:

• You decide which actions exist and how risky each one is (view orders, change an address, cancel a booking).
• The customer decides which of those permissions to grant their agent when they sign in.
• Your existing rules still apply: an agent signed in as a customer can't do more than that customer can.

Where does the protocol stand in November 2026?

It moves quickly and is still a draft:

Source: changelog and Path to 1.0. Until version 1.0, a new revision can break compatibility.

Other facts worth knowing:

• No large company runs it publicly yet. When we checked on 6 November 2026, none of walmart.com, target.com, shopify.com, stripe.com or sierra.ai served a poppy.json file. The best-known demonstration so far is from Sierra's own event, where Meta's assistant got a mortgage pre-approval through Rocket's agent (Sierra).
• Payments aren't part of it yet. Payments, push notifications (such as flight delays) and signed approvals are listed as open topics. For shopping, the protocol points to Google's Universal Commerce Protocol (UCP) through an extension.
• There are community tools, not official ones. The spec ships an implementation kit with JSON schemas and a validator. Third-party libraries exist for some languages, but there is no official SDK and no Laravel package yet.

How does it relate to MCP, OpenAPI and other standards?

The Personal Agent Protocol doesn't replace the standards you may already use; it builds on them:

• OpenAPI and MCP (the Model Context Protocol, the common way to give AI tools access to an application) are the two API types it supports.
• OAuth handles sign-in, and JWTs sign the session.
• UCP covers how an agent shops; Poppy finds the company, identifies the agent and signs the customer in.
• Decagon announced a related consent standard, PACT, the same day and said it would join the protocol's working group.

So work you do on a clean API or an MCP server today is not wasted, whatever happens to the protocol's details.

Should your business care?

Pay attention now if customers regularly do repetitive tasks with you online: e-commerce (order status, returns, address changes), bookings and reservations, financial services, logistics and delivery tracking, or SaaS products where users manage accounts and settings. These are exactly the tasks people will delegate to an assistant first.

You can wait if your website is mainly a brochure and enquiries come in by phone or a contact form. Being readable by AI (clear pages, structured data) matters more for you than a protocol integration.

Either way, nobody needs to implement a 0.x draft in production today. The useful question is whether your systems could support it quickly once it reaches 1.0.

What to do now

1. List the tasks customers would delegate. Look at your most common support requests and account actions. Those are your future agent actions.
2. Make sure those tasks exist as an API. If the only way to change a delivery address is a web form, an agent has to click through it. A documented API (OpenAPI) or an MCP server gives agents a reliable path. See our guide on third-party API integration in web applications for the basics.
3. Use a standard OAuth server with meaningful scopes. The protocol reuses your OAuth scopes, so "full access" for everything won't work well. Separate reading from changing, and mark irreversible actions.
4. Start read-only. Signed-out and read-only access carry the least risk and need the least work. Add write actions once you have logging, limits and review in place.
5. Check your bot protection. Firewalls and bot blockers that treat every automated visitor as an attacker will also block legitimate agents. The spec's guides recommend planning for recognised agent operators.
6. Watch for version 1.0. Track the changelog and decide then. Building on 0.3 is possible, but expect changes.

Mistakes to avoid

• Treating a draft as final. Version 0.3 changed how permissions work only a month after launch. Build the foundations, not a rigid integration.
• Giving agents your full admin API. Expose only the tasks customers need, with the same checks as your website.
• Allowing irreversible actions without a safety net. Cancellations, payments and deletions need confirmation, limits and an audit trail.
• Asking customers for their passwords. The protocol's agent-uses-your-password option ("Mediated Sign-In") is transitional and planned for removal. Direct Sign-In on your own page is the way forward.

How CodeBrisk can help

We are a Laravel web and mobile app development company, founded in 2014, and we build the APIs and integrations this protocol relies on: payment gateways, accounting software, system-to-system sync and AI integrations. We have also built a production MCP server for AI agents on our own site, with token permissions, rate limits and human review of everything an agent writes.

If you want your application ready for AI agents, see our API development and integration and AI integration and automation services, read the technical companion how to make your Laravel app ready for AI agents, or tell us about your project.