Where to put human approval when an agent can change business records

Decide per action, using rules you already have

Most organisations already have authority rules: who may post an invoice above a certain amount, who may change a supplier's bank details, which changes need a second person. Start there. An agent should not hold more authority than the most junior person who does the same work today, and the approval points should follow the same lines.

Then mark the points of no return. Microsoft's guidance on compensating transactions recommends identifying which steps can be undone and which cannot, and placing irreversible steps only after all critical checks have passed. The Model Context Protocol specification makes a related recommendation for tools: a person should be able to deny a tool invocation, and clients should ask for confirmation on sensitive operations.

A worked approval matrix

For a hypothetical accounts-payable agent, the matrix below is the kind of result this exercise produces. The thresholds are placeholders; yours come from your own authority rules.

• Read invoices, orders and goods receipts: no approval
• Draft a hold note or a query to the supplier: no approval, but the message is sent only by a person
• Post a fully matched invoice below the threshold, for example 2,000 euros: no approval, a weekly sample is reviewed
• Post an invoice above the threshold or with any deviation: approval by an accounts-payable clerk
• Change supplier master data or bank details: not available to the agent at all

The last line matters. Some actions are better removed from the agent's tools than guarded by an approval, because an approval can be granted by mistake and a missing tool cannot be called.

What the approver needs to see

• The exact change: which record, which fields, old and new values, the amount
• The evidence the agent used, with links to the source documents
• Why the pause happened: the rule, threshold or deviation that triggered it
• What approve, edit and reject will each do next

Record the decision with the approver's identity, the time and the version of the proposal they saw. That record is your decision evidence when someone later asks why a payment went out.

How the pause works in the code

Agent frameworks support this directly. In LangGraph, interrupt() saves the graph state through a checkpointer and waits until the run is resumed with Command(resume=...). In the OpenAI Agents SDK, a tool marked with needs_approval pauses the run and returns the pending call as an interruption, and the run state can be serialised and resumed after a person approves or rejects it.

Three details decide whether this is safe. First, LangGraph re-runs the interrupted node from its start on resume, so any side effect placed before the interrupt runs again. Second, the action that executes must be bound to the arguments that were approved; if the agent changes them, ask again. Third, a saved checkpoint does not make the external write happen exactly once. If the process fails after the payment call but before the result is recorded, a resume can send it again unless the receiving system deduplicates the request.

Keeping approvals from stalling the work

Measure the time a case waits for approval separately from the time the agent works on it, and give the queue an owner and a target. Group similar approvals so a clerk can clear ten matched invoices from one supplier in one view. Decide what happens when nobody responds: the case goes back to a person's queue, it is never approved by default.

Then watch what approvers do. A category that is approved unchanged almost every time over months is a candidate for sampling instead, and the process owner makes that call with the data in front of them. A category with frequent edits or rejections tells you the agent is not ready for it.

When approval gives false comfort

Approval fails quietly when approvers cannot check what they are shown, when the volume pushes them into clicking through, or when sensitive reads, such as an agent pulling an employee file, are never gated because nothing was written. Whether a decision legally requires a person is a question for your counsel and, where relevant, your works council. The engineering contribution is to show where people decide and to keep the record of each decision.