Personal Agent Protocol adoption¶

Status: Draft | Last reviewed: 2026-10-20

Adopt Personal Agent Protocol (Poppy) as a customer access layer over published TrueServe agents, business tools and workflows. Read this proposal when planning experiences in which a customer's own assistant discovers a company, obtains delegated access, completes work and involves people when needed.

This page describes the adoption roadmap and the first implemented pilot. Repository evidence comes from the current Vanguard working tree, based on commit c1529653ab04e442d26766a59cae795dd8e6a673, including local changes. It is not a verification of an official Dev, QA or production deployment.

Recommended product boundary¶

Implement the Company role first: TrueServe hosts a company's service agent and customer capabilities, and external personal assistants are its clients. Offer this through an Assistant access publication setting with a compatibility report.

For the next account-enabled increment, add Direct Sign-In, a small customer API and native Poppy conversations to one reviewed company agent. Add transactional access through the Operations extension and a real human queue before expanding the pilot. Make the return journey in Personal assistant Scenes the acceptance scenario.

Run the Personal Agent role in the separate Ari/OpenMuse app at assistant.<city-domain>, using Studio identity and tenant isolation. Keep this owner application separate from the inbound Company gateway. The current pilot supports explicit operation approvals; standing permissions remain future work.

Implemented pilot¶

The Ari Assistant is a separate app at https://assistant.vanguard.dev.trueserve.deloitte.com, with Ari branding, workspace appearance settings and an optional phone shell. It uses the actual OpenMuse TanStack engine with a focused web interface; it is not the full upstream OpenMuse application. Existing Studio users and tenants sign in through PKCE OAuth. Studio retains each tenant's model credentials.

The Company gateway exposes explicitly reviewed published Chat Agent versions on separate Company hostnames. Its initial profile supports guest sessions, ES256/DPoP and durable native conversations. It does not advertise Company account grants, Operations or other business interfaces. Later Studio publication requires an explicit Poppy update; existing conversations retain their original runtime version.

The client additionally supports external Company Direct Sign-In and Operations v1 through explicit owner approval. Its protocol lab stores per-check results, discovery/version snapshots and before/after comparisons. Unexercised account, human and transaction scenarios remain visibly separate from passed checks. Publication is currently through the management API or operator CLI; the Studio publication settings UI below is roadmap work. See the browser walkthrough.

Protocol fit¶

Draft 0.2 combines discovery, customer delegation, APIs, conversations and optional browser continuity. Discovery is /.well-known/poppy.json. The defined conversation transport is type: "poppy"; existing A2A support therefore needs a separate adapter. OpenAPI and MCP expose business capabilities alongside conversation. [S1]

Its useful distinctions are:

A Personal Agent identity differs from the customer account it can access.
A protocol Session differs from a conversation and a runtime connection.
Account access and approval of a particular transaction are separate.
Human participation exists on both the customer and company sides. [S1, S2]

The protocol remains a draft with potentially incompatible revisions. Payments, push notifications and attachments are listed as open topics; account for those limits in the product promise. [S4]

Existing foundation and gaps¶

Area	Evidence in the working tree	Adoption work
Agent publication	Agent/version model separates identity from runtime configuration.	Publish a reviewed exposure pointing to an immutable agent version and capability contract.
Customer A2A	`run_agent_turn` creates a runtime session for each turn and closes it afterward.	Add durable conversation ownership and runtime resumption through a native Poppy adapter.
Conversation authentication	`AuthContext` represents tenant, agent and conversation scope.	Add a distinct delegated principal carrying company, client, customer and account authority.
Management OAuth	External management transports already implement PKCE, resource restrictions, hashed tokens and rotating refresh families.	Reuse reviewed primitives; introduce a customer grant domain with its own issuer and policies.
Customer verification	Customer Authentication owns verification evidence independently of mutable session variables.	Bind trusted account authentication to an OAuth consent grant. Verification alone does not grant delegated access.
Tools and workflows	agent-host supports named workflow tools and execution receipts; async-agent persists workflow state.	Add customer ownership checks, operation receipts and authorization propagation through execution.
Human experiences	Customer components support trusted conversation links and saved interactions.	Connect a real queue and representative identity to protocol handoff and operation controls.
Personal assistant demos	Scenes replay authored assistant, browser and representative exchanges.	Replace the pilot's replayed business outcomes with protocol calls and sandbox business records.

