Why AI Keeps Making the Same Mistake After You Correct It

A senior reviewer stops a response because it sounds reasonable while making a promise the company cannot keep. They edit it, send the item on, and return to the queue. A few days later, a differently worded response carries the same underlying problem.

The correction was saved somewhere. The lesson may not have been. That is the ordinary gap between an approval log and a learning system.

Most deployed language models do not rewrite their underlying weights each time a user corrects an answer. They generate from a fixed trained model plus the information, tools, instructions, and context the application supplies for that interaction. A feedback button or edited draft may be retained for later analysis, but it is not automatically a model update.

That does not mean every modern system has no memory. Applications can preserve conversations, retrieve examples, maintain rules, and use evaluation data. The point is narrower: durability is an engineering and operating choice, not a default consequence of a person clicking edit.

Queues commonly record approve, edit, reject, or escalate. Those labels can be useful, but they often leave out the discriminating cue. Was the claim unsupported? Did a small factual change make the case high risk? Was the output wrong, or merely unacceptable for a particular customer, contract, or policy?

Without that reason, a team may have a large history of interventions and still lack a usable instruction for the next case. The record says a reviewer acted. It does not reliably say what should happen when a similar pattern appears again.

A correction can be present in one conversation and absent from the next request. It can be buried in a long thread, omitted by retrieval, contradicted by later instructions, or too specific to generalize safely. Research on evolving agentic systems treats changing requirements and repeat failure modes as evaluation problems, not merely prompting problems.[EvoTest: Evaluating agentic systems under evolving requirements]

A system needs tests for whether a proposed lesson still holds, where it stops holding, and what should happen at that boundary.

For a correction to become reusable behavior, someone needs to name the class of case, reconstruct why the expert intervened, identify evidence that would reverse the call, and test the proposed rule or example on work it did not originate from. A good result is bounded: in these conditions, this behavior is useful; outside them, escalate.

The result may live in a prompt, a policy layer, a retrieval set, a deterministic check, or a routing rule. Its technical form matters less than proof it is safe enough for its intended role.

That is the Never Twice principle: a resolved judgment should stay resolved. Skagway works from reviewed cases and focused expert sessions to make the reason behind recurring intervention visible, then tests whether it can be reused without sending the same routine work back to the same person.

Novel, ambiguous, or required human decisions stay visible. The work is not about pretending that judgment can always be reduced to a rule. It is about refusing to confuse a stored correction with an organization that has learned from it.