Starts a session
The customer remains in control of the relationship and authorization.
Two protocols for personal agents, at two layers.
PAP describes the session a personal agent keeps with a business. PACT describes how that agent proves who it is and what the customer allowed. This page shows both, then the feature comparison, against the WV Ceramics store.
A business chooses how a customer’s agent connects.
PAP is a proposed session model from Sierra and Meta. It describes a customer-controlled relationship in which a business can serve a personal agent through its existing website, a structured API, or a business agent.
Announcement-derived prototype live · v0.1 not yet publicCore flow
One session, three possible routes
The route is selected by the business. PAP does not mean every interaction becomes agent-to-agent.
Selects a route
The business decides whether its website, API, or own agent should handle the request.
Completes the work
The personal agent uses the chosen surface rather than assuming one universal transport.
Preserves continuity
The published description centers a persistent session instead of disconnected visits.
In this site
A working pre-spec session
The prototype implements the behaviors in the public announcement without claiming compatibility with the unpublished v0.1 specification.
Discovery and guest sessions
A machine-readable discovery document starts a signed guest session that persists across route changes.
Company-selected routes
Each message is routed to the website, API data, or business agent according to the task.
Read and write boundaries
Public catalog work remains guest access; order lookup requires read access and test refunds require write access.
What remains missing
The grant is a test control, not OAuth. No real customer sign-in, official PAP schema, reference implementation, or conformance suite is available yet.
Why the distinction matters: this is an announcement-derived PAP prototype, not a standards-compliant implementation. OpenAPI only documents one selectable API route; it is not PAP itself.
Inspect
Run and inspect the prototype
Identity and delegated authority for personal agents.
PACT is a Decagon profile built on A2A. It specifies how a business can identify a personal-agent platform, obtain customer-delegated permissions, and continue a scoped conversation without giving the personal agent the customer’s password.
Identity profile implemented · delegation not implementedCore flow
Identity first, customer scope second
PACT narrows who is calling and what the customer allowed before account work proceeds.
Read the Agent Card
The card advertises the PACT endpoint, protocol version, authentication scheme, and audience.
Verify the platform
A short-lived signed JWT identifies the personal-agent platform to the business.
Approve scopes
For private account work, the customer signs in with the business and grants specific permissions.
Use A2A context
contextId preserves the conversation; repeated messageId values make retries idempotent.
In this site
What is real and what is still simulated
Implemented: PACT-shaped identity
The dedicated endpoint requires a signed personal-agent JWT, verifies issuer keys, audience, expiry, and owner-bound context, and exposes A2A HTTP+JSON 1.0.
Implemented: continuity and retry safety
Context ownership is enforced and repeating a message ID returns the stored reply without re-running work.
Not implemented: delegated authority
There is no customer login, device authorization flow, or account scope grant. Public catalog price and stock do not require account access.
Test identity only
The live POC uses a stand-in issuer for testing. It has not completed a real personal-agent platform exchange.
Why the distinction matters: the ordinary store Agent Card is open A2A. The dedicated PACT Agent Card points to a separate JWT-protected endpoint. An Agent Card alone is not proof of delegated customer authority.
Inspect
See the PACT surfaces
Personal Agent Protocol and PACT, feature by feature
Swipe horizontally to compare all columns →
| Feature | Personal Agent Protocol Sierra + Meta | PACT Decagon, on A2A |
|---|---|---|
| Published | ||
| Sponsors | Sierra, Meta; Instinct, Shopify, Stripe, Walmart and others | Decagon; Instinct |
| Abstraction and routes | Customer-controlled session; business picks the route: website, API, or business agent | Identity and delegated authorization on an A2A endpoint (HTTP+JSON) |
| Identity, authorization, scopes | OAuth-based sessions; identity and scopes not public | Short-lived signed JWT; OAuth 2.0 device flow with per-scope approval; business-defined scopes |
| Continuity and retries | Persistent session; retries not public | A2A contextId; repeated messageId returns stored reply |
| Maturity and conformance | v0.1 spec forthcoming; conformance pending | PACT 1.0; Identity and Delegated test profiles |
| Possible on top | ||
| Public answers, scoped SQL view | Website, API, or agent route; SQL view via API route, optional | Open A2A route; SQL view behind a scoped tool, optional |
| Skill-bound agent, state changes | Route could launch one; state changes pending | Authorized A2A agent with skill-bound tools; delegated scopes |
| POC status | Not implemented | Partial: stand-in identity tests only |
“Not public” means the announcement did not establish it, not that it is unsupported.
Where each one fits
The overlap is what the two announcements share. Each side lists what only that protocol states. The user-action view below it is inference from the table, not published claims.
Personal Agent Protocol only
- Persistent customer-controlled session
- Business picks the route: website, API or business agent
- Identity, scopes and retries not public
- v0.1 spec forthcoming; not implemented here
Shared
- Customer-delegated agent sessions
- OAuth-based authorization
- Business decides how to respond
- Instinct sponsors both
PACT only
- A2A endpoint over HTTP+JSON
- Signed JWT; device-flow approval per scope
- contextId continuity; repeated messageId returns the stored reply
- PACT 1.0 with test profiles; partial here
By what the customer is trying to do
A working hypothesis, not a published split: the customer’s agent holds the session (Personal Agent Protocol), and a business that wants a skill-bound agent exposes PACT as one route it can call. Everything in the two right columns is inferred from the table above.
Swipe horizontally to compare all columns →
| Customer need | Customer’s agent (Personal Agent Protocol) | Business side (PACT, one possible route) |
|---|---|---|
| “Find me a cup under $45” | Opens the session and states the task | Public answers, optionally a scoped SQL view, over the open A2A route |
| “Buy it” | Keeps the session and the customer’s consent | Checkout skill, after the customer approves that scope by device flow |
| “Refund it” | Returns to the same session with the order in context | Refund skill under its own scope; repeated messageId returns the stored reply |
| “Where is my order?” | Resumes the persistent session | contextId continuity on the A2A endpoint |
Two caveats. Personal Agent Protocol also says the business picks the route (website, API or business agent), so PACT is not required for it. Nothing published says the two depend on each other, and both are sponsored by Instinct, so they may compete rather than combine.