PAP Checker
Version 0.3 of the Personal Agent Protocol was published on 4 November 2026 and is now frozen at its own address. Within hours, draft 0.4 opened in its place. The authors call it "much smaller than 0.3: mostly additions, clarifications, and fixes", and say they "don't expect Companies that implement 0.3 to need significant work to adopt 0.4".
That's good news if you've built on 0.3. But 0.4 does change one thing every company will meet, which is how versions and extensions are declared. This post covers what publishing 0.3 means, what 0.4 changes so far, and what we see across the sites that publish a poppy.json.
What does "published" mean for 0.3?
A published version of the Personal Agent Protocol (PAP, or "Poppy") won't change. 0.3 now lives at /docs/0.3/spec, next to 0.2 and 0.1, and the spec's main address follows draft 0.4. The Path to 1.0 page now opens with a status note: 0.3 "is published and won't change", and 0.4 is in progress.
0.3 was a big release. Its changelog lists 79 changes, and 28 of them are tagged Breaking. Each company defines its own scopes. Sign-in types come from the OAuth server metadata. Sessions are separate from OAuth. protected_resources replaces poppy_domains, and excluded tasks are new. Our post on draft 0.3 walks through those on real runs. One correction: it was written while 0.3 was still in progress, and the frozen text has more in it, including the UCP extension and skill_index.
Who is on 0.3 already?
Of the 34 sites listed on PAP Checker on 5 November, 15 declare 0.3, 9 declare 0.2 and 10 still declare 0.1. Three of the 15 are our own PAP Sandbox test stores. The other twelve moved to 0.3, or started on it, before it was published.
Since 0.3 is frozen, a "protocol_version": "0.3" document is now checked against fixed text. A document on 0.1 or 0.2 is still checked against the version it declares, and still works with agents that support that version. But the next agents and companies will build on 0.3 and 0.4.
What changes in draft 0.4
The list below is the changelog as of 5 November. It grows until 0.4 is published, so any of it can still change.
One company, several versions (§3.4)
A company can now serve more than one protocol version at a time, so agents can move to a new one at their own pace. poppy.json is the document for the version the company prefers. A new supported_versions field maps each other version to its own document:
"protocol_version": "0.4",
"supported_versions": {
"0.3": "https://example.com/poppy/0.3.json"
}
Each URL must be HTTPS, on the same host that served poppy.json, and the agent must not follow a redirect from it. Every version's document must have the same organization.domain and select the same issuer. The agent picks the newest version it's compatible with and names it on every request in a new Poppy-Version header. An endpoint that checks the session rejects a missing or unserved version with version_unsupported (HTTP 400). The agent then fetches poppy.json again and chooses again.
From 1.0, these fields and headers keep their meaning in every version. Even agents and companies on different major versions can then tell whether they share one. This also clears one of the topics Path to 1.0 listed as open: "Versions" is no longer on that list.
The spec notes that this works like UCP's version selection. A company that runs both protocols can now handle versions the same way in each.
Extensions are listed per version, and declared per request (§3.3)
This change touches every poppy.json that lists extensions. In 0.3 each extension was one object. In 0.4 it's a list, with one entry for each major version the company supports:
"extensions": {
"operations": [{ "version": "2" }],
"ucp": [{ "version": "1" }]
}
Agents now declare the extensions they use with a company in a Poppy-Extensions header, one version of each, for example "operations";v="2", "links";v="1". The extensions member of the agent's client metadata document goes away. An agent can use different versions with different companies, and roll out a new version gradually. extension_required follows what the request declared, and the token endpoint no longer returns it.
Conversations that started in another version (§8.13)
A conversation can carry on in a session that uses other versions, unless the company can't carry it over. Then it may reject requests on that conversation with version_mismatch (HTTP 409). The error names the version the conversation started in, and the agent either finishes it in a session with those versions or starts a new one.
Signed-in browsing needs poppy:browser-sign-in (§6)
For an agent's browser to join a session signed in, the agent now needs an access token with poppy:browser-sign-in. It's the only scope the protocol defines. 0.3 required every website to apply the cookie's scopes, which sites whose permissions don't match their OAuth scopes couldn't do. Two new web fields go with it:
web.unscoped: the website treatspoppy:browser-sign-inas everything the account can do there, so an agent knows before it asks. A company that sets it listsbrowser_session_endpoint.web.disabled: the company asks agents to use only its company agent and APIs, not its website. It then lists nobrowser_session_endpoint, and must listagentorapis. The spec notes the protocol can't enforce this: it's a stated preference, and "isn't a promise that Personal Agents won't browse".
Direct Sign-In is preferred (§4)
A company that offers sign-in SHOULD offer Direct Sign-In, and an agent SHOULD use it when it's offered. Device Sign-In stays in the spec. The guides point out that it's advised against for sensitive or high-value resources, so such a company may offer only Direct Sign-In.
Approvals can say when and how (Operations §6, §8.1)
An approval can now carry approved_at and input_type, such as tap, typed or voice. Agents SHOULD include both. Like the approval itself, they're the agent's statements, and a company doesn't reject an approval that leaves them out.
What this means if you run a company on 0.3
- Nothing breaks today. 0.3 is frozen, and agents that support 0.3 keep reading your document as it is.
- Plan to serve two versions, not to switch. When you move to 0.4,
supported_versionslets you keep your 0.3 document as well, at its own URL on the same host. - Your extensions block will change shape. Under 0.4, each extension becomes a list of versions. If you list
operations,mediated-sign-inorucp, that's the edit to expect. - Decide what agents may do on your website. Use
web.unscopedif a signed-in browser has full account access, orweb.disabledif you want agents to stay off your website.
What PAP Checker does now
I maintain PAP Checker. As of 5 November it reads a 0.3 document against the frozen 0.3 text, and stops calling 0.3 "in progress". For a 0.3 site, the results still come from the protocol's own validator, pinned at the commit that became 0.3.
A document that declares 0.4 is read with the 0.3 rules for now, and the result says so: some of what it reports may come only from what 0.4 changed. We'll add 0.4's rules (supported_versions, extension lists, web.unscoped, web.disabled) as the draft settles and sites start declaring it.
Check your poppy.json or paste it into the validator.
FAQ
Is Personal Agent Protocol 0.3 final?
Yes. It was published on 4 November 2026 and won't change. The protocol as a whole isn't stable until 1.0, and draft 0.4 is the next version.
Do I need to move from 0.3 to 0.4?
Not now. 0.4 is still a draft. The authors expect it to need little work for a company already on 0.3. When you move, supported_versions lets you serve both.
What is supported_versions?
A new draft 0.4 field in poppy.json. It maps each other protocol version a company serves to the URL of that version's document, on the same host. Agents pick the newest one they're compatible with.
What is the Poppy-Version header?
In draft 0.4, the header in which an agent names the protocol version it uses, on every request in a session. A company rejects a missing or unserved version with version_unsupported.
Why do extensions become lists in 0.4?
So a company can offer more than one major version of an extension at once, and each agent declares the one it uses in the Poppy-Extensions header.
What does web.disabled do?
It asks personal agents not to browse a company's website, and to use its company agent and APIs instead. It's a preference the protocol can't enforce.
Is poppy:read back?
No. poppy:browser-sign-in is the only scope the protocol defines in draft 0.4. It's for an agent's browser joining a session signed in. Every other scope is the company's own.
Sources
- Personal Agent Protocol specification, version 0.3, published 4 November 2026, frozen
- Personal Agent Protocol specification, draft 0.4, in progress (read 5 November 2026)
- Changelog, personalagentprotocol.org (read 5 November 2026)
- Path to 1.0, personalagentprotocol.org, status updated 4 November 2026
- Guides, draft 0.4, personalagentprotocol.org (read 5 November 2026)
- PAP Checker: sites publishing poppy.json, read 5 November 2026