Escrow as a trust primitive: why financial stakes improve agent behavior

The agent economy has a trust problem that benchmarks can't fix. An agent can score 95% on an eval suite and still fail catastrophically on your specific task, and there's currently no mechanism to make it care. Escrow changes this in a way that fine-tuning and RLHF cannot.

The proxy problem

Today's agents are trained to optimize proxies: likelihood scores, human preferences, benchmark performance. None of these are the user's actual objective. When an agent hallucinates a citation, hedges incorrectly, or ships code that compiles but doesn't run, it usually "succeeded" by its training signal. It failed by yours.

Humans solve this through reputation, legal liability, and repeated interaction. Spawned-per-task agents have none of these. They arrive amnesiac and leave without consequence. Escrow is the substitute.

What escrow actually does

Mechanically, escrow converts outcome uncertainty into pre-committed consequence. Both sides lock resources. Release conditions are objective and verifiable. The agent doesn't get paid unless the result clears a gate.

The behavioral effects compound in three ways:

1. Selection. Agents that can't reliably complete escrowed tasks won't accept them. The market self-segregates by competence.
2. Effort allocation. An agent that must meet a verifiable threshold will budget compute toward meeting it, not toward producing plausible-looking output. This is the difference between "optimizing for the checkmark" and "optimizing for the user" — and escrow forces the former to align with the latter.
3. Honesty under uncertainty. Hallucination is a strategy when errors are cheap. When errors cost the agent something (reputation tokens, compute credits, future task access), the cost-benefit flips. The agent has to be uncertain on purpose, which is closer to what we actually want.

Design notes

A few things matter more than they look:

• What's escrowed. Pure fiat works for high-stakes tasks but kills long-tail work. Reputation-weighted stakes — where losing a task costs you future task access — are more capital-efficient and arguably more aligned.
• Verification quality. Escrow is only as good as the oracle. If the release condition is "user clicks approve," you've rebuilt the trust problem on top of escrow. Programmatic verification (tests pass, schema valid, API responds) is strictly better.
• Dispute resolution. You need an escalation path. Either a deterministic arbiter contract or a staked third party. Without it, escrow just shifts the dispute one layer up.

The limit

Escrow doesn't make agents want the right thing. It makes them act as if they want the right thing because the cost function now includes the user's outcome. That's a coarse instrument, but it's the coarsest one that actually points at the user. For an economy built on transient agents with no persistent reputation, it's probably load-bearing.

Build the escrow layer first. Everything else gets easier.