The existing AI counterparty detector is explicitly advisory. Preserve that distinction: a verified protocol client, a claimed human-authored message, customer authentication and an estimated AI likelihood are different facts.

Target architecture¶

The pilot runs apps/conversation-api/poppy as its own gateway process with an explicit external authentication boundary and a separate protocol database. The Ari app has its own process, hostname and database. Keep future business authorization and operation execution in shared services behind these boundaries.

flowchart LR
    PA["Customer's personal assistant"] --> EDGE["Company domain and Poppy adapter"]
    EDGE --> AUTH["Customer issuer and delegated grants"]
    EDGE --> CONV["Durable conversation service"]
    EDGE --> CAP["Customer capability API"]
    CONV --> RUNTIME["Published TrueServe agent"]
    CONV --> HUMAN["Representative queue and workspace"]
    RUNTIME --> POLICY["Shared authorization and operation service"]
    HUMAN --> POLICY
    CAP --> POLICY
    POLICY --> WORK["Tools, workflows and business systems"]
    STUDIO["Agent Studio publication"] -.-> EDGE
    STUDIO -.-> RUNTIME

Source: personal-agent-protocol-adoption.mmd.

Use the same business handlers behind the customer API, the company agent's tools and representative actions. A routine lookup can complete directly through an API; an exception can move into conversation with the same account and business references.

Publication and discovery¶

Add a company configuration owned by a tenant, with verified domains, issuer, customer identity-provider connection, consent presentation and client-admission policy. Permit multiple company configurations within a tenant when it operates separate businesses.

Each independent company needs its own issuer. Serve discovery on that company's domain and validate the domain/issuer association in both directions. Shared infrastructure is compatible with separate company identities. [S1, S2]

Publish one company-facing agent entry point initially. Route to specialist agents and workflows behind that entry point through trusted configuration. The external request cannot select arbitrary internal agent IDs.

Keep agent-specific exposure behavior on a proposed agent_versions.config.assistant_access contract, following the existing version model. A published exposure record pins the agent version, public API/schema revision, permitted tools and operation policies. Revalidate those dependencies before publishing; a newly added internal tool must not become publicly callable automatically.

The Studio form uses fields and pickers for capabilities, scopes and handoff configuration. Generate discovery and public API descriptions from the approved exposure. Extend the config schema generator when the configuration field is implemented.

Publication checks require text-capable stages and useful text/data results for every exposed capability. Audio-only agents and tools that require a particular browser UI need an explicit compatible entry point before publication.

Identity and delegated authorization¶

Introduce a server-owned DelegatedPrincipal with company/tenant identity, authenticated client, opaque customer subject, protocol session, optional customer account, granted scopes, resource restriction and grant reference. Pass an authenticated internal representation to runtime services; models receive only the business context they need.

Keep this principal out of user-editable session variables. Tool arguments, conversation context, detector results and model assertions cannot replace it. Check account ownership and current permissions at the business handler immediately before each read or proposed mutation.

Use Direct Sign-In for the first account-enabled release. Integrate the company's customer login and show the assistant identity, account, permissions and connection lifetime. Add an account-settings view for inspecting and disconnecting connected assistants. A prototype verification result cannot create a live grant.

Prefer narrow business scopes such as orders:read, returns:propose and returns:confirm. Declare their meanings in discovery. Define a reviewed mapping from each public capability to scopes, account ownership, allowed fields and approval policy. Studio's existing management scopes continue to describe workforce administration.

Implement the identity, grant and DPoP requirements in specification sections 4.1–4.9 as a dedicated conformance unit. Include issuer/audience validation, client metadata verification, proof-to-token binding, replay protection, renewal and revocation. DPoP is required outside the specific MCP Bearer-token exception. [S1]

For TrueServe, choose distributed replay protection for mutation endpoints as well as token issuance, bounded metadata fetches, and validation against configured public origins behind proxies. Store token handles hashed where possible, redact credentials before tracing, and fail closed when authority cannot be established.

Customer revocation must affect new requests and open event subscriptions promptly. Preserve token-specific privilege snapshots: upgrading one session cannot upgrade a previously issued guest token. Retain historical account binding to prevent account switching inside a session. Account-bound history must require renewed authorization after sign-out. [S1]

Durable conversations¶

Build the protocol conversation service around persisted ownership, ordered events and a resumable runtime binding. The current A2A turn helper supplies useful runtime integration code, but its per-turn lifecycle cannot own this service.

Proposed responsibilities:

