Learn

Personal Agent Protocol and PACT: how personal agents will deal with businesses

What Sierra and Meta's Personal Agent Protocol and Decagon's PACT define, how they use A2A, MCP and OAuth, and what a business can do before v0.1 ships.

On October 6, 2026, two proposals appeared for the same problem: how a person’s AI agent should deal with a business. Sierra and Meta announced the Personal Agent Protocol with Genesys, Instinct, Rocket, Shopify, Stripe and Walmart. The same day, Decagon published PACT, the Personal Agent Consent & Trust Protocol, built with Instinct, and said it was joining the Personal Agent Protocol’s working group.

This guide covers what each one defines today, how they use A2A, MCP and OAuth, and what a business can do before the Personal Agent Protocol’s first specification ships.

The problem both address

Personal agents already book travel, manage orders and chase refunds for the people who use them. Most of them do it the way a person would: they load the company’s web pages, fill in forms, and call the support line when that fails. Sierra’s announcement describes the cost of that: it is slow, and the agent may not finish the job.

A direct connection would be faster, but each side wants something different from it. Sierra’s framing:

Party What it wants
Consumers Speed, dependability, and an agent that acts in their interest
Businesses To know when an agent acts for a customer, and to decide what it may do
Companies building personal agents One consistent way to work with every participating business

Both proposals answer the same three questions: which agent is calling, whom it acts for, and what that person has allowed it to do.

The Personal Agent Protocol

What the announcement describes, in the order a visit happens:

Step What happens
Discovery It starts on the business’s website: the personal agent finds what the company offers and how to reach it
Session The agent starts a session for its user, first as a guest, which is enough for questions like product availability or a returns policy
Sign-in When a task needs the customer’s account, the customer signs in on the company’s page, or uses credentials already set up with their personal agent
Access The customer decides whether the agent gets read-only or write access
One visit The session is built on OAuth and carries across channels: a question before sign-in and an order change after it are one visit
Routes The business chooses how agents reach it: its website, its APIs (on standards such as MCP and OpenAPI), or its own agent for tasks that need a conversation, such as a warranty claim

The announcement also lists possible additions without dates: finer permissions on specific actions, push notifications (a flight delay, a shipped order), and payment extensions that let an agent buy something without sharing card numbers.

Status, as of October 6, 2026: no specification is public. Sierra plans to publish v0.1 later in October 2026.

PACT

PACT is published as version 1.0 under the Apache 2.0 license, with a reference provider, a reference personal agent and a conformance suite. It names three parties: the personal agent, the business (a Brand), and the Provider that hosts the business’s agent.

Step How PACT does it
Discover The agent reads the business’s A2A Agent Card, which gives its endpoint, how to authenticate, and the permissions it offers
Prove which agent is calling Every request carries a short-lived JWT the agent platform signs (ES256 or RS256, at most 5 minutes). The Provider checks it against the platform’s published keys. This proves the platform, not the customer’s account
Talk Text messages over A2A’s HTTP+JSON binding, one conversation per agent, user and business; a retried message gets the same reply
Get the customer’s consent (optional) The agent asks for the business’s scopes, such as orders:read or orders:cancel, with OAuth’s device authorization flow. The customer opens a link, signs in with the business and ticks the permissions to grant; the Provider issues a short-lived signed delegation token
Act within it Each request carries both tokens. A turn that needs a scope the customer hasn’t granted returns A2A’s TASK_STATE_AUTH_REQUIRED with a new link, and the conversation continues after approval. Replies under delegation carry a signed receipt of the scopes used and actions taken

The first three rows are PACT’s Identity profile; the consent rows are its optional Delegated profile. A business advertises the second on its Agent Card.

How they relate to A2A, MCP and OAuth

Personal Agent Protocol PACT
Published specification Not yet (v0.1 planned for October 2026) 1.0
Messaging The business’s website, APIs (MCP, OpenAPI) or its own agent A2A 1.0, text messages
Agent identity Not described in detail yet A JWT signed by the agent platform, checked against its published keys
Customer consent OAuth session; read-only or write access OAuth device flow; business-defined scopes
Asking for more permission Not described yet A2A TASK_STATE_AUTH_REQUIRED
Records Visibility for the business into what agents do Signed receipts on replies under delegation

Neither replaces A2A or MCP. They define the part A2A deliberately leaves open: A2A’s specification says how an agent signals that authorization is needed, but leaves the form, scope and revocation of the resulting credential to implementations. OAuth supplies the consent step, and PACT keeps the customer’s login on the business’s own pages.

What a business can do now

  1. Publish an A2A Agent Card for the agent that serves customers. PACT starts there, and the Personal Agent Protocol starts on the business’s website.
  2. Keep login on your own pages. PACT sends the customer to the business to sign in and never gives the agent their credentials; Sierra’s announcement also describes signing in on the company’s page.
  3. Write down what an agent may do, in the terms your systems already use: read an order, cancel one, issue a refund up to a limit. These become scopes or skills in either protocol.
  4. Decide the route. Some tasks suit an API call; others, such as a warranty claim, need a conversation with your own agent.
  5. Watch for v0.1. The Personal Agent Protocol’s specification, workshops and reference implementation are due later in October 2026.

Emissar’s Front Door, the hosted entrance it runs for businesses, answers PACT personal agents with PACT’s identity profile since October 6, 2026. Its demo business, with made-up data, is at https://frontdoor.emissar.ai/a2a/demo.

Questions

Is the Personal Agent Protocol published?
Not yet. Sierra announced it on October 6, 2026 and said it plans to publish the v0.1 specification later that month, along with design workshops and a reference implementation. Until then only the announcement describes it.
How does PACT relate to the Personal Agent Protocol?
They are separate. PACT is a published protocol from Decagon, built with Instinct. On the day both were announced, Decagon said it was joining the Personal Agent Protocol working group. How the two will fit together has not been settled in public.
Do these replace A2A or MCP?
No. PACT is built on A2A 1.0 and OAuth 2.0. Sierra says the Personal Agent Protocol builds its sessions on OAuth and lets a business offer its website, its APIs, built on standards such as MCP and OpenAPI, or its own agent.
Does a personal agent see the customer's password?
Not in PACT: the customer signs in on the business's own login page, and the agent only shows them the link. Sierra's announcement says a customer can sign in on the company's page or use credentials already set up with their personal agent; its specification will say how that works.

Sources

  1. Sierra: Introducing Personal Agent Protocol (October 6, 2026) (accessed )
  2. Bret Taylor's announcement on X (October 6, 2026) (accessed )
  3. Decagon: Introducing the Personal Agent Consent & Trust Protocol (PACT) (October 6, 2026) (accessed )
  4. PACT specification, version 1.0 (accessed )
  5. PACT repository: reference provider, personal agent and conformance suite (Apache-2.0) (accessed )
  6. A2A Protocol Specification: Agent Cards, security schemes and the AUTH_REQUIRED task state (accessed )
  7. RFC 8628: OAuth 2.0 Device Authorization Grant (accessed )
  8. RFC 8414: OAuth 2.0 Authorization Server Metadata (accessed )