Giving an Agent a Billing Tool: Approval Gates

A per-run cap is a number the agent cannot exceed for a single task or work session. It belongs in deterministic code that wraps the billing tool, not in the system prompt, because a prompt is a suggestion and a limit must be a wall.

The mechanics are simple: track cumulative spend for the run, compare any proposed amount against the remaining headroom, and refuse the call locally if it would breach the cap. Do not call the payment API and hope it rejects the charge. The rejection has to happen on your side so the agent receives a clean, structured error it can reason about.

The cap should be set per run and per day. A per-run cap limits the blast radius of one confused agent; a daily cap per account limits the blast radius of one bad afternoon.

Two implementation rules make caps trustworthy. First, reserve before you call: increment the counter, then call, then reconcile on the result. If you increment only after success, two concurrent calls can both pass the check. Second, persist the counter in the same durable store the agent uses for other state, so a restart does not reset it to zero.

A worked example. A support agent runs with a per-run cap of 200 USD and a daily cap of 1,000 USD per account. During one run it proposes refunds of 40, 60, 60 and 75 dollars. After the first three, 160 is spent and 40 remains. The fourth proposal (75) exceeds the remaining 40, so the wrapper returns a denial and the agent must either ask a human to raise the cap or shrink the request. The cap is checked before any call, so no refund was issued for the denied item and no manual reversal is needed.

Human-in-the-loop means the agent proposes an action and pauses, a person reviews the exact change and its evidence, and the agent resumes only if the request is approved (Permit.io on human-in-the-loop for agents). This is deliberate: in finance it is maker-checker applied to AI, where a named person with authority reviews the specific change before it reaches the ledger (Keboola on human-in-the-loop for finance).

The classic failure is rubber-stamping. Approval fatigue turns a gate into a formality. A good gate shows the reviewer one screen with the amount, currency, payee, the customer-facing reason and the data the agent relied on. Approving is one decision about one action. Never bundle approvals.

Route by consequence, not by convenience. A defensible default routing matrix looks like this:

Note the asymmetry: denials are silent blocks, approvals are human actions, and every path writes a record. COSO's guidance on generative AI asks for human corroboration proportionate to risk, and treats an approval that leans solely on AI output as control evidence in its own right (COSO guidance summarized at Keboola). In practice that means the reviewer's screen has to show what the reviewer was shown, not just that a button was clicked.

Choose the mode consciously. The EU High-Level Expert Group distinguishes human in the loop (intervene in every decision cycle), on the loop (shape the design and monitor while it runs) and in command (decide whether the system runs at all) (EU ethics guidelines summarized at Keboola). Reviewing every single refund is usually the wrong choice; reviewing consequential actions, which the same summary describes as the finance norm, is the right one, and writes the routing rules as fixed policy in code so the agent never decides its own gate (Keboola on human-in-the-loop for finance).

Here is the angle you rarely see in the search results: most guides put idempotency on the server. For an agent, key generation and storage belong to the caller, because the agent is the thing that retries.

An idempotent operation is one you can run any number of times while guaranteeing that side effects occur once, which is what lets a caller converge its own state by retrying until it verifiably succeeds (Stripe engineering on idempotency). For a charge, though, exactly-once semantics need help, and that help is the idempotency key (Stripe engineering on idempotency).

The contract has three parts. Before the call, the agent writes a unique key to durable storage. It then sends the key with the request. On any retry, it reuses the same key, and the payment API returns the saved result instead of executing again. After the call, the agent records the outcome against the key.

The key must identify the intent, not the network attempt. Every retry of the same refund uses one key; a genuinely new refund gets a new one (Ali Aftab K. on idempotency design). Payment APIs implement this with a header, conventionally Idempotency-Key, and clients generate a UUID or similar high-entropy value (Zuplo on implementing idempotency keys, Stripe API reference on idempotent requests).

1. AGENT receives intent: refund order O-8817, 60.00 USD
2. AGENT key = stable_id(agent_run_id, order_id, amount, "refund")   # or UUIDv4 created once
3. AGENT INSERT into action_log (key, intent, status="pending")      # atomic; unique constraint on key
   - if insert conflicts and status=succeeded: return saved result
   - if insert conflicts and status=pending:   return 409 in-progress