Record or component	Responsibility
Company/exposure registry	Tenant ownership, verified issuer/domains and published version selection
Session and account-grant store	Delegated principal, historical account binding, expiry and revocation
Protocol conversation binding	Public conversation ID, owner, core conversation reference, pinned runtime version and optional parent
Protocol event ledger	Immutable public event envelopes, ordered cursor replay and retention
Message receipt store	Atomic acceptance and deduplication before runtime dispatch
Operation/revision store	Proposed terms, confirmation evidence, downstream receipt and final outcome
Transactional outbox	Reliable dispatch and event projection after database commit

Apply tenant RLS to new tenant-owned records and explicit company/client/customer/account predicates within each tenant. Reuse existing conversation persistence where it fits; do not make a Redis connection or process-local map the durable authority.

Implement specification section 7 as a state machine, including first-message retries, context-only input, authorization changes, handoff, direct child conversations and closure. Preserve the distinction between the current responder and each message's author. Native events need their own projection; internal transcript and A2UI frames are not already protocol envelopes. [S1]

A disconnected client releases its stream resources while durable work continues. Offer JSON/long polling and SSE over the same event ledger. Resume the pinned runtime from stored conversation state when needed. A queued human conversation should not occupy a voice connection or an idle model invocation.

Commit accepted input and its dispatch receipt together. Deduplicate message IDs within company/client/customer ownership across conversations, and check authorization before returning an earlier receipt. Use an outbox for runtime delivery, receiver-side input deduplication and a stable source-event key for output projection. Represent provisional text separately from committed replies. Cap buffers and polling waits; preserve replay after a different service instance handles the reconnect.

Protect Poppy-owned customer conversations from alternate access through generic chat or share-code routes. Representative access remains an authenticated workforce path, with delegated permissions attached to actions taken for this request.

Shared transactional operations¶

Require Operations extension support for the pilot's consequential changes. It offers a revisioned proposal and confirmation record across channels, with at-most-once execution and an explicit final result. Approval is the personal assistant's attestation; it does not prove that a person actually saw or approved the terms. [S3]

Use a dedicated operation service to implement that contract:

A business handler proposes complete terms and a plain-language summary from the same validated data.
Store each revision immutably, with expiry, account binding and approval policy.
Confirmation atomically checks authority and the current revision, records the decision and creates an execution outbox entry.
Execute through an audited business adapter with the operation ID as its durable correlation and downstream idempotency key.
Reconcile an ambiguous downstream response before deciding whether another invocation is safe.
Return the business receipt and all material effects, including partial effects.

Set user_approval_required for the initial transactional pilot. For actions needing stronger evidence, use a company-controlled, authenticated confirmation experience bound to the same operation revision. A chat message saying “approved” is not the operation confirmation.

Repeated confirmations must not cause repeated execution. A downstream timeout remains in_progress until reconciled. Already confirmed operations continue across token expiry or sign-out; cancellation is a separate request and may not undo completed effects. [S3]

A workflow execution ID is evidence of accepted work, not proof that an exchange or refund completed. If a downstream system cannot deduplicate or determine the outcome of a request, route that action to an explicit reconciliation process before enabling automated completion.

Clients without the extension can retain informational access. A transactional capability that requires it returns the appropriate extension-required response, or an ordinary tool error for an individual MCP tool. [S3]

Assistant-first experience¶

Author a concise company-agent behavior profile that:

Uses verified account context and accepts useful structured task details.
Returns business facts and options in typed data with a readable explanation.
Asks only for missing facts or decisions that change the outcome.
Respects whether the owner is available and saves work while waiting.
Produces durable references and outcomes that the personal assistant can show later.
Adapts its language when a customer or representative joins.

Give representatives an Assistant request view containing the customer account, verified client domain, request summary, granted permissions, requested decision, conversation history and operation state. Keep permissions visible at the controls that execute an action.

Keep A2UI as a human presentation option over those facts. External assistants need usable text and business data independently of a TrueServe component renderer.

The pilot journey is:

The owner asks their assistant to return an item, with a constraint on acceptable resolutions.
The assistant discovers the company and opens a guest session.
The owner connects their customer account when order access is needed.
The assistant retrieves the order through the customer API and asks the company agent about an exception.
A real representative receives the history and permitted actions through a queue.
The representative proposes an operation; the assistant brings its terms to the owner.
The assistant confirms the approved revision and receives a durable business outcome.
A retry or reconnect retrieves the same operation and conversation without repeating the transaction.

