The Draft Spec Has Landed. The Standard Behind It Has Not.

Two anomalies. That's what I found when I pulled the Personal Agent Protocol draft apart at 3 a.m. Dublin time, and either one alone would have made me slow down. The first: the document is stamped "Oct 13, 2026." A future date. Either a placeholder someone forgot to scrub, a typesetting error, or — the version I can't rule out — metadata from an article meant to publish later. When a spec can't get its own timestamp straight, you start asking what else is decorative. The second is worse. The protocol lives at personalagentprotocol.org. Clean, corporate, descriptive. But the discovery file it asks every company to deploy is named /.well-known/poppy.json. Poppy. Not PAP. A different name entirely. That's a rebrand scar. Somewhere between the whiteboard and the draft, "Poppy" became "PAP," and nobody updated the plumbing. In my experience covering protocols, name drift is never cosmetic. It's the visible edge of a pivot nobody wants to announce. Red candles don't lie, and neither do orphaned filenames. So I did what I always do. I stopped reading the marketing and started reading the dependencies. Here's the landscape PAP is walking into. The AI agent standardization race is not converging. It's fracturing, and it's fracturing fast. A2A — the protocol that was supposed to be the coordination hub for agent-to-agent communication — is effectively stalled. Its registry discussion, thread #741, is closed. The energy has moved sideways into an "AI Catalog" and something called ARD. Meanwhile MCP, the Model Context Protocol, keeps gaining traction as the de facto standard for tool discovery. Google's Gemini governance stack sits in private preview, shipping to partners before any public standard exists. And somewhere in that mess, five incompatible implementations of agent coordination are already running. Five. Not one draft with five contributors — five separate codebases that can't talk to each other. This is what a standards war looks like from the inside. Not a clean race with a finish line. A bar fight where everyone claims to be winning. Into that bar walks PAP v0.1. An open protocol. No token. No blockchain. Just a spec, a discovery file, and a promise that it's working "with design partners." The draft itself is structured like a serious standard. Five sections — Introduction, Specification, Extensions, Guides, and "Path to 1.0." That skeleton is borrowed straight from mature standards bodies. It's the kind of documentation that makes a project look funded even when you can't find the funding. And the framing is deliberately modest: the author says the draft moves the conversation "from assertion to measurement," offering an auditable document for builders to evaluate rather than a victory lap. That restraint is unusual, and it's either maturity or very good marketing. I've seen this movie. In late 2017, while finishing my economics degree in Dublin, I infiltrated three ICO Telegram groups promising instant 10x returns and found zero GitHub commits across all three. The tell wasn't the whitepaper. The tell was what the whitepaper left out. PAP leaves out a lot. But what it includes is more interesting than what it hides. Let me give you the honest technical read, because the stack tells the whole story. PAP's identity layer is OAuth. Its session layer is JWT. Its transport is HTTPS. Its interface description is OpenAPI. And it explicitly wraps MCP for tool context. That's the entire protocol. OAuth. JWT. HTTPS. OpenAPI. MCP. Now count the blockchain primitives. I'll wait. There are none. No DID. No on-chain signatures. No zero-knowledge proofs. No wallet addresses. No smart contracts. No sequencer, no rollup, no bridge. The trust anchor is a company's own login page. The user authenticates on the enterprise's own domain, receives a short-lived JWT, and the agent carries that token around like a visitor badge. This is not a Web3 protocol. It's a Web2.5 bridge. It's OAuth wearing an agent costume. And that's not a criticism — it's a classification. Because the report I'm working from filed PAP under "Blockchain/Web3," and that label is wrong in a way that matters. Market this to crypto natives and you're selling a fishing rod in a desert. The actual buyer is an enterprise SaaS team that already runs OAuth and just wants its API callable by an AI agent. The architecture is smarter than the stack suggests. PAP uses a "minimal core plus extension layer" design. Payments, push notifications, interactive elements — all pushed down into extensions, out of the core spec. The author is explicit about why: to prevent the feature bloat that has historically killed agent standardization efforts. That's a direct shot at A2A. A2A tried to solve everything at once, and now it's a museum piece with five incompatible wings. PAP looked at that wreck and said: we ship the skeleton, we let the extensions fight it out later. And understand what the MCP dependency means. PAP doesn't try to replace MCP. It sits beside it. MCP handles what tools an agent can call; PAP handles who the agent is and what it's allowed to do. That's smart positioning — it turns a potential competitor into a host ecosystem. But it also means PAP's ceiling is set by MCP's floor. If the tool-discovery layer decides to absorb identity into itself, PAP becomes a redundant middleman overnight. The protocol is betting that identity stays a separate problem. That bet is not guaranteed. The discovery mechanism is the cleverest part, and it's almost aggressively boring. Companies deploy a static JSON file at /.well-known/poppy.json. That's it. No chain, no token, no permission. Reuse RFC 8615's well-known URI convention, and any company with a web server is instantly reachable. Low friction. High adoption potential. And zero censorship resistance. A protocol that lives at a well-known URL is a protocol any DNS provider, any CDN, any hosting company can switch off. There's no decentralization here, and to PAP's credit, it isn't pretending there is. The performance data is a blank too. No TPS, no latency, no throughput. For a Web2 stack that's almost fine — HTTPS and OAuth don't need throughput claims. But it means you're evaluating a protocol with zero benchmarks, zero load tests, and zero real deployments. You're grading a blueprint. So here's my core finding. PAP is a well-assembled bridge between enterprise identity and AI agents. It is not a breakthrough. It is not decentralized. And it has no working code. That last point is the one that should keep you up at night. Everyone's going to focus on the tech. I'm going to focus on the black box, because that's where the real risk lives. PAP has no reference implementation. None. Draft 0.1, and not a single line of runnable code. In standardization, a spec with no reference implementation doesn't fail because it's wrong. It fails because it's ambiguous — and ambiguity breeds forks. I have a precedent, and it's sitting right there in the data: A2A's five incompatible implementations. Five teams read the same spec, made five different reasonable interpretations, and shipped five products that can't interoperate. That is the default outcome for any standard without a reference implementation and a conformance suite. PAP has neither. And it has no visible governance mechanism to resolve the disputes ambiguity will create. Now here's the part nobody's writing about. PAP's entire future rests on one phrase: "we are working with design partners." That's it. That's the whole foundation. No named partners. No count. No industry. No logos. Just "we." Compare that to how mature standards work. W3C publishes editor names. IETF has working group chairs. Even scrappy open-source protocols have a contributor graph you can pull in ten seconds. PAP gives you a first-person "we" and a blank space where accountability should sit. I've done this kind of analysis before. After the 2024 spot Bitcoin ETF approval, I spent weeks inside SEC filings and Dublin compliance offices, because custody detail is where institutional risk hides. The lesson never changes: follow the accountable entity. When there's no accountable entity, the risk doesn't vanish. It just becomes unpriceable. The design partners are PAP's only claim to legitimacy, and they're invisible. If those partners are enterprise identity providers — Okta, Auth0, that tier — PAP is real and I'm wrong to be skeptical. If they're vapor, PAP is a very professional-looking ghost. And notice the design bias. The auth flow has users logging in on the company's own page. Not a community portal. Not a DAO. The company. This was built to serve enterprise agent access, and the governance model says the same thing: single-entity control, open-sourced for credibility, with v1.0's definition reserved to whoever wrote v0.1. There's a regulatory layer to this too. PAP's stack — OAuth authorization, JWT sessions, agent access to enterprise data — walks straight into GDPR and CCPA territory. Who is the data controller when an agent acts on your behalf? What's the scope of consent? Where's the audit trail? The draft doesn't say. It's a clean technical spec that quietly offloads all the hard privacy questions onto whichever company deploys it. That's convenient for PAP. It's less convenient for the enterprise that has to answer to a regulator. This is platform governance wearing open-source clothes. Wash trading: the digital casino taught me to read the order book, not the marketing. Here, the order book is the governance model. And it's one-sided. So what do you actually watch? Forget the feature list. Three signals will tell you whether PAP is a standard or a press release. First: does a reference implementation ship? Not a demo, not a sandbox — a repo you can clone and run. Until that exists, PAP is a PDF with ambitions, and every week without it raises the odds of an A2A-style fork spiral. Second: do the design partners get named? The moment real logos appear, the ambiguity tax collapses and adoption becomes a numbers game. If six months pass and they're still anonymous "design partners," treat the whole thing as a design exercise. Third — the one I'll be tracking hardest — watch the payment extension. Right now PAP has no token, no economics, no value capture. That's deliberate. It dodges securities law, it dodges speculation, it keeps enterprises comfortable. But the extension layer reserves a payment path, and the author calls that the place where "the real work" lives. If PAP ever wants to monetize, that extension is the door — and it's the only door through which stablecoins and on-chain settlement could walk into this protocol. And keep one more thing in view: the unreleased October spec. The report flags an unannounced specification still pending. If that turns out to be PAP's own v1.0, the ambiguity resolves upward. If it's a competitor's move, PAP's window closes. Either way, the calendar is working against a draft that already has a filename from a future it hasn't reached. That's the whole thesis. PAP is a mature, restrained, well-architected spec built on Web2 rails, and its fate has almost nothing to do with how good the code is. Exit liquidity is someone else — value here flows to whoever controls the identity layer, and right now that's an unnamed "we" with a mistyped filename and a date from the future. The draft landed. The standard hasn't. Watch the repo, watch the logos, watch the payment path. Those three things will tell you the truth long before the roadmap does.