Money moves need an explicit decision, not a tool call

Finance teams already know that preparing a payment and releasing it are different acts. The clerk who matches an invoice to a purchase order is not the person who presses the button, and the bank portal enforces that split whatever anyone writes in an email. Agents make it tempting to collapse the two, because the same run that found the invoice could, technically, also call the payment API. This note is about keeping them apart, and about what the person who releases the money should see when the agent hands over its work.

Two jobs that look like one

Most of the useful agent work around money is research. Checking an invoice against the order and the delivery note. Comparing supplier quotes against the specification. Confirming that a renewal price matches the contract. Finding the subscriptions nobody has logged into for a quarter. Drafting the week's payment run with each line justified.

All of that is reading, comparing and writing up. It can be wrong, and a person should check it, but a mistake costs a correction. Committing money is a different kind of act: once a transfer settles, getting it back depends on the goodwill of the recipient and the speed of your bank. The research can run freely inside a scope; the commitment should never happen as a side effect of the research.

A useful test: if you deleted every output of the run, would anything in the world have changed? For research, the answer should be no. The moment the answer becomes yes, you have left research and entered commitment, and a person needs to decide.

Why a tool call is never the authority

When an agent produces a call such as create_transfer(payee, account, amount), it is producing text. That text was shaped by everything the agent read on the way, including material you do not control: a PDF invoice, a supplier's email, a web page. The familiar fraud where an invoice arrives with “updated bank details” works on people; it works at least as well on a system that reads the invoice and fills in the fields.

So a well-formed call proves nothing about whether the transfer should happen. Neither does the fact that the agent holds a credential for the payment system, or that a payment tool is connected to the workspace. Holding a key is not the same as being allowed to use it unattended, and a connected tool is not an instruction to use it. Authority comes from a person with the right role looking at the specific instruction and saying yes. In GoCux, a call the agent generated never counts as permission to move money, whatever the call contains.

Keep the rails separate

A second source of confusion is billing. Agent work usually runs against some form of credit or usage budget, and it is easy to assume the same mechanism could pay for things the agent buys. Keep those apart. The budget that pays for the agent's own work is not a payment rail for outside purchases; GoCux billing, for one, is not. Purchases and transfers belong in the systems your finance team already controls, with their own limits, dual control and reconciliation.

In practice the agent's deliverable is a prepared instruction, not an executed one: a payment file, a purchase request, a line in the approval queue of your payment system. The agent does the slow part, the gathering and checking. The rail you already trust does the moving, once a person releases it. The agentic payments guide describes how GoCux treats this boundary.

What the approver should see

An approval request for money has to stand on its own. The approver should not need to open three systems to understand it. A workable request shows:

1. The instruction exactly as it would execute. Payee name, account identifier, amount, currency, reference and date, quoted as the call would send them, not paraphrased.
2. Where each value came from. The invoice passage that gives the amount, the contract clause that sets the price, the supplier record that holds the account, each with a pointer the approver can open.
3. What is different from last time. A new payee, changed bank details, an amount outside the usual range for this supplier. These are the fields fraud hides in, so the request should flag them rather than leave them for the approver to spot.
4. The work it belongs to. The work order, its goal and the person who started it.
5. What a decision does. Approve releases this one instruction. Reject closes it and is recorded. Changing the amount or the payee creates a new instruction, not a tweak to an approved one.

Payment for approval
Payee:      [supplier name]
Account:    as on supplier record, unchanged since last payment
Amount:     invoice total, matches PO line 3
Reference:  invoice number from page 1
Flags:      none / NEW BANK DETAILS / amount above usual range
Evidence:   invoice p.1, PO line 3, delivery note
Decision:   approve this instruction | reject

One instruction, checked again when it runs

An approval should cover the single attempt it was granted for. If the agent retries after a timeout, the retry must not turn one approved payment into two; the payment system should recognise the repeat and refuse it. If the amount, account or payee changes between approval and execution, the action is no longer the one that was approved, and it needs a new decision. GoCux checks a decision again at the moment the action runs for exactly this reason: the world can change between the click and the call.

The same logic rules out standing approvals such as “approve all payments to this supplier this month”. They feel efficient, and they remove the one moment where a changed bank detail would have been noticed. If volume makes per-instruction approval painful, group the instructions into one reviewable run, not into one blanket permission.

Who should decide

The person who asked the agent to prepare a payment run is a natural reviewer of whether the research is right. Releasing money may need someone else, the same way your finance process already separates requesting from approving. Write the rule down so that the agent never has to guess who to ask, and so that a decision taken in one company never carries over to another. Who may approve agent work covers how to set those roles, and why an agent should ask before it acts covers the gate itself.

Before an agent gets near money

• The agent's job is written as research or preparation, with the deliverable named: a checked payment file, a justified purchase request.
• No credential the agent can reach lets it execute a transfer unattended.
• Payments run through your existing payment system and its controls, not through the agent's budget.
• Every approval request quotes the exact instruction, its sources and any changed fields.
• One approval covers one instruction; retries cannot duplicate it; changed values need a new decision.
• Decisions and rejections stay on the work's record. What an agent audit trail should record lists what belongs there.

Spend on the agent's own work deserves its own limits too; put a ceiling on agent spend covers that side.