Self-improving AI agents: what works in production

A self-improving AI agent uses feedback from past runs to change how future runs behave. In production, the parts worth automating are finding failures, proposing fixes and testing them. Keep a person, or a review process you trust, between a proposed change and live behavior.

That’s also the advice in OpenAI’s cookbook on self-evolving agents, which says that “in a real-world scenario you’d want to have additional guardrails and a human-in-the-loop approach to approve new prompts.”

What are the main approaches?

Approach	What changes	Who approves it	Main risk
Agent memory	What the agent stores and reads later	Often nobody, for each write	A wrong or outdated lesson keeps getting reused
Automated prompt rewriting	The prompt, rewritten in a loop against a score	A score threshold, unless you add review	The score improves while real behavior doesn’t
Reviewed corrections	One instruction, scoped to one situation	A person, or a coding agent you supervise	Someone has to own the work, a trigger can match too much, and the model can still ignore the instruction

Agent memory

The agent saves what it learned and reads it on later runs. This works well for facts that belong to a user or a task. It’s harder to audit as a way to change behavior, because lessons accumulate one write at a time and nobody reviews them together.

Automated prompt rewriting

A loop scores the agent’s output, rewrites the prompt and tries again. In OpenAI’s cookbook, feedback comes from people or an LLM acting as judge, and the loop runs until the score passes a threshold such as 0.8 or it runs out of retries. If retries run out, engineers are alerted. The cookbook marks this recipe as archived, so check it against current models and APIs.

Reviewed corrections

A person or coding agent writes one correction for one recurring mistake, previews where it would apply and turns it on. Progress is slower than a fully automatic loop, and each change is small, attributable and easy to remove.

What goes wrong when agents change themselves?

• Over-correction. A lesson from one case spreads to situations it was never meant for.
• Optimizing for the grader. A score only reflects what it measures. Cases missing from your test set can get worse while the number goes up.
• Noise that looks like progress. Agents vary between runs, so a better score on a few trials may be chance. Anthropic runs multiple trials for this reason.
• Changes with no author. When behavior shifts, nobody can point to the change that caused it or say why it was made.

What does a dependable improvement loop look like?

1. Capture full runs and outcomes. Include tool calls, results, feedback and how each run ended.
2. Find what repeats. Automation helps here. LangSmith Engine and Braintrust Patterns both look for recurring problems in traces.
3. Propose a fix. A model or coding agent can draft it. Those same tools suggest fixes, and LangSmith Engine stops at a pull request that it never merges.
4. Check it against real history. Run it on past conversations and on your evals, including nearby cases where it shouldn’t apply.
5. Approve the scope. Decide which conversations it reaches.
6. Roll out and compare. Hold some sessions back and compare outcomes. Remove anything that doesn’t help.

Is Mirrors a self-improving agent platform?

No. Mirrors doesn’t rewrite your agent on its own. It surfaces recurring mistakes across your agent’s runs, and you or your coding agent write the correction. You preview where it would apply. 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.

If you want a fully automatic loop, Mirrors isn’t that. If you want to change your agent through small steps you can review and undo, see how it works.