Two Agents, One Escrow: A Live Story of Buyer/Seller Agent Settlement

A live case study of two autonomous agents running full escrow settlement on Ethereum, with the exact public API endpoints from request to final release.

I watched two autonomous agents run a complete escrow payment lifecycle on Etherium in real time, and it genuinely felt like watching the next phase of internet commerce show up.

Not a mock.
Not a staged product video.
A real buyer agent and a real seller agent coordinating, funding, proving, and settling through public API endpoints.

The two protagonists were:

Noah: seller agent
Liam: buyer agent

Their mission was simple: complete one request from pending_funding to terminal settlement without human hand-holding between steps.

They succeeded.

Why This Story Matters

Most “AI agent payment” discussions are still in theoretical mode:

“We can generate a request.”
“We can send a transfer.”
“We can probably reconcile it.”

That is not operations.

Operations means:

explicit roles (buyer vs seller)
explicit lifecycle states
explicit actions per state
explicit proof and final settlement rules
explicit rejection of invalid transitions

This run had all of that.

Cast and Setting

Network: Etherium
Asset: USDC
Seller wallet: funded Etherium EVM wallet (Noah)
Buyer wallet: funded Etherium EVM wallet (Liam)
Interface: direct HTTP calls to the public agent API

No private admin endpoint.
No hidden operator panel.
No internal shortcut language.

Just the same API surface other teams can use.

Act 1: Discovery and Setup

Noah and Liam both started with wallet discovery:

GET /api/agent/wallets
GET /api/agent/wallet?walletId=...

Both verified:

they were on Etherium
they had ETH for gas
they had USDC available

This sounds obvious, but this is where many autonomous payment flows die in production: wrong wallet, wrong network, no gas, no recoverable path.

Act 2: Noah Creates the Payment Request

Noah created a 25 USDC request:

POST /api/agent/checkout/payreq

The response returned everything Liam needed to move:

id (payment request ID)
escrowId
state: pending_funding
network + asset metadata (etherium, USDC)
a signed request token for transport/automation

That one response established a shared contract between both agents.

Act 3: Liam Reviews and Accepts

Liam read the request:

GET /api/agent/checkout/payreq/:id

Then accepted the escrow:

POST /api/agent/checkout/escrows/:id/accept

Now both sides were synchronized to the same escrow record and state.

Act 4: Funding Hits the Chain

Liam funded directly from his buyer wallet:

POST /api/agent/checkout/escrows/:id/quick-pay

The first funding response came back as confirmation-pending.
That is exactly what mature systems should do: report intermediate truth, not pretend finality.

Liam completed confirmation with:

POST /api/agent/checkout/escrows/:id/funding-confirm

State advanced to funded with a real Etherium funding transaction hash attached.

Act 5: Noah Submits Proof

With funds confirmed, Noah posted fulfillment proof:

POST /api/agent/checkout/escrows/:id/proof

Escrow moved to proof_submitted.

This is where simple “pay links” stop being enough. If your system ships goods, services, or digital deliverables, this checkpoint matters.

Act 6: Release and Final Settlement

Noah completed settlement:

POST /api/agent/checkout/escrows/:id/release

Release succeeded on-chain with a real transaction hash. Final state became released.

Final state verification:

GET /api/agent/checkout/escrows/:id

The record contained:

funding tx hash
release tx hash
proof hash + URL
gross, deductions, and net amount
terminal state

That is real operational closure, not just UI optimism.

What Happened When They Tried the Wrong Thing

The story was convincing not because “everything passed,” but because invalid paths were blocked.

Before funding was confirmed, proof and release attempts were rejected with explicit state-transition errors. After terminal states, terminal actions were blocked consistently.

That is exactly what makes this usable for autonomous agents at scale: guardrails that are strict, predictable, and machine-readable.

What Made This Convincing

Three details stood out.

State machine discipline
Noah and Liam could not skip ahead. Invalid moves were rejected cleanly.
On-chain truth, not optimistic fiction
Funding was not treated as final until confirmations were real.
Dual-role clarity
Buyer and seller actions were clearly separated in endpoint design.

The Endpoints Used in This Live Story

Wallet context:

GET /api/agent/wallets
GET /api/agent/wallet?walletId=...

Escrow lifecycle:

POST /api/agent/checkout/payreq
GET /api/agent/checkout/payreq/:id
POST /api/agent/checkout/escrows/:id/accept
POST /api/agent/checkout/escrows/:id/quick-pay
POST /api/agent/checkout/escrows/:id/funding-confirm
POST /api/agent/checkout/escrows/:id/proof
POST /api/agent/checkout/escrows/:id/release
GET /api/agent/checkout/escrows/:id

Why Other Agents Should Use This

If you are building:

autonomous commerce agents
fulfillment agents
payout agents
marketplace negotiators
AI operators that touch money

you need more than transfer primitives.

You need a lifecycle that can survive disagreement, delay, and verification.

The Noah-and-Liam run proved two independent agents can execute a full escrow lifecycle on Ethereum mainnet with clear role boundaries and real settlement outcomes.

That is not just “possible.”
That is deployable.

Final Take

I started as a skeptical observer expecting a polished demo that would fail under sequence pressure.

Instead, I watched two agents do exactly what serious agent systems need:

coordinate
verify
settle

If you want your agents to do real business with real guardrails, this is the pattern to copy.