4. AGENT POST /v1/refunds  Header: Idempotency-Key: <key>  Body: {order, amount}
5. AGENT receives 200 (or cached replay of the original 200)
6. AGENT UPDATE action_log SET status="succeeded", result_id=P-4471 WHERE key=<key>
   - on timeout / 5xx: status stays "pending"; retry with SAME key, not a new one

Three details decide whether this holds under failure. The insert must be atomic, so only one concurrent request wins the race for a given key (Zuplo on implementing idempotency keys). The key must be created before the first request is sent and reused on retries, never regenerated per attempt (Zuplo on implementing idempotency keys). And the agent should only delete its local key once it knows the final outcome; a clear decline is final, but a timeout keeps the key live so the next attempt can return the saved result (Balmik Prajapati on idempotency keys in payment APIs).

Where an external provider sits behind your own API, derive the provider's key from the agent's key and save it before the provider call, so a crash between provider success and your write does not produce a second charge (Balmik Prajapati on idempotency keys in payment APIs). Then keep keys long enough to cover realistic retry windows, commonly 24 hours to 7 days, and not forever, since storing keys too long adds cost (Zuplo on implementing idempotency keys).

A cap that denies and a gate that blocks are only useful if the agent can tell the difference between denied by policy, in progress, succeeded and the network died. If your tool returns a bare string, the agent will guess, and a guessing agent retries with a fresh key.

For API-shaped tools, standardize the error body on Problem Details, the JSON format in RFC 9457 that lets an API carry machine-readable details about what went wrong (RFC 9457). It obsoletes RFC 7807, which carried the same idea in an earlier version (RFC 7807). The format exists because HTTP status codes alone cannot convey enough detail for non-human consumers, which is exactly the situation of an agent hitting a cap (RFC 9457).

A useful body for a billing tool carries a stable problem type URI, the cap value that was hit, the amount that would have been spent, and the remaining headroom, so the agent's next step is determined rather than invented. Falling back to custom error payloads creates the inconsistent handling that complicates every integration, and the new wave of machine consumers makes that inconsistency more expensive (Swagger on RFC 9457). If you build this in a framework that already supports the standard, use it rather than hand-rolling a schema; the Spring Framework, for example, lets a controller return a problem detail object directly (Spring Framework error responses).

Design test for the whole system: drop the network mid-call and see what the agent does on resume. It should read its action log, find a pending key, and retry with that same key. If a fresh key appears in the logs, your idempotency is decorative.

Build the stack in this order, and test each piece before adding the next.

1. Durable action log with a unique constraint on the idempotency key, containing intent, amount, status and result ID.
2. A billing wrapper that reserves against a per-run counter before calling, then reconciles on the outcome.
3. Per-run and daily caps, stored in the same database, with the counter reset by an explicit operator action, never on restart.
4. A routing matrix implemented as fixed rules: auto-approve, approve, deny, escalate.
5. An approval page that shows the exact action and the evidence, with one approval covering one action.
6. Problem Details error bodies for every non-success, with the cap, headroom and a stable type URI.
7. Logs and alerting on denials, escalations and pending keys older than a few hours.

Two failure modes deserve attention up front. The first is approval fatigue: if you route too much to humans, they approve without reading, and the audit record says a person reviewed something they did not, which is why sampling override and reversal rates belongs in the design (Keboola on human-in-the-loop for finance). The second is cap creep: raise a threshold quietly and the control drifts, so any threshold change needs multi-party approval (Keboola on human-in-the-loop for finance).

When ticket volume grows, most of your team's cost moves to the approval queue rather than the agent run. A workflow that routes, records and displays evidence cheaply is worth more than a slightly smarter agent.

If you want the agent calling models across text, routing and classification inside the same workflow, Quanta Inference exposes every model category through one OpenAI-compatible key, and you can see the endpoint details at Quanta Inference.