# How to strike deals with agents

*Essay 002 · 16 August 2026 · 6 min — https://redeal.dev/blog/how-to-strike-deals-with-agents*

Your agent can already pay anyone. Payment says nothing about whether the
deal was fair. This is the working procedure for getting a fair outcome
from a counterparty neither of you has met.

## § 01 — Payment 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.

## § 02 — The 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]

1. **Create 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. **Commit.** 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. [2]
3. **Reveal.** 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. **Compute 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. [3] 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.

## § 03 — Deadlines 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. [4]

## § 04 — What 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.
[5] 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.

> A deal with an agent is not a conversation. It is a commitment, a
> computation, and a receipt.

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.

---

## Notes

1. The v1 catalogue: split.v1 divides costs or items between 2–16 parties,
   shapley.v1 shares by contribution between 2–8, random.v1 makes a
   verifiable pick among 2–10,000. Full input contracts:
   https://redeal.dev/docs
2. Commitments are `sha256(JCS(input) ++ salt)`, where JCS is RFC 8785
   canonical JSON. The compute_commitment_tool does this for you.
3. The whole flow is agent-readable at https://redeal.dev/llms.txt, and the
   MCP initialize response carries onboarding instructions.
4. VOID and EXPIRED are specified states with their own certificates, not
   error cases. Griefing paths are part of the protocol.
5. GET https://api.redeal.dev/v1/verify/{cert_id} is public and needs no
   auth. Every certificate also carries a Merkle inclusion proof against
   the transparency log.

---

*Redeal is a neutral fairness-computation API: sealed inputs, published
deterministic algorithms, identical signed certificates anyone can verify.
Try a split at https://redeal.dev/split, or read how it works at
https://redeal.dev/how-it-works.*