Personal Agent Protocol introduces a common interface for personal AI agents working with businesses on a customer’s behalf. Developed by Meta and Sierra with industry partners, the initiative connects discovery, authorization, and service channels into a shared interaction model. Its public draft, nicknamed Poppy, appeared on October 9, 2026. The leadership opportunity is to make delegated service easier to support and govern. The practical challenge is ensuring that permissions, business rules, and escalation paths remain effective when an agent becomes the customer’s representative.
Table of Contents #
- Prepare for represented customers. Businesses should consider how service journeys change when a personal agent handles the interaction.
- Make authority explicit. Customer consent and business permissions need enforceable boundaries across every supported channel.
- Pilot with evidence. Adoption decisions should depend on completed tasks, retained control, and integration effort.
What Personal Agent Protocol establishes #
The central proposition is straightforward: customers choose an agent to represent them, and businesses define how that agent can interact with their services. Personal Agent Protocol supplies a proposed common foundation for that relationship.
In its October 9 draft announcement, Sierra named 35 additional design partners, including OpenAI, Okta, Visa, and United Airlines. Participation shows interest across identity, payments, travel, and customer service; it does not establish that these organizations have deployed interoperable production services.
This development extends the delegation question explored in DevNavigator’s Muse AI agent analysis. A capable personal assistant needs businesses that can recognize its role and support its requests. Leaders should examine both sides of that interaction when assessing readiness.
How Personal Agent Protocol connects the journey #
The public Draft 0.1 specification describes discovery through a company-hosted file at /.well-known/poppy.json. The agent identifies itself and starts a session. When account access is required, supported sign-in flows grant the agreed scope.
Personal Agent Protocol connects that session across website browsing, APIs, and conversations with a company agent. It builds on established technologies, including OAuth, JWTs, HTTPS, MCP, and OpenAPI.
Consider a hypothetical jacket return. A customer delegates the request, approves account access, and the agent uses the retailer’s supported channel. The useful outcome is an accepted return with clear instructions and a confirmation the customer can verify. A connected session alone cannot determine eligibility, resolve conflicting policies, or guarantee successful completion.
Permissions become a service design decision #
Personal Agent Protocol gives teams a reason to review the authority behind each customer task. Reading an order, requesting a return, changing an address, and updating payment details carry different consequences. Treating them as one broad permission would make delegation harder to understand and supervise.
My recommendation is to define permissions around recognizable customer outcomes. Explain what access allows, where confirmation is required, and how the customer can withdraw authorization. Test the same restrictions through every channel the pilot exposes.
Human handoffs deserve equal attention. If an agent cannot resolve an exception, the receiving employee should have enough context to understand the request, prior actions, and remaining decision. Otherwise, automation may simply move coordination work to another team.
Measure outcomes while the standard evolves #
Personal Agent Protocol remains a draft that can change before a stable release. Payments and push notifications are listed among its open topics. Design participation and demonstrations should therefore be separated from evidence of broad adoption or operational reliability.
Start with one bounded service journey and a clearly defined completion condition. Compare accepted task completion, elapsed time, customer effort, correction rates, and support escalations against the existing process. Include implementation and supervision costs when judging value.
Also test failure behavior: expired authorization, rejected requests, unavailable channels, and a customer changing their mind. These cases reveal whether the workflow preserves control when the happy path breaks.
The strategic opportunity is a more usable interface between customers’ agents and business services. Invest first in clear permissions, reliable service APIs, and accountable escalation paths, then use pilot evidence to decide how far to expand.