Personal Agent Protocol Draft 0.2: What Changed, and the Official Company Kit

Update, 26 October 2026: Draft 0.2 was published on 24 October 2026 and is now frozen at /docs/0.2/spec. When this post was written it was still in progress, and it said 0.1 was the only frozen version. The spec's main address, /docs/spec, now serves draft 0.3, which is in progress, so links below to /docs/spec open 0.3. What changes in 0.3, shown on real runs: Personal Agent Protocol draft 0.3. The rest of this post is as written on 20 October.

Draft 0.2 of the Personal Agent Protocol is taking shape in the open. Eleven days after draft 0.1 was published on 9 October 2026, the spec site now serves 0.2 at its main address, keeps 0.1 frozen at its own URL, and lists every change in a public changelog. The same week, the authors released a Company implementation kit: a skill that a coding agent follows to add the protocol to a company's systems, and a validator that acts as a test personal agent against the result.

This post goes through what changes in 0.2, what the kit does, and what a company that has already published a poppy.json should do now. One thing first: 0.2 isn't final. The changelog says the list "grows until 0.2 is published", and before 1.0 any draft can break the one before it.

#What is Personal Agent Protocol draft 0.2?

Draft 0.2 is the second version of the Personal Agent Protocol (PAP, or "Poppy"), the open standard from Sierra and Meta for how a person's AI agent finds a company, starts a session, signs the person in and acts for them. It's served at personalagentprotocol.org/docs/spec and marked "in progress". Draft 0.1 stays frozen at /docs/0.1/spec.

