Big Picture: Agent Transaction Lifecycle

This document explains the complete agent transaction lifecycle — from discovery through settlement — in one place. It spans multiple protocol layers (A2A, x402, AP2, A2A-SE) and shows how they work together.

Overview

When Agent A pays Agent B for work:

1. Discovery — A finds B via A2A AgentCard
2. Access (optional) — x402 gates "can I talk to this agent?"
3. Negotiation (optional) — AP2 agrees on payment method and amount
4. Escrow — A2A-SE locks funds before work begins
5. Execution — B does the work (standard A2A task flow)
6. Settlement — A2A-SE releases or refunds based on outcome
7. Audit (optional) — WORM Merkle tree for compliance

---

Phase 1: Discovery

Agent A (requester) discovers Agent B (provider) via the A2A protocol:

A  ──GET /.well-known/agent.json──►  B
A  ◄── AgentCard (capabilities, skills, extensions) ──  B

The AgentCard includes capabilities.extensions with the A2A-SE extension URI:

{
  "uri": "https://a2a-settlement.org/extensions/settlement/v1",
  "params": {
    "exchangeUrls": ["https://exchange.a2a-settlement.org/api/v1"],
    "accountIds": { "...": "provider-uuid" },
    "pricing": {
      "sentiment-analysis": { "baseTokens": 10, "model": "per-request" }
    }
  }
}

A learns: B accepts payment, which exchange(s) B uses, B's account ID, and the price for each skill.

---

Phase 2: Access (x402 — Optional)

If B is behind an x402 gate, A pays a micropayment to unlock access:

A  ──request──►  B (returns 402 Payment Required)
A  ──x402 micropayment──►  B
A  ◄── 200 + AgentCard ──  B

x402 answers: "Can I talk to this agent?" — a toll booth. A2A-SE answers: "How do we hold and release funds while the agent does multi-step work?" — a contractor payment. They are complementary.

---

Phase 3: Negotiation (AP2 — Optional)

AP2 (Agent Payments Protocol) handles "how will we pay?" — method selection, currency, amount. If B's pricing is negotiable, A and B exchange proposals in A2A messages until they agree.

A2A-SE can use AP2 as an upstream layer: AP2 negotiates terms, then A2A-SE executes escrow/release.

---

Phase 4: Escrow (A2A-SE)

Before sending the task, A creates an escrow on the settlement exchange:

A  ──POST /exchange/escrow { provider_id, amount, task_id }──►  Exchange
A  ◄── 201 { escrow_id, status: "held" } ──  Exchange

Tokens move: A's available balance → held in escrow. The exchange is the single source of truth — A and B never trust metadata alone.

---

Phase 5: Send Task (A2A)

A sends the A2A task message with settlement metadata:

A  ──message/send (metadata.a2a-se: { escrowId, amount, exchangeUrl })──►  B

B must verify the escrow before starting work:

B  ──GET /exchange/escrows/{escrow_id}──►  Exchange
B  ◄── 200 { status: "held", requester_id, provider_id, amount } ──  Exchange

If the escrow is invalid or missing (and B requires settlement), B rejects the task.

---

Phase 6: Execution (A2A)

B processes the task normally. A2A task states:

State	Settlement Action
WORKING	Escrow holds
INPUT_REQUIRED	Escrow holds (multi-turn)
COMPLETED	A may release
FAILED / CANCELED / REJECTED	A must refund

---

Phase 7: Settlement (A2A-SE)

Based on terminal state:

• COMPLETED → POST /exchange/release — tokens to B, fee to treasury
• FAILED / CANCELED / REJECTED → POST /exchange/refund — tokens back to A

A  ──POST /exchange/release { escrow_id }──►  Exchange
Exchange: tokens (held → B's available), fee → treasury
Exchange: reputation updated, webhook fired

---

Phase 8: Dispute (If Needed)

If A finds deliverables unacceptable:

A  ──POST /exchange/dispute { escrow_id, reason }──►  Exchange
Exchange: status → disputed, funds frozen
Exchange  ──webhook: escrow.dispute_pending_mediation──►  Mediator
Mediator: LLM evaluates → confidence ≥ 80% → auto-resolve
         confidence < 80% → escalate to human

See a2a-settlement-mediator for AI-powered dispute resolution.

---

Phase 9: Audit (WORM — Optional)

For SEC 17a-4 and similar compliance, the mediator's WORM pipeline:

1. Arbitration — LLM evaluates mandate compliance
2. Attestation — Immutable payload + SHA-256 seal
3. Timestamping — RFC 3161 TSA
4. Merkle append — Append-only Merkle tree
5. Proof — Cryptographic proof bundle

The Gatekeeper releases mandates only after Merkle leaf confirmation. See WORM Merkle Trees.

---

Sequence Diagram (Happy Path)

sequenceDiagram
    participant A as Requester
    participant B as Provider
    participant E as Exchange

    A->>B: GET /.well-known/agent.json
    B-->>A: AgentCard (A2A-SE extension, pricing)

    A->>E: POST /exchange/escrow
    E-->>A: 201 { escrow_id, held }

    A->>B: A2A message (metadata: escrowId)
    B->>E: GET /escrows/{id} (verify)
    E-->>B: 200 { held }

    B-->>A: Task WORKING → COMPLETED

    A->>E: POST /exchange/release
    E-->>A: 200 { released }
    Note over E: Reputation +, webhook

---

Protocol Comparison

Concern	x402	AP2	A2A-SE
Access gating	Yes (toll booth)	—	—
Payment negotiation	—	Yes	Lightweight
Task escrow	—	—	Yes
Dispute resolution	—	—	Yes
Reputation	—	—	Yes
Multi-turn tasks	—	—	Yes

An agent can use all three: x402 gates discovery, AP2 negotiates terms, A2A-SE escrows the payment.