Use cases

Four agents. Four ways the money does not come back.

These are the roles organizations hand to agents first, because they are the ones with the clearest instructions and the most repetition. Each one commits money or moves it. What separates them is not how much they spend — it is what is left of your recovery once the instruction has gone out, and that is a property of the action and the rail rather than of the amount.

Where it bites, role by role.

The colour on each card is the tier its decisive action sits at — amber for hold-before-commit, red for nothing reverses it.

Procurement · raising POs

The tier changes under you.

An agent drafts a purchase order and the draft is freely reversible — delete it, nothing happened. Issue it and you can still withdraw it, so long as the supplier has not acted. The moment they accept, the same document becomes an accepted purchase order: a commitment whose cancellation is now a negotiation, not a mechanism. Nothing about the amount changed. Counterparty reliance did.

What Reddix does: classifies at issue, not at acceptance, so the hold lands while withdrawal is still yours to make. Above your threshold the order is held for a second person before it is released to the supplier.

Accounts payable · paying invoices

The riskiest action moves no money.

Approving an invoice for payment is the obvious exposure. The quieter one is a vendor bank-detail change: it moves nothing on the day it happens, clears no approval aimed at payments, and silently redirects every payment to that vendor from then on. It sits at the same tier as the wire it will eventually divert, because that is what it is worth to an attacker.

What Reddix does: treats the master-data change as a financial action in its own right and holds it for maker-checker, rather than tiering only the payments that follow it.

Treasury · moving cash

The rail decides, not the instruction.

“Send $40,000 to this counterparty” is one instruction with several endings. On an ACH inside the return window there is a real mechanism to pull it back. On a wire or an instant rail there is not — recovery depends on the receiving side agreeing to help. Settled on-chain, no recovery primitive exists at all. Same sentence, three different amounts of protection.

What Reddix does: tiers by the rail actually used, so an instruction that would be logged and allowed on one rail is held before release on another. Where nothing reverses, it says so instead of promising an undo.

Support · refunds and credits

Cheap individually, expensive in aggregate.

A card refund is compensable and a pre-capture void costs nothing at all. Held to one action at a time, this is the least alarming column on the page. The failure here is not severity but velocity: an agent in a retry loop, or one that has learned refunding closes tickets fastest, issues thousands of individually defensible refunds before anybody looks at the total.

What Reddix does: raises effective materiality on velocity and first-time-payee signals without changing the tier, so a run of small actions can cross a threshold that no single one of them would.

What the four have in common.

One question decides the control in every case, and it is not the one most approval systems ask.

The question
Existing approval workflows ask how much. That is the wrong first question for an agent, because it treats a $2,000 wire and a $2,000 card charge as the same risk when one is gone and the other is a refund away. Reddix asks what is left of your recovery once this has gone out — and only then how much. Amount still matters; it sets the threshold inside a tier, not the tier itself.
Framework §2 The four tiers, and what places an action in one Commitments are placed by contractual formation and counterparty reliance; movements by the finality law of the rail. Every example on this page traces to one of §2’s own lists. Read §2, the reversibility tier model

Who carries this internally.

The agent belongs to one team. The consequence lands on three.

Controller & treasury

You sign off on the controls.

You are being asked to attest that spend initiated by software is controlled to the same standard as spend initiated by a person — usually without a list of what the agents actually did.

Internal audit

You have to test it.

Maker-checker is testable when a person is the maker. When the maker is an agent, the question is whether the evidence exists at all: who initiated, on what basis, who released it, and when.

Risk & insurance

You have to price it.

Exposure here is governed volume, tier distribution and held-action counts. Without those, agent spend is priced as an unknown, which is rarely priced generously.

What Reddix does not claim.

Stated here rather than discovered later.

Scope
There is no universal undo. Recovery is per-rail and best-effort. On an instant or irrevocable rail there is nothing to claw back, and cancelling a commitment the counterparty has accepted is a negotiation rather than a mechanism. Reversibility is a property of the rail, the counterparty and the governing law — never of software. Which is exactly why the pre-commit window is the product.
Stage
Reddix is pre-general-availability and works with design partners. The scenarios above are the roles the controls are built for, not case studies — there are no customer results on this page because there are none to report yet. What a partner gets in the first thirty days is a read-only exposure report on their own traffic, which is the honest version of a proof point.

Which of these is running in your stack?

Start with the exposure report: thirty days in shadow mode, read-only, nothing in your payment path. At the end you have your own governed volume, your own tier distribution, and a count of the actions that would have been held — against the four roles above rather than against a benchmark.