Maya 2030 on A2A — Integration Overview

Status: Draft v1 — 2026-05-18 Audience: Engineers building agents that interoperate with Maya.

TL;DR

Maya 2030 speaks A2A v1.0 (a2a-protocol.org) on the wire, plus two extensions:

Implement both on an A2A v1.0 agent and it interoperates with Maya users. There is no other Maya-specific surface.

Why A2A as the wire layer

A2A v1.0 is Linux-Foundation-governed with 150+ org adoption (Google, Microsoft, AWS, Salesforce, SAP, ServiceNow, Workday, IBM). It already specifies:

None of that is worth re-implementing. Maya's contribution is two extension URIs: one for authorization (UCAN), one for audit (substrate receipts).

The composition

                              ┌──────────────────────────────────────┐
                              │  A2A v1.0 wire layer                 │
                              │  (JSON-RPC 2.0 over HTTPS, Agent     │
                              │   Card discovery, Task lifecycle,    │
                              │   streaming, push notifications)     │
                              └────────────┬─────────────────────────┘
                                           │
                          ┌────────────────┴────────────────┐
                          ▼                                 ▼
            ┌──────────────────────────┐       ┌──────────────────────────┐
            │ maya-ucan-v1             │       │ maya-substrate-receipts  │
            │ (Maya extension)         │       │ -v1 (Maya extension)     │
            │                          │       │                          │
            │ • SecurityScheme type    │       │ • Receipt envelope on    │
            │   "UcanSecurityScheme"   │       │   every COMPLETED task   │
            │ • Authorization: UCAN    │       │ • Trust-root + inclusion │
            │   <chain> header         │       │   proof URLs in Card     │
            │ • Offline chain verify   │       │ • Optional Bitcoin/OTS   │
            │ • AUTH_REQUIRED re-auth  │       │   anchor lifecycle       │
            │   for scope escalation   │       │                          │
            └──────────────────────────┘       └──────────────────────────┘
                          ▲                                 ▲
                          │                                 │
                ┌─────────┴─────────┐             ┌─────────┴─────────┐
                │ user → Maya →     │             │ Maya substrate    │
                │ service-agent     │             │ + OTS + Bitcoin   │
                │ UCAN chain        │             │                   │
                └───────────────────┘             └───────────────────┘

Each extension is independently useful. A service agent can adopt UCAN auth without receipts, or emit receipts under a different auth scheme. Both together give the user durable, externally-verifiable proof that an authorized action was performed.

End-to-end flow

"Maya reorders dog food from Amazon":

  1. Discovery (Maya runtime → Amazon)

    • The runtime fetches amazon.com/.well-known/agent-card.json per A2A convention.
    • Card advertises extensions: ["…/ucan/v1", "…/substrate-receipts/v1"] and a commerce.purchase skill.

  2. Authorization (user → Maya, one-time)

    • User signs a root UCAN: iss: did:deos:alice, aud: did:deos:alice.maya, att: [commerce.purchase ≤ $200 at amazon.com], exp: 2027-01-01.
    • Stored in ~/.maya/ucans/.

  3. Sub-delegation (Maya → Amazon, per request)

    • Runtime mints a leaf UCAN: iss: did:deos:alice.maya, aud: did:web:amazon.com, att: [commerce.purchase ≤ $87.99 dog-food-sku at amazon.com], nbf: now, exp: now+5min, prf: [root_ucan_cid].
    • Chain (leaf + proof) rides in the Authorization: UCAN <chain> header on the A2A SendMessage call.

  4. Action (Amazon)

    • Amazon's A2A agent verifies the chain offline per maya-ucan-v1.
    • Places the order.
    • Mints a substrate receipt: {action_can: "commerce.purchase", metadata: {sku, amount, …}, ucan_chain_cids: […]}. Ed25519-signed, MMR-appended.
    • Returns A2A response with task COMPLETED and the receipt in extensions[…/substrate-receipts/v1#receipt].

  5. Verification (Maya runtime)

    • Verifies receipt signature against Amazon's substrate trust-root.
    • Re-verifies inclusion proof against log_root.
    • Re-anchors the receipt in Maya's own substrate (cross-witnessing).
    • Surfaces in iOS chronicle as 🟢.

  6. Bitcoin confirmation (~1 hour, async)

    • Amazon's substrate batches its current root and submits to OTS.
    • OTS commits to Bitcoin.
    • Receipt's anchor.status transitions pending → confirmed.
    • iOS badge upgrades from "Signed" to "Bitcoin-Confirmed."

  7. Dispute (months later)

    • User pulls the receipt from their local substrate.
    • Verifier walks: UCAN chain → Maya signature → Amazon substrate signature → MMR inclusion → Bitcoin block N at time T.
    • No party in this verification has to be online or trusted.

What you build vs adopt

If you're building... A2A Maya extensions Maya-specific
A service that wants Maya users Adopt v1.0 as-is Implement both extensions none — you're done
A Maya-compatible personal agent Adopt v1.0 as-is Implement both extensions (client + server) DEOS-style trust substrate (or use the Maya reference one)
A federated indexer Adopt v1.0 as-is Optional (you can sign listings via UCAN if you want) Index format — see discovery/indexer/v1
A wallet / UCAN issuer n/a (out-of-band) Familiarize Maya wallet UI conventions (TBD)

Streaming (message/stream)

A2A v1.0 §3.1 defines message/stream for tasks where incremental output matters — chiefly LLM drafting.

Agent Card advertises both endpoints:

{
  "service_endpoint": "/a2a/messages",
  "streaming_endpoint": "/a2a/messages/stream",
  "capabilities": { "streaming": true, ... }
}

The streaming endpoint takes the same JSON-RPC envelope but only message/stream. Response is Content-Type: text/event-stream:

Event Data shape Meaning
status TaskStatus JSON object Status transition (typically WORKING on open)
delta {"text": "<partial>"} Token-level partial output (LLM streaming)
task full Task JSON Terminal — completed Task with substrate receipt envelope in artifacts[].extensions
error {"message": "..."} Terminal — abnormal exit, no receipt

15-second : ping comments keep transparent proxies from half-closing the stream.

Streaming is per-action. comms.personal/draft.reply emits real delta events per LLM token. Other action_cans complete promptly and arrive as a single task event, so a client can drive every action through the streaming endpoint without fan-out.

Client: @deos/receipt/a2a exposes A2AClient.sendMessageStream(params) returning AsyncIterable<StreamEvent>. Iterate until task or error.

What's not in these specs

Reference implementation status

Versioning + governance