When an AI agent gets it wrong: design the correction loop

An agent drafting recurring finance work will get things wrong. It will code a supplier invoice to the wrong nominal, miss a credit note, or describe a variance in a way no client would accept. So does every new colleague in their first months. What matters is what happens next. In most teams, AI agent mistakes are fixed by the reviewer, in the output, and then forgotten. The draft gets corrected, the file moves on, and next month the same mistake comes back. This post makes one argument: the correction loop is something you design before the agent starts, not something you hope for after.

The quiet workaround problem

Picture how review works when nobody has designed the loop. Take a hypothetical bookkeeping firm where an agent drafts the monthly management accounts commentary for a dozen clients, and a manager approves each draft before it goes out.

In month one, the manager rewrites three paragraphs. In month two, the same three kinds of paragraph. By month four the manager has stopped reading the draft closely and simply rewrites the sections they know will be wrong. The agent is "working", the pack goes out on time, and the manager is spending nearly as long as before. Worse, the knowledge of what the agent gets wrong lives in one person's head again, which is the exact key person risk the handover was meant to close.

That is a quiet workaround. Nobody chose it. It happens because fixing the output is always quicker today than fixing the instructions, and nothing in the process asks for the second step.

AI agent mistakes are information

A correction is the most precise feedback you will ever get on a set of instructions. It says: here, on this input, the method you wrote down produced the wrong answer. Thrown away, it is lost time. Captured, it is the next line of the manual.

The trick is that not every mistake has the same cause, and each cause has a different fix. In practice most corrections fall into four kinds.

1. The instruction was missing or vague. The manual said "flag unusual variances" without saying what unusual means. The fix is a sharper instruction: a threshold, an example, a rule.
2. The input was wrong or late. The bank feed dropped a day, the client sent last month's file, a reference was free text. The agent did what it was told with bad material. The fix sits upstream, in the input, not in the agent.
3. It needed judgement the task does not have written down. A one-off client situation, a partner's preference, a sensitive conversation. The fix is a stop-and-ask rule: when this happens, hand it back to a person.
4. The agent simply got it wrong. The instructions were clear, the input was fine, and the output was still wrong. This is the rarest kind once the first three are handled, and it is the one that matters most for trust.

Without sorting, all four look the same on the reviewer's screen: a red pen through a paragraph. Sorted, they point to four different owners and four different fixes.

Designing the correction loop

The loop does not need software. It needs four habits, agreed before the agent drafts its first piece of work.

Log every correction against the task

Each time a reviewer changes an agent's draft, they write one line: what was changed, which of the four kinds it was, and what the right answer was. This sits against the recurring task, not in someone's inbox, in the same way as the exceptions log for work done by people.

Give each kind an owner

Instruction gaps go to whoever keeps the manual for that task. Input problems go to whoever owns the input, which is often a client chaser rather than anyone near the agent. Judgement cases go to the task's manager, who decides whether to write a stop-and-ask rule. Plain agent errors go to whoever set the agent up. A correction without an owner is a workaround waiting to happen.

Change the instructions, then check the change

When an instruction changes, write down what changed and why, and run the new version over the last two or three periods' inputs before trusting it. A new rule about variances can fix one client and break another. This is the same discipline we described in writing SOPs for AI agents: the manual is what the agent runs on, so a change to it is a change to the work.

Close the entry

A correction is closed when the fix is in place and the next run did not repeat it. If the same correction turns up three months in a row, the loop is broken somewhere, and that is worth a conversation with the reviewer rather than a fourth fix.

What the log tells you about trust

A good correction log does a second job. It is the track record that decides how much freedom a task's agent earns.

On the ladder from drafts first, trust later, a task moves from "agent drafts, person approves" to "agent acts, person reviews after" only on evidence. The correction log is that evidence, read by kind. A task whose corrections are falling and are mostly input problems is close to ready for the next step. A task where plain agent errors keep appearing is not, however tidy the rest of the output looks.

The log also protects people from a bad promotion. If an agent is moved up a level on a manager's impression, and the impression was formed while that manager was quietly rewriting the weak sections, the first unreviewed month will show it. Read the log, not the mood.

The reviewer's job changes, and that is the point

Be plain with the team about what this asks of reviewers. Logging a correction takes longer than making it, for the first few months. That cost is real and should be counted in the hours the handover is expected to return.

What the reviewer gets back is better. Instead of fixing the same paragraph every month, they are teaching a method once and watching it hold. Their judgement ends up written down, attached to the task, and credited to them, rather than spent invisibly every close. That is the version of AI in a finance team people tend to want: the dull half of the job goes first, and the skilled half becomes visible. It is also why Beaks is designed to keep corrections, approvals and their reasons on the handover record, rather than in a side channel.

One thing to do this week

If any agent or AI tool already drafts recurring work in your team, pick one task and start a correction log today with three columns: what changed, which of the four kinds it was, and who owns the fix. After the next run, read it with the reviewer. If nothing drafts yet, write the log template now and attach it to the first task you plan to hand over, so the loop exists before the first mistake does.