Who lets an AI correction change the books?
The AI Operator | October 16, 2026
An AI that spots an error in a financial record can save a team time. Letting it correct that error brings a new duty: the team must decide who approves the change and how to check that it was made correctly.
A conference report this week describes one approach. Richard MacManus reports that Anthropic’s Keon Shahab discussed an AI agent that looks into trade records that do not match. The agent suggests a change to an order, then puts that change before a person for approval.[1]
For a finance team, the next question is how that approval works in practice. The system needs to wait for the person’s decision, make only the change they approved and leave a clear record of the result.
What’s Happening This Week
The report describes a person reviewing the proposed change. Some details remain unclear, including what the agent can do on its own and how the system blocks a change that has no approval.[1]
There are ways to set those limits. Anthropic’s guide for people who build agents describes rules that can block an action or ask for permission first.[2] A team can use those rules to control what an agent may do.
The guide does not tell us which rules were used in the conference example. A finance team would still need to see what that agent can change and whether it has another way to reach the same records.
Why This Is a CFO Problem
Imagine an order with the wrong amount. A member of the finance team checks the record and approves a fix. While the agent waits to act, someone else changes the order.
The first person approved a fix based on the old record. Should that approval still count? A safer rule would send the changed order back for review. Otherwise, the agent could apply a fix that no longer fits.
The team also needs to check what happened after the change. A message that says “done” does not prove that the right amount was saved.
Keeping the old amount, the planned change, the approval and the final amount gives the team a clear record. If a problem comes up later, someone can follow those steps and see where things went wrong.
The Operator’s Check
Start with a made-up order in a test system, away from live records. Let the agent check the order and suggest a fix. Then ask it to make the change without approval. The system should block it. That block should hold even if the agent tries another way to make the change.
Next, approve one clear change and check the saved order. The amount should match the approved fix.
Repeat the test, but change the order after approval and before the agent acts. The system should stop and ask for a fresh review, since the person’s first decision was based on a different record.
There is one more case to check. The agent sends a change, but no answer comes back. The team may not know whether the change went through. Before trying again, check the saved record. Sending the same request twice could cause a second change.
These tests would help a team check its own system. The conference report does not show whether the agent in the talk passed them.
Money Move
Pick one task where an agent suggests a change to a money record. Ask the person who runs it to show how the system handles approval, using made-up records.
Watch what happens when the agent tries to act without permission. Then watch what happens when someone changes the record after approval. Finally, check that the saved result matches the change the person approved.
Keep the agent from changing live records until those checks are clear. If a change later needs to be undone, check the saved record again to make sure the old value is back.
The conference example shows how an agent can bring a proposed fix to a person. Before a team lets it change the books, it needs to see that the system follows that person’s decision and checks the result.
-dg