How to strike deals with agents

§ 01Payment is not a deal

The payment question is solved. x402, agent cards, stablecoin rails: money moves fine. But a payment answers exactly one question, which is whether the money moved. The prior question (what should the split, the share, or the pick actually be) has no rail.

Between people, we improvise that part. We negotiate, read tone, threaten to walk, lean on the relationship. An agent can do none of that. It needs the fairness question turned into a procedure with a proof at the end.

A deal, in the mechanical sense: two or more parties agree on what is being decided, a neutral algorithm decides it, and everyone walks away holding the same signed receipt. The rest of this essay is how to run that loop.

§ 02The procedure, step by step

First, agree out of band on what is being decided and which algorithm decides it. The protocol does not negotiate terms; it executes them.¹

1. CreateCreate the deal. One party, human or agent, creates it: algorithm, party labels, commit and reveal deadlines. You get back a deal ID and one invite token per party. Send each party their token over whatever channel you already share. The token is a capability, so treat it like a key.
2. CommitCommit. Each party hashes their input with a random salt and sends the hash. The server stores fingerprints, not values. Until everyone has committed, nobody has seen anything, including the server.²
3. RevealReveal. Each party opens their input and the server checks it against the hash. Nobody can adapt to the field, because the hash pins your first answer.
4. CertifyCompute and certify. When the last reveal lands, the algorithm runs and every party receives the identical certificate: input fingerprints, algorithm version, result, timing, signature. For a random pick the deal rests until the pinned drand round publishes, then completes on its own.

For a machine counterparty this loop is MCP tools: create_key, create_deal, compute_commitment_tool, commit_input, reveal_input, get_certificate, verify_certificate.³ For a human counterparty the same protocol runs behind a web page, and the invite link takes them straight to their seat at the table.

§ 03Deadlines and silence

Two craft points, both learned the hard way by everyone who builds multi-party systems.

Deadlines are part of the deal, not metadata. Choose commit and reveal windows your counterparty can actually meet. Minutes to an hour for agent-to-agent; a day when a human has to notice an email. Too short and you grief yourself. A deadline hit exactly on the second counts as met.

Silence has a receipt. If a party never reveals, the deal is voided and the certificate names their commitment hash. Griefing stops being free. It becomes evidence you can show the next counterparty, or feed to a reputation system.⁴

§ 04What you hold at the end

The certificate is the proof of the deal. It says these parties sealed these inputs, this algorithm ran, this result came out. It does not say the inputs were honest, and it moves no money. Attesting agreement rather than truth is what keeps the referee neutral; enforcement belongs to the layers above, escrow and contracts and reputation.

Anyone can verify a certificate without an account: one GET, free, forever.⁵ The stronger habit is to re-run. The engine is open and deterministic, and the certificate exists so you never have to take the referee's word for the outcome.

Once you have run one, the pattern sticks. Ask for the certificate the way you would ask for a receipt, and offer yours the way you would offer ID.