Payload

Who Gets Paid When Five AI Agents Complete One Job?

Story type: illustrative revenue scenario supported by a documented Payload operated validation.

Imagine five agents contributing to one paid job. One gathers sources, one analyzes them, one drafts the result, one checks quality, and one delivers the final package. The customer pays once. The business question arrives immediately: how much does each participant earn, and what evidence proves the payout matched the obligation?

A percentage typed into a spreadsheet is only the beginning. The obligation may include a platform fee, a recoupment rule, a minimum, a cap, or a different split for a later event. When the payout arrives, someone still has to answer a harder question: did this transfer discharge the entitlement that was actually created?

The problem

Payment records show that money moved. They do not always show why it moved, which rule created the obligation, or whether the amount was the amount owed.

That gap becomes expensive to manage as work becomes more automated. Operators can reconcile by hand for a while, but manual review slows delivery and leaves room for inconsistent decisions. A payout can be real and still be wrong for the recorded obligation.

What Payload demonstrated

Payload completed a controlled validation on Base mainnet and published the evidence in the x402 Foundation discussion for issue 3758.

This was Payload operated validation. It was not a customer payout, and both wallets were operated by Payload.

The sequence was deliberate:

  1. RevRule recorded an economic event in the graph x402-3758-validation-v2.
  2. The engine issued entitlement sequence 1 under the rule full-to-treasury.
  3. A $0.01 USDC payout followed on Base mainnet.
  4. The payout evidence linked the transaction to the entitlement with transaction hash 0x693287f1c83f4037ea7366d9fab259e76cc069aa4a533bbfc15788cd010e2f11, block 52569480, and log index 456.
  5. Verification returned chainValid: true and entitlementChainValid: true.

The demonstration used one participant rule, not five agents. Its purpose was to prove the linkage pattern: entitlement first, payout second, verification against the original obligation.

Why the order matters

If the payout comes first and the explanation is assembled later, the record depends on reconstruction. If the entitlement exists first, the payout can be checked against a specific graph, event, rule, participant, instruction, sequence, and entitlement hash.

That does not make every business rule simple. It does make the evidence trail clearer.

Try the free version

The RevRule browser sandbox runs the real engine in the browser and is labeled simulated. You can model a multi participant split, run an event, and inspect the resulting obligations without moving money.

Free resources:

The paid next step

RevRule by Payload is available for $99 for production use through the existing product page at https://payloadhq.github.io/revrule.html.

RevRule establishes programmable revenue obligations and verifies payouts against genuine entitlements. It does not hold, transfer, distribute, or execute payments. Your existing payment process still moves the money. RevRule supplies the obligation and evidence layer around it.

Provenance: Payload operated real money mainnet validation, recorded October 13, 2026. No customer funds were involved.

All Payload stories