The Personal Agent Protocol (PAP) has emerged as a tangible framework for industry scrutiny with the publication of its initial documentation at personalagentprotocol.org/docs. The site carries the formal stamp “Draft 0.1 Updated Oct 13, 2026,” providing a clear signal that the framework is currently an evolving proposal rather than a finalized industry standard. The documentation is structured into five primary sections: “Introduction, Specification, Extensions, Guides, Path to 1.0.” This organization offers a baseline for developers to evaluate the protocol’s architecture as it moves through its early development phase.
At its technical foundation, the protocol is defined as “an open protocol for how personal agents and companies work together.” It leverages a familiar stack including OAuth, JSON Web Tokens (JWTs), HTTPS, OpenAPI, and the Model Context Protocol (MCP). Discovery is managed via a /.well-known/poppy.json file, which provides a standardized mechanism for agents to identify an organization and locate relevant APIs. The authentication flow is designed to maintain user context, as “The user signs in on the company’s own page through standard OAuth” and explicitly grants access permissions. Once authorized, the system manages state efficiently: “One session covers API calls, conversations, and web browsing. APIs and conversations use a short-lived session token, a signed JWT.”
Despite these functional specifications, the current draft remains a work in progress. There is no reference implementation available on the site, and the protocol is explicitly labeled as a draft. Furthermore, the core specification is kept intentionally lean, with complex features relegated to the extension layer. The documentation notes that these extensions allow developers to “add things like payments, push notifications, or interactive elements.” This modular approach is intended to prevent the feature bloat that has historically hindered other standardization efforts in the agent space.
This release arrives as the broader infrastructure landscape faces significant friction. The A2A Registry, once viewed as a central hub for agent-to-agent coordination, has effectively stalled, as evidenced by the closure of A2A GitHub Discussion #741. The maintainer noted that the process “led to consensus around the following standards: AI Catalog specification… ARD specification” which handles dynamic discovery as federated search. This shift highlights the reality that while A2A compliance labels now ship, the underlying specifications have struggled to reach maturity, with five incompatible implementations currently in the wild.
For builders and investors, the market bifurcation is increasingly apparent. While tool discovery via the MCP Registry continues to gain momentum, agent-to-agent governance remains trapped in a cycle of debate. This follows the pattern visible in unshipped October specs, further complicating the path toward interoperability. The industry is navigating a complex identity convergence shift, where establishing trust architectures is taking precedence over broader registry efforts.
The current state of agent infrastructure is perhaps best exemplified by the Gemini governance stack, which underscores that private previews often precede public standards. In this context, the PAP draft serves as a necessary reference point for those tracking the evolution of agent-company interactions. By keeping the core lean and focusing on a clear path to maturity, the project aims to avoid the pitfalls of its predecessors.
The project’s own roadmap is transparent about its current limitations. Regarding the future of the framework, the documentation states: “It’s a draft, and we are working with design partners to get it to 1.0.” This collaborative approach is intended to refine the specification before it reaches a production-ready state. For now, the protocol provides a concrete, auditable document for builders to assess, rather than a finalized standard ready for immediate, large-scale deployment.
Ultimately, the arrival of the PAP draft moves the conversation from assertion to measurement. Builders can now read the spec itself and assess what it covers: discovery via poppy.json, OAuth-based sign-in with JWT sessions, and extensibility through a principles-first framework. What it does not cover – a reference implementation, a payments path, or governance enforcement – defines where the real work remains. Whether the industry builds on this foundation or fragments around it depends on design partner adoption and the pace of v0.1 hardening into a standard the market can trust.