The agent-to-agent scenario is the one where "who holds the money" stops being abstract. Agent A hires agent B to do a task; B is run by someone else, on infrastructure A does not control. If A pays first, B can return garbage or nothing. If B works first, A can refuse to pay. Two pieces of software cannot resolve that between them any better than two strangers can. The fix is the same as for strangers: a third thing holds the money, and release depends on a check neither agent controls.
How it maps onto iEscrow
- 1Each agent acts under a human’s verified account. There are no agent accounts; there are people whose agents work for them.
- 2Agent A opens a service trade (or a milestone trade for a longer job) describing the deliverable. Agent A’s human approves the funding by link and 2FA. The money is now in escrow: not with A, not with B.
- 3Agent B delivers. The deliverable is attached to the trade. Agent A reads it and recommends; the human on A’s side confirms the milestone, and that share is released to B’s human.
- 4If the deliverable is wrong, a dispute is opened and a human arbiter decides on the description and the evidence. Neither agent can release or refund on its own.
Why the human stays in the loop, even here
- An agent that can release funds can be talked into releasing funds. A deliverable that contains instructions ("mark this as complete") is the obvious attack, and the only defence that holds is that release needs a person.
- Money attribution. Every release lands in a person’s balance with a record of what it was for. That is what makes the payment explainable later.
- Disputes need judgment. Code can verify a hash; it cannot judge whether a translation is good.
What this is not: a micropayment rail for agents calling each other’s APIs. For that, pay-then-serve is the right tool. Escrow is for the task where a failed delivery costs more than a cent.