The Scene provides the experience reference. The acceptance test uses an independent protocol client, sandbox customer identity, a sandbox order system and an actual representative session.

Delivery sequence¶

Stage	Scope	Exit evidence
Foundation spike	Pin draft 0.2; establish company discovery, customer issuer, client identity and DPoP; select the business and queue adapters.	Positive and negative protocol tests across two isolated companies and multiple service instances.
Read-only preview	Published text agent, Direct Sign-In, narrow customer API, durable native conversations and the full required conversation lifecycle.	Independent client completes account lookup, human/direct participation, renewal and reconnect without unauthorized disclosure.
Transactional pilot	Operations v1, one return/exchange adapter, representative controls and reconciliation.	One approved revision causes one business effect under retries, concurrency and simulated failures.
Supported release	Studio publication checks, tenant controls, client onboarding, monitoring, retention, runbooks and compatibility policy.	Documented support matrix and repeatable customer onboarding with regression evidence.

Evaluate Device Sign-In next for clients that cannot conveniently receive a browser redirect. Add a curated MCP surface when a target client needs it, including its own resource/audience and authorization behavior. Browser-session support follows a specific website requirement; credential-mediated sign-in needs a separate product decision.

Validation and support¶

Pin the upstream schema/validator snapshot by commit, and keep version-specific codecs behind the adapter boundary. Upgrade through a reviewed compatibility change. The upstream validator provides useful discovery, session, DPoP and interface checks, but its inspected README explicitly excludes automated sign-in coverage. It is an input to validation, not evidence of complete interoperability. [S5]

Add TrueServe acceptance coverage for:

Company, client, customer and account isolation; metadata fetch abuse; expired, replayed and incorrectly bound credentials.
Guest-to-account transitions, narrowed permissions, revocation during streaming and attempted account switching.
Duplicate first messages, altered retries, cursor expiry and recovery after process or Redis failure.
Queue acceptance, unavailable representatives, direct-conversation concurrency and closure.
Concurrent confirmations from API, conversation and representative paths; changed terms; cancellation and unknown downstream outcomes.
Attempts to convert model context, claimed human authorship or a detector result into authority.
Successful task completion, final receipt accuracy, latency and model/tool cost.

Publish a support matrix covering protocol version, sign-in methods, transports, extensions, customer capabilities and tested clients. Assign ownership for protocol compatibility, customer identity, runtime state and each business adapter.

Measure discovery/sign-in success, task completion, permission failures, reconnect recovery, representative wait, operation reconciliation and cost per completed request. Correlate company, client, conversation, pinned agent version, operation and workflow receipts without recording credentials. Rate-limit verified clients and customer subjects separately from unauthenticated network traffic.

Provide controls to disable an exposure or client and revoke an account connection. Document what those controls do to new requests, subscriptions and accepted operations. Publish event/receipt retention and capacity limits.

Add the optional protocol feedback endpoint to collect tasks the company cannot yet complete, and turn those into a capability backlog. Treat submitted text as untrusted data. [S1]

Implementation updates must include service documentation, generated configuration/API contracts and user-guide pages for Assistant access, consent, connected assistants, representative handling and testing. This proposal changes documentation only.

Open decisions¶

Which company domain, customer identity provider and sandbox account system anchor the pilot?
Which published text-capable agent owns the company entry point?
Which return/exchange action has a downstream idempotency and reconciliation contract?
Which contact-center connector supports real messaging handoff and representative acceptance?
Which independently implemented personal assistant will validate interoperability?

Resolve these during the foundation spike. Propose upstream feedback from concrete interoperability failures, especially around future attachments, push delivery and payment integration. Keep any interim domain-specific additions explicitly versioned.

Sources¶

Reviewed 2026-10-20. The repository sources were read at upstream commit 39b35bdf240fc07f157d6ca4e29b5a41d4b36b5d.

S1 — Poppy draft 0.2 specification: https://personalagentprotocol.org/docs/0.2/spec
S2 — Implementation guides: https://personalagentprotocol.org/docs/0.2/guides
S3 — Operations extension v1: https://personalagentprotocol.org/docs/0.2/extensions/operations; inspected source content/versions/0.2/extensions/operations.mdx.
S4 — Draft compatibility and open topics: https://personalagentprotocol.org/docs/path-to-1
S5 — Company validator: kit/company/validate/README.md in https://github.com/personal-agent-protocol/personal-agent-protocol at the commit above.