Analyst Overrides and AI Agent Feedback Loops

Last updated: September 2026

When an analyst overrules an AI agent, the institution has just generated a piece of evidence, and most systems throw it away. A champion challenger model is the control that lets you keep it. Override data trains a candidate version of the agent, the version making live decisions stays untouched, and promoting the candidate takes evidence and a named human. This page uses the term to mean two versions of the same decision logic, not two competing vendors. Get the arrangement wrong and the feedback loop stops improving the agent and starts encoding one team's habits as policy.

TL;DR

• An analyst override is evidence, not an instruction. It tells you a human disagreed. It does not tell you the human was right.

• Route overrides into a challenger. Keep them away from the version currently making decisions.

• A single override rate is uninterpretable. Stamp every decision and every override with the version that produced it, and the number becomes a comparison that can answer whether your last change helped.

• Record the disagreement, not just the correction. Keep the agent's value, the human's value and a reason. An override stored as an edit destroys the signal at the moment it is created.

• Measure your analysts against each other before measuring anyone against an agent. Consistency between humans is the ceiling on what a loop can learn from them.

• Keep a person at the promotion gate, and put evidence on the gate. A change that fixes the case in front of you can quietly degrade every case you are not looking at.

Learning from analyst overrides: the short answer

How should a risk team use analyst overrides to improve an AI agent? Treat an override as evidence, not as an instruction. Record it as an event carrying the agent's value, the human's value and a reason, so the disagreement survives instead of being overwritten. Send that signal to a challenger — a candidate version scored on the same inputs at the same time without acting on anything — and leave the champion, the version making live decisions, alone. Promotion is then a deliberate swap that requires evidence across a body of cases and a person with the authority to approve it. That is what keeps a feedback loop from quietly turning one team's habits into policy.

The button nobody agrees on

A customer building their own review workflow asked us a question that contains the whole problem. Does the manual override button cause the verification to be re-run, or does it close the case? Those are opposite events, and a system that cannot tell them apart learns nonsense from both. One is a request for a second opinion. The other is a final answer.

The same ambiguity shows up further along. A director of financial crimes compliance at a bank, who had already designed an override workflow and had not finished thinking it through, laid out what was still open: "How do you do that? How long do you keep it? How does it change? And should it ever go back up?"

Those are the right questions, and almost nothing published on champion and challenger testing answers them. A feedback loop built on override data can make an agent measurably better, or it can quietly turn the habits of a few reviewers into institutional policy. From the outside, those two outcomes look alike for a long time.

This page covers what you may do with override data once you have it, and what stops that response becoming an uncontrolled retrain. Noticing that agreement between your agent and your analysts has moved is a separate job, and it belongs with monitoring for model drift.

What champion and challenger mean here

A champion is the version making live decisions. A challenger is a candidate version running alongside it on the same inputs, producing outputs nobody acts on. Promotion is the decision to make the challenger the champion. Champion and challenger models are an established pattern in model risk management, and champion challenger testing of credit models is where most regulated institutions meet it first.

One clarification, because the phrase is overloaded. In outsourcing and third-party risk, a champion-challenger strategy means keeping a second vendor on standby to keep the first one honest. That is a procurement tactic and a different subject. Here, both the champion and the challenger are yours.

The pattern fits override feedback because a challenger is where a signal you do not yet trust belongs. An override is that kind of signal: real information, generated by someone who was looking at the case, of unknown reliability until you have looked at many of them together. Sending it to a challenger costs you nothing and commits you to nothing.

What existing accounts of the pattern miss is the human part. Every treatment of champion and challenger promotes a challenger on model metrics against held-out data. None of them asks what to do when the thing disagreeing with the champion is a person, with judgment, a caseload and a different read on ambiguous evidence than the analyst at the next desk.

The override lifecycle, as one bank actually designed it

The most complete override design we have seen came from a compliance function working through it out loud. It is worth reproducing because it is a real four-state lifecycle, and because what it leaves out turns out to be the point.

The right to override is a control rather than a general capability. In this institution, changing a customer risk rating was restricted to two roles: the financial-crimes lead and the BSA officer. Analysts held a weaker right. They could recommend. An analyst-initiated change routed to a queue, was confirmed there, and came back to a control role for approval as a quality-control step.

That distinction matters more than it looks. A recommendation and an approved override are two different events, and only the second is a decision the institution will defend. A feedback loop that treats them as one thing is learning from the wrong event. Which role should hold which review right is a larger question than this page settles; the piece takes the split as given and asks what it does to the data.

