On this page
Key takeaways
- An agent doesn’t learn from production on its own. A mistake repeats until something changes what the agent sees or can do in that situation.
- The usual causes are a rule in the wrong place, an instruction that’s missing when needed, a confusing tool, a pattern nobody grouped and a fix nobody measured.
- Group failures by situation, not by error message, then rank them by how often they happen and what they cost.
- Test each fix across several runs and on nearby cases where it shouldn’t apply.
An AI agent repeats a mistake because nothing has changed about the situation that causes it. The model doesn’t learn from your production runs on its own, so the mistake stays until someone finds the pattern, changes what the agent sees or can do in that situation, and checks that the change worked.
This guide covers agents in production that work with customers or business systems. Coding agents like Cursor and Claude Code follow the same logic, but the fix usually lives in a rules file or a hook. Claude Code’s best practices cover that case.
Why do AI agents repeat the same mistakes?
These are the usual causes, in a sensible order to check them.
The fix is in the wrong place
A team adds a prompt line for a rule that has to hold every time. A prompt line is a request to the model, and there’s no guarantee the model will follow it.
- Check: Would one miss cause real damage?
- Fix: Enforce the rule in code, with validation, permissions or a tool guard.
The instruction isn’t there when it’s needed
The right instruction exists, but it’s buried in a long system prompt or sits in a skill the model never opened. In Vercel’s evals of a coding agent, the skill was never invoked in 56% of cases under default behavior.
- Check: Look at the exact prompt the failing run received, and whether the agent read the instruction.
- Fix: Deliver the instruction from your harness when the situation comes up.
The real problem is a tool
Many mistakes that look like bad judgment start with a tool. The description is vague, a parameter is ambiguous, or a result leaves out a field the agent needs. A prompt patch works around this for a while without fixing it.
- Check: Read what the tool returned in the failing run. Given that result, was the agent’s choice reasonable?
- Fix: Change the description, schema or result. Anthropic found that “Even small refinements to tool descriptions can yield dramatic improvements.”
Nobody saw the pattern
Each failure arrives alone. Support sees a complaint, an engineer sees one odd trace, and nobody connects them to the other sessions that went the same way.
- Check: Can you say how many sessions hit this failure last week?
- Fix: Group failures across runs, using the steps below.
The fix was never measured
Someone patches the prompt, tries it once, sees it pass and closes the ticket. Agents vary from run to run, so one pass says little. Anthropic’s example: a 75% per-trial success rate gives only about a 42% chance of passing three trials in a row.
- Check: Do you have before and after numbers for the fix?
- Fix: Test across several runs, then compare production outcomes with and without the change.
If you run several agents together, the MAST taxonomy is worth reading. It catalogs 14 failure modes in three categories: system design issues, inter-agent misalignment and task verification.
How do you find the mistakes that keep recurring?
- Capture full runs. Keep messages, tool calls, tool results and how each run ended. Error logs alone miss runs that finished cleanly with the wrong result.
- Collect outcome signals. Customer corrections, escalations, retries, failed checks and support tickets all point to runs worth reading.
- Read the failing runs. Langfuse’s error analysis guide has a good method: note the first thing that went wrong in each trace, then cluster those notes into failure categories.
- Group by situation. “Changes coverage before checking the driver’s license” tells you what to fix. “Tool error” doesn’t.
- Rank by frequency and cost. A rare failure that moves money can matter more than a common one that annoys nobody.
Several tools now automate parts of this. See how observability, evals and corrections compare.
How do you make a fix stick?
- Put it in the right layer. Hard rules go in code and tool guidance goes in the tool. Use this table to sort the rest.
- Keep it narrow. Say what should change and when. Check nearby situations where the fix shouldn’t apply, as well as the ones where it should.
- Turn the failure into a test. As Anthropic puts it, “failures become test cases, test cases prevent regressions.”
- Roll it out gradually. Start with part of your traffic and hold some sessions back for comparison.
- Check the outcome. Compare failure rates between sessions that got the fix and sessions that didn’t. Remove fixes that don’t help.
Where Mirrors fits
Mirrors is a developer tool for production AI agents. It helps with two of the causes above: patterns nobody saw and instructions that aren’t there when needed. It surfaces recurring mistakes across your agent’s runs, and you or your coding agent write a correction for each one. You preview the stored conversations it would have reached. When its trigger matches, the SDK returns it and your harness appends it to the prompt. A holdout keeps a share of matching sessions without it, so you can compare outcomes using the metrics your team tracks.
Hard rules still belong in code, and a confusing tool still needs fixing. See how Mirrors works or read the corrections guide.