Self-Improving Learning Loop
Feedback and outcomes become updated memory, skills or prompts over time.
Problem
Most agents ship and then stay the same until an engineer rewrites a prompt. Meanwhile users correct them, reject drafts, rate answers and work around the same mistakes every day. All that signal is lost, so the agent never gets better at the specific work it actually does.
- Users give constant feedback, mostly implicit (edits, rejections, rework).
- Changing an agent automatically risks making it worse.
- Feedback is noisy, and one user’s preference isn’t everyone’s.
- Improvements must be explainable and reversible.
Solution
Capture feedback from every run: explicit ratings, edits users make to outputs, rejected actions, and downstream outcomes like a reply that resolved the ticket. Group the signals into recurring lessons, such as “users always shorten the intro” or “agent misreads fiscal-year dates”. Turn each lesson into the cheapest fitting change: a memory entry for one user, a prompt or skill update for everyone, or training data at scale. Every change is proposed, evaluated against a test set, approved, versioned and can be rolled back.
Diagram
The loop runs on evidence, not single complaints. Every change passes an evaluation gate and can be rolled back.
When to use
Use it when
- The agent runs often enough to generate steady feedback
- Users edit or correct outputs in ways you can capture
- You have an evaluation set to test changes before rollout
- Improvement over weeks matters more than perfection on day one
Avoid it when
- Low volume, so feedback is too sparse to learn from
- No evaluation gate; automatic changes would be untested
- Regulated settings where behavior changes need formal re-approval each time
Trade-offs
Gains
- The agent gets better at the actual work it does
- Users see their corrections stick
- Clear record of what changed, why and with what effect
Costs
- Needs a pipeline and an owner, not just a prompt
- Can learn the wrong lesson from noisy or biased feedback
- Personal and shared lessons have to be kept apart
Worked example
A personal assistant drafts weekly status updates for a team of 12 managers.
- CaptureOver 4 weeks, it logs 48 drafts and the managers’ edits. Edits are compared with the original drafts automatically.
- ClusterFinds two lessons. 9 of 12 managers delete the opening paragraph, so that’s a shared lesson. One manager always converts bullets into a table, which is a personal one.
- ChangeThe shared lesson becomes a prompt update: start with the top 3 outcomes, no preamble. The personal lesson becomes a memory entry for that manager only.
- Eval gateThe prompt update is tested on 40 past weeks. The rubric judge scores it higher on conciseness with no drop in completeness. A team lead approves it as version 4.
- ResultAverage edit size falls from 34% of the draft to 12% over the next month. Version 3 stays available for rollback.
Failure modes
| Failure | Symptom | Mitigation |
|---|---|---|
| Learning from noise | One loud user's preference changes behavior for everyone | Require a pattern across users before a shared change |
| Ungated changes | An automatic update quietly makes things worse | Every change passes evals and approval; versioned rollback |
| Personal vs. shared mix-up | One user's style imposed on others | Separate personal memory from shared prompt and skill changes |
| Only explicit feedback | Few ratings, so little learning | Capture implicit signals like edits, rework and outcomes |