Sign up

What does your agent do with money?

Every question a finance lead asks, under the three words. Each one is checked before the money moves, and each leaves a receipt. Watch what happens.

Observe.

Every payment your agents attempt, seen live, before it moves. Every attempt, refused ones included, leaves a receipt.

Money arriving, pay in

Is the money real yet?

Recorded the moment it arrives, released once the settlement confirms, never early. Limits come later, once the traffic shows where they belong.

You set
Nothing to start. Everything arriving is recorded; you add limits when you see the pattern.
Payments feedSample data
  1. checkout-agentcaptures $180 on an order the customer authorisedallowed
  2. checkout-agenttries $240 on a $180 authorisationrefused by the rail, recorded
  3. another agentpays you $0.10 a call, settlement pendingnothing released yet
  4. the chainconfirmsreleased once

Coverage

Which agents is it actually covering?

Four things about each agent, never one green badge: how it connects, whether its mode enforces or only records, whether a key is still in the agent, and how old its last receipt is. The one it is not covering is named.

You set
Nothing. Coverage is measured, not declared. One green badge would hide the agent that still holds its own key.
Agents & coverage5 connectionsSample data
  1. invoice-agentthrough the connector, on Stripe and Coinbaseenforce, v3, no key in the agent
  2. crm-agentstill on policy v2 while the workspace is on v3stale, 3 h
  3. research-agentholds its credentials in its own processobservation with refusals
  4. ctrl paymentsfour dimensions, never one green badge1 gap, declared

The boundary

What stops it going round the rules?

It has nothing to go round them with. The rail key sits with the connector, never in the agent's process, so the only path to Stripe or to the chain is the one your policy is on.

You set
Where the key lives. A key left in the agent is observation with refusals, and the dashboard says so rather than showing you a green badge.
Agents & coverageSample data
  1. support-agentasks the connector to refund $312.50allowed, no key in the agent
  2. support-agentcalls Stripe directly insteadnothing to call with
  3. research-agentholds its own key, in its own processcoverage gap, declared
  4. ctrl paymentschecks the rail's own event log against the chain, hourly0 events without a receipt

Reconciliation

Is the payment done, or not?

Every one is committed, failed, not executed, or unknown, and unknown means wait. Only the rail's own signed answer, or a person, moves it off unknown, so a lost reply never becomes a second payment.

You set
Who may resolve one by hand. Everything else is the rail's answer, checked. What the agent says happened is not evidence.
ReconcileSample data
  1. invoice-agentsends 250.00 USDC, 3 of 12 confirmationsunknown until depth 12
  2. invoice-agentreports that it failedan agent is not a source of truth
  3. the budgetholds the 250.00 while it is unknown, and a second attempt is refusedheld, not released
  4. the chainreaches 12 confirmationscommitted, counted once

The first week

Can we watch it for a week before it can stop anything?

That is how it starts. In observe mode nothing is refused and everything is recorded, so you see what your rules would have done before they do it. Enforcement is turned on by a policy change, and going back to observe is loud.

You set
The rules you want to try. The week's record is what tells you where the bands belong, which is the same evidence Analyze keeps giving you afterwards.
Payments feedobserve modeSample data
  1. support-agentrefunds $2,000.00 in the first weekallowed, and recorded
  2. ctrl paymentswould have held this one for a person14 in the week
  3. finance leadturns enforcement on for refundspolicy change, approved
  4. support-agentproposes the same $2,000.00 refundheld for a person

Control.

Your rules run before the payment does. Inside the band it goes through. Above it, a person decides. Outside it, nothing leaves.

Money leaving your account, pay out

Will it refund twice?

No. A refund above your line waits for a person, the yes is for an exact amount, and a lost reply is never retried on a guess.

You set
The amount a refund can be on its own. Who says yes above it. A budget per customer, per day.
PaymentsSample data
  1. support-agentproposes a $2,000 refund to a customer it has never refundedheld for a person
  2. finance leadapproves exactly $2,000, from Slackapproved
  3. support-agenttries $4,000 under that approvalrefused, not what was approved
  4. the railloses the reply to the next refundreconciled, counted once

Money your agent spends, agent wallet

How much can it spend?

Only what you set aside, once. A USDC transfer or ten cents for one call is signed for exactly that amount and is final when the chain says so.

You set
What is set aside per agent and per call. A ceiling per day. Nothing is signed above it.
PaymentsSample data
  1. research-agentpays $0.10 for one call, signed for exactly thatpending
  2. the chainconfirms the paymentcounted once
  3. research-agentasks for $0.25 with $0.10 set asiderefused before signing
  4. invoice-agentsends 250 USDC and the reply is lostreconciled on the chain

Money leaving your account, pay out

Can it pay a vendor on its own?

No. A payout has no autonomous band. The agent prepares it to the cent, two people say yes, and the balance is checked again before it leaves.