Most of 0.2 tightens what 0.1 left open, and much of it comes from GitHub issues filed in the first week (#2 to #15). The changelog splits the changes into major ones (design decisions) and minor ones (gaps and consistency). It tags any change that could make a 0.1 implementation stop working as Breaking. Most changes carry that tag.

New to the protocol? How the Personal Agent Protocol works walks through a real agent, step by step, on draft 0.1.

#The changes a company will notice first

These are the 0.2 changes that touch poppy.json and the issuer's OAuth metadata, the two public documents an agent reads before anything else. They're also the ones a checker can see from outside. For a field-by-field view, see what changed in poppy.json.

#Which domain poppy.json speaks for (§3, §3.1)

In 0.1, organization.domain was the host the agent asked for, and a leading www. was ignored. In 0.2 it's the host that serves the document after any redirects, compared ignoring case and nothing else. So www.example.com and example.com are now different domains. A company that uses a provider has the provider serve the document on the company's own domain.

If your poppy.json redirects to another host, check that organization.domain names the host it lands on.

#One issuer per company (§3.2)

An issuer now represents exactly one company. A provider hosting several companies gives each its own issuer, even on shared servers, so they never share user IDs or account tokens. Documents on several domains that name the same issuer must carry the same auth. The spec also says where to find metadata for an issuer with a path, as RFC 8414 defines, and adds a guide on hosting several companies.

#DPoP algorithms: optional list, ES256 required (§3.2, §4.3)

Every company must accept DPoP proofs signed with ES256. Publishing dpop_signing_alg_values_supported in the OAuth metadata is optional. If you do publish it, ES256 must be in it. A company whose issuer also serves other OAuth clients can leave the field out.

#HTTPS everywhere (§3)

Every URL the protocol defines or exchanges must be HTTPS. That now covers API and MCP URLs, metadata endpoints and extension endpoints, which 0.1 didn't. Agents don't send a token, proof, assertion or credential to a URL that a protocol endpoint redirects to. Neither side connects to loopback, private or link-local addresses it was given.

#A version you support, or nothing (§3.1)

0.1 promised that newer minor versions wouldn't break older agents. 0.2 drops that promise until 1.0. A personal agent uses only a poppy.json whose protocol_version it supports, so a document that says "0.2" won't be read by an agent built for 0.1, and the other way round.

#A new feedback endpoint (§8)

A company can list feedback.endpoint in poppy.json. When a user's task can't be done through the protocol, the agent may post a short report:

{
  "kind": "missing",
  "task": "Pay with a gift card",
  "description": "The User wanted to pay for a new order with a gift card they were given. Neither the API nor the Company Agent can apply a gift card, and the checkout page in the browser session has no field for one."
}

That example is from §8. Reports need a Session Token, carry no identifiers, and aren't for errors. The spec's reason is plain: "Without this, the Company sees only a customer who left." Companies must treat a report's text as data, not instructions, even when a model reads it.

#Sign-in, sessions and tokens

These changes sit behind the public documents. They matter most to whoever builds the token endpoint and the agent.

• Assertion audience (§4.1, §4.2, §9.4). Client and Session assertions now name the company's auth.issuer in aud, and companies reject anything else. In 0.1, a Session assertion named the token endpoint. Section 9.4 explains why: a malicious company could name another company's token endpoint and replay assertions there.
• Lifetimes and replay (§4.1, §4.2). A Session assertion's exp is at most five minutes after iat. A company rejects a reused jti from the same client_id until it expires.
• A DPoP key per user ID (§4.3). Agents use a different DPoP key pair for each user ID, so companies can't link people by their keys.
• Full DPoP proof checks (§4.3). Companies validate every proof as RFC 9449 §4.3 describes, for example exactly one DPoP header, typ of dpop+jwt, and never alg: none. Only the token endpoint must keep a replay cache. APIs and conversation endpoints may.
• DPoP at MCP servers (§4.3, §6). An MCP server takes DPoP Session Tokens if its protected resource metadata lists dpop_signing_alg_values_supported with ES256. Any other MCP server gets a Bearer token, which works only at the URL it was issued for.
• A session stays tied to its account (§4.4, §4.8, §4.9). Once a session has been signed in to an account, it can only be signed in to that account again, even after sign-out. This one came from issue #8, which we opened after a test agent signed out and back in as someone else and got conflicting answers from §4.4 and §4.8. It was fixed on 16 October.
• After sign-out (§4.9). The rules are now in one place. Anything that doesn't need the account carries on. A conversation or operation that used it stays as it was, and a signed-out token gets sign_in_required on it. The agent shouldn't sign back in unless the user asks.
• Mediated Sign-In credentials (§4.7). Once a sign-in ends, the agent discards the user's credentials or keeps them only in a credential store the user chose, such as a password manager. They never go in model context or logs.
• Device sign-in links (§4.6). An agent shows a verification_uri only on the company's issuer host or one of its poppy_domains, with the company's name and domain beside it.
• Anonymous browsing (§4.2). An agent may give a user a fresh user ID for each anonymous session, like a private window, and must keep the mapping of a user's IDs across companies confidential.

#A new security section (§9)

Section 9 is new. It deals with the risk that comes with letting one model talk to many companies: prompt injection. Its two hardest rules are:

Personal Agents MUST treat content from a Company as data, not as instructions. Only the User decides what the Personal Agent does.

A Personal Agent MUST NOT act at one Company, or send it information, because content from another Company asked it to.

It also says that text from a company is never the user's approval, and that tokens, keys and codes stay out of model context (§9.2). And it sets out what a domain vouches for (§9.3): whoever controls poppy.json speaks for the company at that host.

#Conversations and Operations

The conversation API (§7) gets mostly consistency fixes:

• every successful read includes conversation_id and events;
• cursor and wait are query parameters;
• a company that caps wait holds the request for its cap instead of rejecting it;
• handing off or closing a conversation twice returns the current state and changes nothing.

In the Operations extension, an operation proposed while signed in can only be used by a session signed in to the same account. Agents should also check that an operation's terms match its summary before asking the user to approve.

#The Company implementation kit

The Company implementation kit follows draft 0.2. It has two parts:

1. implement-personal-agent-protocol, a skill for coding agents. It installs as a Claude Code plugin, through Codex's skill installer, with npx skills add for Cursor, Gemini CLI and Copilot, or by pointing any agent at a SKILL.md URL. The agent works in five steps:
   • survey your systems, sending only GET requests to your domain;
   • design how the protocol maps onto them, for you to approve;
   • build in milestones (Foundation, Interfaces, Sign-in, then optional Extensions);
   • verify;
   • report, which drafts an implementation report with your domains replaced by example.com.
2. A validator, a Node command-line tool with no dependencies. It acts as a test personal agent against your deployment, and each check quotes the requirement it tests. It starts real sessions and sends test messages to your company agent, so the kit recommends a test environment. If a check looks wrong, a "Disagree?" link opens a GitHub issue with the check and its requirement filled in.

The kit covers the company side only, not building a personal agent. A company that offers only its website stops after publishing poppy.json without auth.

Because the validator signs in and starts real sessions, it can test things no outside check can see: tokens, scopes, sign-out and conversations.

#Who's live, and on which draft

Companies are now posting implementation reports in the spec repository:

• Stacktree, a host for pages at private links, live since 11 October;
• Ample Computer, a cloud for apps that agents deploy, live since 17 October.

Both describe what they built, section by section, and what was hard. They're the most useful reading for anyone starting out.

Of the 15 sites on our list of sites publishing poppy.json on 20 October, two already declare "0.2": Stacktree, which also lists a feedback endpoint, and PlanMyVisit by Autoura. The other 13 are on 0.1.

The design partner list on Path to 1.0 hasn't changed. It's 43 names: three personal agents (Instinct, Meta, OpenAI), 21 companies and 19 technology providers. The open topics are still payments, push notifications, versions and attachments. Since 18 October, people have also opened proposals for attachments, push notifications, sender identity, referrals and "user assurance" (a verified human signal).

#What to do if you've already published poppy.json

1. Decide which draft you declare. A "0.1" document is still valid against the frozen 0.1 spec, and agents built for 0.1 will read it. Move to "0.2" when you've made the 0.2 changes, because an agent reads only versions it supports.
2. Check the domain. Make sure organization.domain is the host that finally serves the document, especially if you redirect or add www..
3. Check your URLs. Every API, MCP and extension URL must be HTTPS.
4. Check the DPoP list. If you publish dpop_signing_alg_values_supported, include ES256.
5. Add a feedback endpoint, if you want reports about tasks agents couldn't do.
6. Test it. The kit's validator tests the whole flow against a test deployment. For the public documents alone, any poppy.json checker that knows both drafts will do, including ours.

#FAQ

#Is Personal Agent Protocol 0.2 final?

No. The changelog marks draft 0.2 as in progress and says its list of changes "grows until 0.2 is published". Draft 0.1, published on 9 October 2026, is the only frozen version.

#Is 0.2 backward compatible with 0.1?

No. Most 0.2 changes are tagged Breaking, and 0.2 drops 0.1's promise that minor versions won't break older agents. Before 1.0, an agent uses only a poppy.json whose version it supports.

#What changed in poppy.json in draft 0.2?

organization.domain is now the host that serves the document after redirects, with www. no longer ignored. Every URL must be HTTPS. There's an optional feedback.endpoint. One issuer means one company, and documents that share an issuer share auth. Our poppy.json reference has the field-by-field list.

#Should my company declare protocol_version 0.1 or 0.2?

Declare the version whose rules you meet. A "0.1" document is fine against the frozen 0.1 spec. Move to "0.2" once your documents and endpoints follow the 0.2 changes. The official kit builds to 0.2.

#What is the Personal Agent Protocol Company implementation kit?

It's an official kit from the spec's authors with two parts. A coding-agent skill surveys, designs and builds a company's implementation in milestones. A validator acts as a test personal agent against the deployment. It covers the company side only.

#Does draft 0.2 add payments?

No. Payments is still listed as an open topic on Path to 1.0, along with push notifications, versions and attachments.

#How do I check my poppy.json against draft 0.2?

Read the changelog for the changes tagged Breaking, then run the official kit's validator against a test deployment. A poppy.json checker that applies the rules of the version you declare covers the public documents.

#Sources

• Personal Agent Protocol specification, draft 0.2, in progress (read 20 October 2026)
• Personal Agent Protocol specification, draft 0.1, published 9 October 2026, frozen
• Changelog, personalagentprotocol.org (read 20 October 2026)
• Company implementation kit, personalagentprotocol.org (read 20 October 2026)
• Path to 1.0, personalagentprotocol.org (read 20 October 2026)
• Operations extension, draft 0.2, personalagentprotocol.org
• Implementation report: Stacktree, GitHub, 16 October 2026
• Implementation report: Ample Computer, GitHub, 17 October 2026