Approval runs in both directions. Any override went through the same process whether it raised risk or lowered it. Reductions got the same scrutiny as increases, which is the opposite of most institutions' instinct and the better design, because a downward override is the one with something to hide.

The override persists through re-scoring. The model kept scoring on its normal quarterly cadence, and the human decision kept winning until a human retired it. The rating still ran; the band did not move. As the compliance director put it, an override applied with justification should "be in play until we would want to remove that" rather than being erased by the next cycle.

It reopens on a state change rather than on a date. What sends an override back for review is a material change in behaviour, such as a new payment rail or a large deviation in activity. Release happened at a scheduled annual review, where someone asked whether the original reason still held.

The four states an override moves through, and who is accountable at each one.

Governance without measurement

What that entire conversation never touched was measurement.

There was no override rate. No agreement rate between the agent and the analysts. No metric of override behaviour of any kind, and nobody raised the possibility that overrides might be inconsistent between analysts. Every consistency control described was procedural: restrict the right, route recommendations through a queue, require approval in both directions, surface the flag to the next reviewer.

Those are good controls, and they answer a different question. Procedural control tells you who may override. Only measurement tells you whether the overrides are consistent enough to learn from.

This is not a story about a careless institution. It had designed more of the override lifecycle than most, and the gap is structural: there is no standard instrumentation for override consistency, no published benchmark, and nothing in the category that ships with it. Which is why the rest of this page exists.

The demand is real and it is not one bank's preoccupation. A compliance leader at a second bank listed "how overrides are handled, how they're presented, how they're managed in change states" among their open questions before signing anything. A compliance reviewer at a third asked whether a score could be lowered "and document the reason why." Notice what arrives in the same breath as the override: the reason.

An override is evidence, not an instruction

Most systems treat an override as an edit. The human's value replaces the agent's, the old value is gone, and the record shows a decision with no trace that anything was ever contested. The disagreement, which is the only genuinely new information in the whole transaction, gets destroyed at the moment it is created.

The design to insist on instead is an append-only event carrying three things: the agent's value, the human's value, and a reason. Keeping both values is what turns the disagreement itself into data. You can count it, group it, and compare it across versions. None of that works on a field that has been overwritten.

The reason field is not decoration. It is the only part of the record that separates a correct override from an inconsistent one. Two analysts reaching opposite conclusions under the same reason code is a training problem; the same conclusion from different reasons is something else. As the quotes above show, this is also the thing buyers ask for unprompted.

Then surface it. The next analyst to open that customer needs an indicator that a manual override is in force, because the override is context for their decision and not only a correction to the model's. Hide it and two reviewers reach different conclusions from the same record, which is the inconsistency this page exists to address. An agent that already shows the input, its reasoning and the final output on every alert is halfway there, and the override has to sit inside that trail rather than outside it.

One point about the status of this. Treating an override as an immutable event is an architectural position, not a product feature anyone can buy off a shelf today. Treat it as a design principle to demand of any vendor, including us.

A disposition tells you what a human thought. An outcome tells you who was right.

A disposition is a judgment recorded at the time: the analyst closed the alert, escalated it, filed on it. An outcome is what actually happened, such as the transaction that turned out to be fraudulent or the customer that turned out to be what the analyst suspected.

These are not the same signal, and the difference decides whether your feedback loop is worth building. A loop trained only on dispositions learns to agree with analysts. That produces measurable improvement in agreement and no improvement in accuracy. It is also self-reinforcing, because automation bias means a reviewer who trusts the agent rubber-stamps it, which raises agreement, which looks like the loop working.

Outcome data can be fed back through the same interfaces used to invoke a decision in the first place, such as flagging a transaction that was approved last week as bad once more is known about it. That turns a backtest from "the decision would have been different" into something an institution can act on: you would have declined these specific cases, and this proportion of them were genuinely bad.

The practical instruction is short. Instrument both, and never let an agreement number stand alone as evidence of quality.

One override rate tells you nothing. A comparison tells you something.

An override rate in isolation cannot be interpreted. The same figure could describe an excellent agent reviewed by careful analysts, or a mediocre agent reviewed by passive ones, and nothing in the number separates the two. Institutions quote these figures to each other anyway, which is how a metric stops carrying information.

It becomes interpretable the moment it becomes a comparison. Stamp every decision and every override with the version of the configuration and the instructions that produced it, and the question turns into one you can answer: did the last change help? That is far more useful than asking whether eight per cent is a good number.

The second measurement worth building is about shape rather than volume. Overrides scattered across unrelated cases are reviewer judgment doing its job. Overrides clustered on a shared characteristic, such as the same customer type, the same typology or the same data gap, are a pattern the agent is getting wrong systematically. Set the clustering threshold from your own volume. There is no defensible industry number for it, and you should distrust anyone who offers you one.