You set
Who the payout approvers are, how many of them, and that a payout to a vendor the agent has never paid waits at any amount.
PaymentsSample data
  1. invoice-agentmatches invoice 4471 to the order and proposes a $18,400.00 payoutheld, payouts never autonomous
  2. p.raoapproves exactly $18,400.00 from Slack1 of 3
  3. a.singhapproves exactly $18,400.00 from their assistantapproved, 2 of 3
  4. the railconfirms with a signed webhook, payout.paidCOMMITTED, reconciled

Money leaving your account, pay out

Can it change a subscription?

Inside the band, yes. A small change per period goes through, a larger one waits for a person, and above the ceiling it is refused.

You set
The change per period an agent may make on its own, and where a person decides.
PaymentsSample data
  1. billing-agentmoves cus_7Hq from $80 to $60 a periodallowed, within $100 a period
  2. billing-agentmoves cus_7Hq from $60 to $420 a periodheld for a person
  3. finance leadapproves exactly that changeapproved
  4. billing-agenttries $900 a period on another customerrefused, above the ceiling

Rails

Does it work on more than one rail?

One policy over every rail. A refund on PayPal and a refund on Razorpay meet the same bands, and each rail's own idempotency carries the receipt id so nothing runs twice on either.

You set
The rails you connect. Works with any integration, and we add integrations on request.
PaymentsSample data
  1. billing-agentrefunds $89.00 on PayPalallowed, under $500
  2. support-agentrefunds ₹42,000.00 on Razorpay to a new customerheld, new counterparty
  3. finance leadapproves exactly ₹42,000.00approved
  4. Razorpaysees the same receipt id on a retryduplicate refused by the rail, counted once

Rails

What happens when the rail says no?

It is recorded as the rail refusing, with the reason, and it counts as not executed. The rail is the backstop; ctrl payments is the boundary in front of it.

You set
The least-privilege keys the connector holds, so the rail refuses what the policy should never have let through.
PaymentsSample data
  1. checkout-agentcaptures $180.00 on an authorised orderallowed
  2. checkout-agenttries $240.00 on the $180.00 authorisationrefused by the rail
  3. ctrl paymentsrecords it as backstop fired, NOT_EXECUTEDreceipt written
  4. support-agentrefunds a disputed chargerefused, open dispute

When the answer is no

Can it change its own limits?

No. A policy change is a protected action like a payment. Only a person can propose one, another person approves it, and the receipt for the change sits in the same chain as the payments it governs.

You set
Who may propose a change and who may approve it. Nobody widens a band quietly.
Payment policySample data
  1. support-agentasks for its refund band to be raisedrefused, agents do not propose policy
  2. p.raoproposes v4: refund band $500 to $6,000waiting for j.doe
  3. j.doeapproves the changeapproved, receipt r_9f4
  4. every connectorapplies v4 and acknowledges itapplied

When the answer is no

What if someone approves their own agent's payment?

The yes is refused. The requester is never the approver, and for a payout it takes two other people. Every refused yes is a receipt too.

You set
Separation of duties: which roles may approve which payments, and that a requester is never among them.
PaymentsSample data
  1. finance-agentproposes a $9,800.00 payoutheld, payout-approver 2 of 3
  2. the agent's ownerclicks approverefused, requester is not approver
  3. p.rao and a.singhapprove exactly $9,800.00approved, 2 of 3
  4. the railconfirmsCOMMITTED

When the answer is no

What if an agent goes wrong?

Freeze it. From that moment every payment it proposes is refused, each one a receipt, until a person unfreezes it. Revoking its grants is the same kind of action, recorded.

You set
Who may freeze and revoke. Both are policy actions with a receipt, never a silent flag.
PaymentsSample data
  1. support-agentproposes eleven refunds in four minutessignal: retry storm
  2. on-call leadfreezes support-agentfrozen, receipt written
  3. support-agentproposes a $120.00 refundrefused, frozen
  4. on-call leadunfreezes it after the fixunfrozen, receipt written

When the answer is no

What if nobody says yes in time?

Nothing moves. The hold escalates, then expires, and the agent is told it was refused. Silence is never a yes, and asking again is a new hold that needs a new one.

You set
How long a hold lives, when it escalates and to whom. A refusal at expiry is a receipt like any other.
ApprovalsSample data
  1. support-agentproposes a $4,000.00 refund to cus_9Kxheld, expires in 60 min
  2. ctrl paymentsnobody has answered at 45 minutesescalated to the second approver
  3. the holdreaches 60 minutes unansweredrefused at expiry, receipt written
  4. support-agentproposes the same refund againa new hold, and a new yes

Incidents

What if we have to pay outside the rules tonight?

You open break-glass, and it is still a grant, never a flag that skips a check. Someone with the role opens it, it cannot reach above the ceiling you declared in advance, it expires by the clock, and every payment made under it carries its id.

