The market doesn't care about your protocol's ambition. It cares about who deploys it, who secures it, and who has the leverage to make it stick.
That's the lesson from the Agent interoperability landscape right now. A new draft spec, the Personal Agent Protocol (PAP) v0.1, landed on October 13, 2026 — or so the document claims. The date is a red flag. It's either a placeholder, a typo, or we're reading a document from the future. The second anomaly is equally telling: the protocol is hosted at personalagentprotocol.org, but the discovery file is named /.well-known/poppy.json. Poppy vs. PAP. Either someone rebranded mid-stream, or this is a codename that stuck. Both anomalies matter because they signal a project that hasn't fully committed to its own narrative yet.
Let's strip the noise. PAP is an open protocol for agent-enterprise interoperability. It defines how a personal agent authenticates, discovers, and maintains sessions with enterprise systems. The draft is structured in five parts: Introduction, Specification, Extensions, Guides, and Path to 1.0. That's a mature skeleton. But the substance is where the story gets complicated.
The Core: A Web2.5 Bridge, Not a Web3 Native
Based on my audit experience with standard proposals, the first thing I look for is the foundation. PAP's foundation is OAuth 2.0 for authorization, JWT for session tokens, HTTPS for transport, OpenAPI for interface description, and MCP for tool context. That's it. No DID. No on-chain signatures. No zero-knowledge proofs. No wallet addresses. The word "blockchain" appears nowhere in the technical stack.
This creates a domain drift problem. If you're tagging this as a Web3 project, you're selling a Web2.5 bridge to a Web3 audience. The protocol is essentially a careful assembly of existing Web standards — OAuth plus JWT plus well-known URIs. It's pragmatic. It's low-friction. But it's not crypto-native. The trust anchor is a centralized enterprise login page, not a decentralized identity.
Here's where the design philosophy gets interesting. PAP uses a "minimal kernel plus extension layer" architecture. The core spec is deliberately lean. Payments, push notifications, and interactive elements are pushed to extensions. The author explicitly states this is to prevent "feature creep that has historically hindered standardization efforts in the agent space." That's a direct, unspoken rebuke of A2A's failure. The author learned the lesson: A2A died in a governance quagmire, splintered into five incompatible implementations. PAP's modularity is a defense mechanism.
But there's a gaping hole. There's no reference implementation. In the standards game, a spec without a reference implementation is a wish. A2A had five incompatible implementations, which at least proved demand. PAP has zero. The risk is immediate: interpretation ambiguity leads to implementation divergence. We've seen this movie. I'm not watching the sequel without a reference build.
The Contrarian Angle: The Market Doesn't Want Coordination Yet
We didn't expect this, but the market is voting with its resources. MCP Registry is gaining momentum as the de facto standard for tool discovery. Meanwhile, A2A's agent-to-agent coordination work is stalled — Discussion #741 closed, governance looped in on itself. The market has made a choice: solve tool calling first, agent coordination second. PAP is solving the second problem before the first is settled.
This is the blind spot. PAP's positioning is smart — it focuses on identity, authentication, and session management, which aligns with the industry's broader pivot toward "trust architecture over registry sprawl." But that pivot is real only if the tools layer is stable. Right now, MCP owns the tool layer. PAP sits on top of MCP, which is either a strategic complement or a dependency trap. If MCP's ecosystem decides to absorb the identity layer, PAP's independence evaporates.
The big tech shadow looms. Google's Gemini governance stack is in private preview. That's the classic platform play: build a private implementation, lock in ecosystem partners, then push a public standard that favors your architecture. For an open draft like PAP, that's an asymmetric threat. You can't out-execute Google's distribution advantage. You can only out-position them on openness. PAP's "minimal kernel" is a good position, but the draft doesn't articulate a governance mechanism to resist capture.
Takeaway: The Next Narrative Is Compute-for-Equity
Here's the forward-looking judgment. PAP's extension layer includes a "payment path" that's explicitly not yet covered. The author calls it "the real work ahead." That's the hook. When payments arrive, the token economy question returns — not as a speculation vector, but as a compute-for-equity mechanism. Agents will need to transact autonomously. Stablecoin settlement on-chain becomes the natural rail.
That's where Web3 finally intersects. Not in the identity layer, but in the settlement layer. The question is whether PAP survives long enough to reach that intersection. The draft is honest, the architecture is disciplined, but the governance is opaque and the team is anonymous.
The market doesn't care about your protocol's ambition. It cares about who deploys the reference implementation, who takes responsibility for the spec, and who stands behind it. The draft has landed. The standard behind it has not. Until the design partners are named and the code is shipped, PAP remains a well-structured hypothesis in a fragmented market — a candidate for convergence that has yet to prove it can converge anything.