You can establish the most important baseline before buying anything at all. Measure your analysts' agreement with each other on the same cases, blind. Consistency between humans is the ceiling on what any loop can learn from them, and most institutions have never looked at it. If two of your reviewers agree with each other seventy per cent of the time, an agent that agrees with them eighty-five per cent of the time is not what needs fixing first.

For a sense of what the numbers look like in practice, a bank in deployment shows 92% agent agreement with its analyst team on alert disposition and 75% less time per review. Read that the other way round and it is an 8% disagreement rate, which is the override signal this page is about. Treat it as one deployment rather than a benchmark to expect; the useful part is the shape of the measurement rather than the value. Override rates belong on the same surface as your other outcome KPIs measured by segment, because a rate that looks fine in aggregate and terrible in one segment is the normal case.

Route the signal to a challenger, not to the live model

The whole argument comes down to one rule. Override data changes a challenger. It never changes the version currently making decisions.

Promotion then requires three things. Evidence across a corpus rather than a single case, because a change justified by one alert is not a change at all. A like-for-like comparison against the champion on the same inputs. And a named person with the authority to approve the swap.

On that last condition, the regulator's language is better than ours. Revised interagency guidance on model risk management, issued 17 April 2026 as SR 26-2 at the Federal Reserve, Bulletin 2026-13 at the OCC and FIL-15-2026 at the FDIC, retains the concept of "effective challenge" and is specific about who can perform it: individuals with "the appropriate expertise to conduct a critical and objective challenge, sufficient independence to maintain objectivity, as well as the organizational standing and influence to effect any change." A reviewer who cannot change the outcome fails the third condition. That describes the two control roles the bank above had chosen, and it is a workable test for whoever holds your promotion decision. The audit record such a decision leaves behind has its own requirements, covered in what a governance trail for an AI risk agent has to support.

Two points of precision on that guidance, because over-reading it is easy. It says it is "expected to be most relevant to banking organizations with over $30 billion in total assets," which is weaker than applying only to them. It also places generative and agentic AI models outside its own scope, with a request for information on banks' use of AI only planned. So no supervisory framework currently tells you how much human involvement an agent decision needs. You cannot look the answer up. You have to decide it, write it down, and be able to defend it, which is why this is worth getting right rather than treating as a compliance formality.

One assumption worth defusing. Learning from overrides sounds like retraining a model, and for an agent it usually is not. Day-to-day refinement is a versioned change to configuration and instructions rather than to the underlying model, which is both more auditable and easier to reverse. The academic name for the adjacent idea, active learning in machine learning, describes selectively asking a human to label the cases a model is least sure about. Override data is the same instinct arriving from the other direction, unprompted and already attached to a real decision.

What good looks like, in one line: the loop has a human at the promotion gate, and the gate has evidence on it.

Why fixing one case can make everything worse

The mechanism behind the fear is concrete. Adding context to fix one case can lower quality across the corpus. The change that resolves the alert in front of you, whether that is one more instruction, one more piece of context or one more exception, can degrade cases you are not looking at, and nothing will tell you unless you are measuring the corpus rather than the case.

The same reasoning is why correctness-critical work should not let a model decide which typologies to consider. A missed typology cannot be justified to a compliance officer after the fact, and tangential context measurably lowers output quality. Narrow and deterministic beats broad and clever when someone has to defend the result.

So the sequence has to run in this order, and it is worth writing down as procurement questions:

1. Aggregate. Collect overrides as events, with both values and the reason, across enough volume to see shape.

2. Surface the pattern to a person. A cluster is a hypothesis rather than a fix, and it goes to someone who can judge it, not to a retraining job.

3. Let the person decide whether to change anything. Most clusters should result in no change.

4. Ship the change versioned, with a record of who changed it, when, why, and from which underlying events.

5. Gate it on an evaluation step against a held-out body of cases, never against the case that prompted it.

Two rules are worth adopting now as questions to ask a vendor about any future automation of that loop: the system proposes and a human approves, and nothing ships without passing an evaluation step. Neither is a product claim. It is the constraint anyone building this honestly ends up accepting.

What you can measure today, and what you cannot yet

Three things are available with no new tooling. The reasoning trail on every recommendation, which is what makes an override interpretable rather than merely recorded. Agents running against the whole queue rather than a sample, which means the denominator of any override rate is the real one. And your own historical dispositions, which are a baseline you already own and have probably never measured.