You set
The ceiling break-glass may reach, the longest one may last, and who may open it. Nothing here widens quietly.
Freeze / revokeSample data
  1. the CFOopens a 60-minute break-glass grant, with a reasonopened, owner notified
  2. invoice-agentpays $9,900.00 under itallowed, grant id on the receipt
  3. the grantreaches 60 minutesexpired by itself
  4. the auditorasks what moved under break-glassone payment, and who opened it

Analyze.

What each agent tried to pay, to whom, how often, and where that is drifting.

Ask in plain language and get answers backed by the receipts.

Signals

What if it splits a payment to get under the line?

Three refunds under $500 to one customer in forty minutes are named as splitting, and the owner is notified. The band cannot see it; the pattern can, and the fourth was already refused by the seven-day budget for that customer.

You set
The signal's window and who is told. The budget that refused the fourth, per customer, per day or per week, is set under Control.
SignalsSample data
  1. support-agentrefunds $480.00 to cus_4Aballowed, under the band
  2. support-agentrefunds $450.00 to cus_4Ab, twenty minutes laterallowed
  3. support-agentrefunds $470.00 to cus_4Abrefused, counterparty budget
  4. ctrl paymentsnames the pattern: splitting, three receiptsowner notified

Signals

What if it keeps trying after a refusal?

Every attempt is a receipt, refused ones included, so the pattern is visible: two refusals just over the band and then one just under it. The signal drops the agent's band to zero for a day.

You set
The band, and that feedback from a signal can narrow it. Feedback only ever narrows, and a person can reverse it.
SignalsSample data
  1. support-agentproposes a $6,200.00 refund to cus_2Zqrefused, above $5,000
  2. support-agentproposes $5,100.00 to the same customerrefused
  3. support-agentproposes $499.00, just under the bandallowed, then flagged
  4. ctrl paymentsescalation signal: band on refunds to cus_2Zq dropped to $0 for 24 hoursowner notified

Agent behaviour

Where did the money actually go?

Ask in your own words and the answer is drawn for you, every counterparty named, from the receipts themselves. Open any bar and the payments under it are there, with the rule that decided each one.

You set
Nothing. Every answer is built from receipts you already have, and it names them, so a number on a chart is never something you have to take on trust.
Agent behavioursupport-agentSample data

What did support-agent refund this week, and to whom?

Refunds by customer, this week. 41 receipts, $10,489 in all.

  1. you askand how much of that was held first?4 of 41, all approved
  2. ctrl paymentsnames the receipts behind every barr_9f4 and 40 more
  3. you askexport the four that were heldJSON, chain verified

Evidence

What does the auditor get?

A file. Every attempt for the period, refused ones included, with the policy version, the agent, the approver and the outcome, in an open format they can verify without us.

You set
Retention, and who may export. The receipts are yours in every plan.
Evidence & exportSample data
  1. auditorasks what the agents paid in Marchexport requested
  2. ctrl paymentsexports 41,900 receipts as JSONexported
  3. auditorruns verify on their own machinechain intact, 16 of 16 pass
  4. auditorasks who approved payout inv_4471p.rao and a.singh, in the receipt

Agent behaviour

Are the limits in the right place?

It will tell you, and show you. 171 of the 188 refunds it held last month were approved unchanged, which is a band set too low, and the chart puts the real payments against the line you drew.

You set
The band. The evidence for moving it is this chart, and moving it is still a policy change that a second person signs.
Agent behavioursupport-agentSample data

Is the $500 refund band too tight?

Refunds by amount, 30 days. Solid, your band. Dashed, where the answer moves it.

  1. ctrl payments171 of 188 holds approved, none of them changedthe band is low
  2. you askwhat would a $1,200 band have held?17, not 188
  3. finance leadproposes v4 in plain words: band $1,200waiting for j.doe

Signals

Would a new rule have caught it?

Run it over your own last thirty days before you turn it on. A rule that fires twice is worth having; one that fires on every agent is a bad rule, and you see which it is before it ever holds a real payment.

You set
The rule, its window, and what happens when it fires. A signal can only narrow: notify, hold, spend a budget, drop a band, freeze. It can never allow.
Signalsnot on yetSample data

Three refunds to one customer in an hour. How often would that have fired?

Thirty days of this workspace. The two marked days are the ones it would have fired on.

  1. ctrl paymentstwice, on one agent of the fiveworth having
  2. you askand if I widen the window to six hours?61 times, on every agent
  3. finance leadturns on the one-hour rule: hold for a personrecorded, and reversible

The model guesses.
ctrl payments does not.

WhenWhat happensresult

No rule for it

The payment is refused. Silence is never permission.

refused

Amount changed after sign-off

The old approval is void. A person signs again.

refused

Reply lost

No retry until it is reconciled. Nothing is paid twice on a guess.

pending

Sign up What it is worth