Personal Agent Protocol now has a public draft. Sierra published Poppy Draft 0.1 on 9 October 2026, moving the discussion beyond its initial announcement. It proposes a shared way for an AI assistant to identify itself, obtain appropriate account access and work with a participating company.
What Sierra released—and what is still planned
Sierra’s 9 October announcement shares the draft and names additional design partners. It says design workshops and a reference implementation are planned over the next month. Those are future steps; this announcement does not establish that the reference implementation is available today.
For an everyday user, the potential benefit is clearer cooperation between an assistant and a business. For a SaaS operator, the question is whether that cooperation can be implemented with permissions the company can understand and enforce. Neither audience needs to treat a draft announcement as a reason to replace working tools immediately.
The publication gives developers something concrete to examine. That is a meaningful milestone, while compatibility, adoption and implementation quality remain separate questions. A company listed as a design partner may contribute feedback without already offering a public production connection.
How Personal Agent Protocol works in plain English
The Draft 0.1 specification covers discovery, authorization, browsing, APIs and conversations. A company publishes a discovery document at /.well-known/poppy.json. This tells an agent which interfaces and sign-in routes the company supports.
The proposed session connects activity across those interfaces. Direct sign-in lets the person use the company’s own authorization page. Device sign-in offers a link and code; mediated sign-in lets an agent submit credentials where the company supports that route. These are distinct options, rather than a rule that passwords must always be shared with an assistant.
The specification distinguishes short-lived session tokens from longer-lived account credentials. It also warns that any part of version 0.1 can change before a stable release, including incompatibly. Teams should therefore record the version they implement and plan for revisions.
In practical terms, finding the right interface, proving account access and performing a permitted action are different stages. A protocol can describe that sequence without deciding every business’s refund policy, billing conditions or account permissions.
What users and SaaS teams could gain
The official project overview describes companies choosing which agents to allow, how people sign in and whether access permits reading, changes or both. Participating services can expose websites, OpenAPI interfaces, MCP servers or their own agents.
Imagine asking an assistant to investigate why a software subscription renewed. This is an illustrative workflow, not a demonstration we tested. A useful sequence would be to read the renewal terms, retrieve the relevant account information, explain the available choices and ask before changing anything consequential.
For a creator, that could reduce the need to repeat a problem across support channels. For a small software company, it could make agent traffic easier to distinguish from ordinary browsing. Whether either benefit appears in practice depends on implementation and the specific services involved; the protocol announcement does not prove faster support or lower costs.
Our Gemini agent-for-work guide discusses a product-level work-agent announcement. Poppy addresses a different layer: how a personal agent and a participating company communicate and authorize activity. A product’s availability does not automatically imply support for this protocol.
The optional approval extension deserves close attention
The project’s operations extension defines a proposal, approval, confirmation and result sequence for consequential actions. It is optional. Companies may require a fresh user approval or allow an earlier permission, depending on the operation’s terms.
The draft ties approval to a particular revision and gives an action one operation identifier across channels. It specifies that retries must not perform the same action twice. These are protocol requirements, not independently verified performance or security guarantees.
This distinction matters for an account change. “Your assistant has access” is broader than “you approved this exact change.” A useful approval screen should say which account is affected, what changes, any cost and when the change takes effect. If those details change, the original approval should not be treated as permission for the new proposal.
| Area | Question for the provider | Why it matters |
|---|---|---|
| Current support | Which draft version and interfaces are implemented? | A partner logo alone does not prove compatibility. |
| Account scope | Can access be limited to reading or a specific task? | One request should not grant unnecessary control. |
| Approval | Does the service use the operations extension for this action? | The extension is optional, not universal. |
| Retries | How can a user inspect a pending operation after a timeout? | Uncertainty should not silently create a duplicate change. |
| Revocation | How does the account owner end continuing access? | Permission needs a usable exit path. |
| Human support | What happens when the task needs a person? | Automation should have a clear escalation route. |
Use a test account and a reversible change for any future pilot. Keep the requested terms, approval and service-confirmed result together. This is our proposed evaluation approach; AIX Radar has not run a Poppy integration or measured its reliability.
Draft gaps and reasons to avoid rushing adoption
The official open-topics page identifies payments, push notifications and attachments as larger areas the draft does not yet cover. It says the list is incomplete. Do not infer that the core draft already defines a complete payment or asynchronous notification system.
For a small business, the sensible first step is an inventory of the customer tasks it might expose. Identify the permissions and approval conditions for each. A support-status lookup and a subscription cancellation deserve different controls even if they share the same account session.
Teams already exposing an API should assess the new authorization and session requirements before promising compatibility. Publishing a discovery file by itself does not demonstrate an end-to-end implementation. Keep experimental access separate from a promise that customers can use any personal agent today.
Personal Agent Protocol FAQ
Is Poppy available to read now?
Yes. The public specification identifies itself as Draft 0.1, updated on 9 October. Its content can change before a stable version.
Is Poppy the same as MCP?
No. Poppy’s draft can advertise an MCP interface, while also describing sign-in, sessions, browsing and conversations. Supporting MCP alone does not establish support for all of Poppy.
Do the named partners all have live integrations?
The announcement does not establish that. Confirm support for the particular service, agent and workflow you intend to use.
Should everyday users install something immediately?
This is a protocol milestone. Wait for a service you use to explain its actual support, permissions and availability. The useful advance is a more explicit proposal for cooperation, with adoption still to be demonstrated.
Reporting cutoff: 10 October 2026, 17:59 Pakistan time. Official draft documentation supplies the technical facts. Examples and evaluation questions are original editorial analysis, not hands-on results.