Now the limit, stated plainly: there is no published benchmark for override consistency, and this page is not going to invent one. What it can tell you is which comparisons mean something, namely the same agent across two versions, your analysts against each other, and a cluster against the scatter. It can also tell you which do not, namely any single rate quoted without its denominator or its version.

Some of this is not a product yet. Scoring override adherence against your own written procedure at scale is an active direction of development and not something available today. A rating, meaning a thumbs up or thumbs down on an agent's output, is a weaker signal than an override, because it records dissatisfaction without recording what the right answer would have been. Collect it, but do not build a loop on it.

Two things this page deliberately hands off. Detecting that agreement has moved, meaning that your override rate is climbing and you need to know why, is the monitoring and drift problem, and it comes before anything here. The thresholds you commit to before a deployment starts, including what agreement rate you will accept and what you will do if you miss it, belong to the evaluation criteria you set at the outset rather than to the feedback design you build afterwards.

Frequently asked questions

What is a champion challenger model?

A champion challenger model runs two versions of a model or agent at once: the champion makes live decisions, and the challenger scores the same inputs without acting on anything. Promotion is the decision to swap them, and it should require evidence across many cases plus a named human approver. In outsourcing and third-party risk the same phrase means keeping a second vendor on standby, which is a different practice.

What is the difference between an override and a model error?

An override is a human decision to depart from the model's output. A model error is the model being wrong. They overlap without being the same thing: an override can be the human's mistake, a correct catch of a genuine error, or a judgment call in a genuinely ambiguous case. Which one it was is a question you answer by measurement, and the existence of the override does not answer it.

How do you tell a correct override from an inconsistent one?

Two signals do most of the work: the reason code and the clustering. Overrides scattered across unrelated cases with varied reasons are reviewer judgment operating normally. Overrides clustered on a shared characteristic point at a pattern the agent is getting wrong, and identical reason codes producing opposite conclusions point at inconsistency among the reviewers rather than a fault in the agent.

How long does an override stay valid?

Answer this with a state change rather than a duration. An override should persist through normal re-scoring cycles until a human retires it, reopen when the customer's behaviour materially changes, such as a new payment rail or a large deviation in activity, and come up for release at a scheduled review where someone checks whether the original reason still holds. A fixed expiry date is easier to implement and tells you nothing about whether the reason still applies.

Should analyst overrides retrain the model automatically?

No. Override data should change a challenger, never the version currently making live decisions, and the promotion of that challenger should be a human decision supported by corpus-level evidence. Automatic retraining on overrides trains the system to agree with its reviewers, which raises agreement without improving accuracy. It also means a change that fixes one case can degrade cases nobody is looking at.

What has to be true before a challenger is promoted to champion?

Three things. Evidence across a body of cases rather than the case that prompted the change. A like-for-like comparison against the champion on the same inputs over the same period. And an approver with the expertise, the independence and the organisational standing to actually make the change, plus a record of who approved it, when, and on what evidence.

Who signs off on promoting a model that learned from analyst decisions?

Current interagency guidance on model risk management describes the standard through "effective challenge": the person must have the appropriate expertise, sufficient independence to maintain objectivity, and the organisational standing and influence to effect change. In practice that points at a control function rather than the team that built or operates the agent. A reviewer who cannot change the outcome does not meet the third condition.

How do you stop a feedback loop from encoding one analyst's habits as policy?

Four controls, in order. Restrict who may generate an authoritative override, so that not every reviewer's judgment enters the training signal. Record a reason with every one. Measure the corpus rather than the case, so a change's effect on everything else stays visible. And gate promotion on a human decision with evidence attached, so no habit reaches production without someone choosing it.

Can override feedback work with an institution's existing risk systems?

Yes, and it usually has to. Agents can run as a standalone layer on top of infrastructure you already have, or as part of a unified platform, and override capture works the same way either way: an append-only event carrying the agent's value, the human's value and a reason, stamped with the version that produced the decision. What matters is that overrides land somewhere queryable alongside the decisions they contest, rather than that the whole stack gets replaced.

Where to start

The governance half of this problem is well understood and the measurement half is not. Institutions know how to restrict who may override and how to route an approval. Almost none of them can say whether their overrides are consistent. If you are designing an override workflow now, the thing to add is the instrumentation that tells you whether the controls are producing a signal worth learning from.

Start with what you already own: your analysts' agreement with each other, your historical dispositions, and a decision to record overrides as events carrying both values and a reason from the first day rather than retrofitting it later. To see what a decision trail built for that looks like, Oscilar's AI agents show the input, the reasoning and the output on every alert, which is the raw material an override measurement needs.