Meta, Walmart and Stripe Want Agents to Log In, Not Click Around. The Spec Isn't Out Yet
By Surya Pratap
October 10, 2026
9 min read
AI & Technology
October 10, 2026
9 min read
Guest, then read, then writeHover to exploreToday a personal AI agent that wants to check an order, book a table or change a delivery address does what a person does. It loads the page, finds the form and clicks through it. That is slow, it breaks when the page changes, and the business on the other end usually cannot tell whether a person or a program is acting.
This week a group of large companies proposed a different arrangement: the agent signs in, the customer decides what it may do, and the business decides how it gets in.
This article is based on "Introducing Personal Agent Protocol" by Bret Taylor and Clay Bavor of Sierra, published on 6 October 2026, and on reporting from The Next Web, Constellation Research and The Daily Brief. No specification had been published when this was written. The reading from section 4 onward is mine.
On 6 October 2026, at Sierra's summit in San Francisco, Sierra and Meta announced the Personal Agent Protocol, which they describe as an open standard for "how personal agents interact with businesses". The founding partners named are Genesys, Instinct, Rocket, Shopify, Stripe and Walmart.
The idea in one sentence, in Sierra's words: "consumers decide what access to give their personal agents, and companies set parameters for what those agents can do."
The announcement frames the protocol around what three groups want:
Meta's interest is direct. Its personal agent, Muse, is the kind of agent the protocol is meant for. According to Constellation Research, Muse applies two checks before it acts: whether one honest person would do the same thing — the example given is creating five accounts to redeem one coupon — and whether the system would still hold up if every agent did it.
The announcement describes a session with three levels of access:
The session is built on OAuth, the standard most sign-in flows already use. It also "carries across channels, so a question asked before sign-in and an order change made afterward are part of the same visit."
On the business side, a company chooses how agents reach it:
The customer chooses how much the agent may do. The business chooses which door it comes through. That split is the whole proposal so far.
This is an announcement, not a standard you can implement this week.
Bret Taylor, quoted by The Daily Brief, summed up the current state: "It is kind of chaos until such a standard exists."
Founders should read this announcement next to the others it overlaps with. The Daily Brief compared four:
| Protocol | Main backers | Focus |
|---|---|---|
| Agentic Commerce Protocol (ACP) | OpenAI, Stripe | Checkout inside an agent, with scoped payment tokens |
| Trusted Agent Protocol (TAP) | Visa, Cloudflare | Proving an agent's identity with signed requests |
| Universal Commerce Protocol (UCP) | Google, Shopify and others | Shopping from discovery to after the purchase |
| Personal Agent Protocol (PAP) | Sierra, Meta, Walmart and others | How a person's agent signs in and what it may do |
Stripe and Shopify are involved in all four. The companies with the most to lose from picking the wrong standard have chosen not to pick. A five-person startup should not try to be more certain than they are.
The protocols also answer different questions. TAP is about which agent is calling. ACP is about paying. PAP is about what this customer has allowed this agent to do in their account. A real product could end up needing parts of more than one.
The good news is that the work underneath every one of these protocols is the same, and most of it makes your product better for humans too.
Make public facts readable without a login. Stock, prices, opening hours, delivery areas, the returns policy. If an agent in guest mode cannot read these reliably, it will send its user somewhere it can. Structured data on your pages and a small read-only API both count.
Separate read access from write access. If your API has one token that can do everything, an agent the customer only wanted to look at their orders can also cancel them. OAuth scopes for "read account" and "change account" are the minimum the protocol assumes.
Make write actions safe to repeat. Agents retry. An order change, booking or refund request should accept an idempotency key, so the same request sent twice happens once. Add a confirm step for anything expensive or irreversible.
Label agent sessions. Record whether an action came from a person, a known agent on the customer's behalf, or an unknown script. You cannot set rate limits, spot abuse or measure agent-driven revenue for traffic you cannot tell apart.
If you already expose an API, an MCP server over a handful of your most common customer tasks is a cheap way to learn what agents actually ask for. Start with read-only tools. Add write tools only once you can see who is calling and you have the idempotency and confirmation pieces in place.
Choosing your channel
The protocol lets you choose between your website, your API and your own agent. For most early-stage products the API is the right first answer: a website is fragile for agents, and running your own customer-facing agent is a product in itself. Offer your own agent when the task genuinely needs a conversation — a complicated return, a mortgage question — not as the default way in.
That PAP will win. It has big names and no spec. UCP, ACP and TAP each have their own heavyweight backers, and the overlap in membership means none of them is settled.
That agents will arrive at your product soon. Visa's own research found most people are still unwilling to let an agent pay for them. The protocol makes agents more capable; it does not make customers trust them.
That it settles the legal questions. Who is responsible when an agent with write access does something the customer did not intend is not addressed in the announcement. Neither is how agent-approved payments fit rules like Europe's strong customer authentication, which were written for a person approving a payment. For one court's view of agents acting for users, see our reading of the Ninth Circuit's Perplexity decision.
That the details are fixed. Everything in sections 2 and 3 comes from an announcement. The v0.1 spec may change names, scopes or the session model.
Meta, Sierra, Walmart, Shopify, Stripe and others have proposed a standard way for a person's AI agent to sign in to a business. Agents start as guests, the customer chooses read-only or write access over OAuth, and the business chooses whether agents use its website, its APIs or its own agent. There is no spec yet, no payments, no fine-grained permissions and no governing body, and it is one of four overlapping protocols.
The protocol you eventually adopt matters less than the groundwork they all assume: public facts an agent can read, scoped access to accounts, write actions that are safe to repeat, and the ability to tell agent traffic from human traffic.
Pick your three most common customer tasks. Make the read-only ones work without a login, and make the write ones scoped, repeatable and logged. Then read the v0.1 spec when it lands, instead of waiting for it to start.
Sources: Bret Taylor and Clay Bavor, "Introducing Personal Agent Protocol", Sierra, 6 October 2026 — the partners, the stated principle, the three groups' needs, the guest, read-only and write levels, OAuth and cross-channel sessions, the website, API and company-agent channels, the v0.1 timing and the future payments, permissions and notifications work. The Next Web for the announcement date and context. Larry Dignan, Constellation Research, 7 October 2026 — Meta's Muse and its two checks. Rajesh Beri, The Daily Brief, 7 October 2026 — the absence of a spec, licence and governing body, Bret Taylor's quote, and the comparison with UCP, ACP and TAP. The reading in sections 4 to 6 is mine.
IdeaToMVP Academy
4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.
