Build the Improvement Loop Into the System

Fixing a mistake changes one output. Improving a system changes what it produces next time. Most people only ever do the first: the AI produces something wrong, you correct it, you move on, and next week the same wrong thing comes back because nothing about your correction outlived the moment. The output got better once. The system that produced it learned nothing. Building the improvement loop in means treating each correction as data the system retains, so the second time a class of mistake shows up it has already been designed out.

The starting point is unglamorous and most teams skip it: you have to actually look. Not at a dashboard of scores, at the real outputs, one after another, reading what the model did and writing down where it went wrong in plain language. The strongest articulation of this comes from the evaluation field, where the move is to read on the order of a hundred real traces, take open-ended notes on each failure, and then group those notes into recurring failure modes. The reliable finding when teams finally do it is that around eighty percent of their errors trace to a small handful of issues they had no idea existed, problems no generic metric was ever going to surface because nobody had looked closely enough to name them. A dashboard of generic scores can measure a great deal while explaining none of it. Reading the actual outputs is what tells you which failures are real and which one to fix first.

Once you know what is breaking, the lesson has to go somewhere it will actually change future runs, and this is where the real craft sits. Not every correction belongs in the same place, because corrections differ in how general they are and how long they stay true. A quirk of one specific tool, the way some API returns dates in an odd format, is true only for that tool and belongs right next to the code that talks to it. A gap in a particular reusable workflow belongs with that workflow, queued as a change to make. A genuinely general lesson, something that holds across tools and projects and would help even on work that never touches the thing that taught it, belongs in your durable cross-project knowledge. And a doc that has simply grown too long to read belongs in a trimming pass. Routing by this half-life is what keeps each store useful, because a lesson filed in the wrong place either clogs something that should stay lean or gets buried somewhere nobody rereads.

Two disciplines make the routing hold up over time. The first is a generalization gate you apply before promoting anything to durable knowledge: would another agent, or you on a completely different project, benefit from this even if they never touch the tool that produced it? If not, it stays local, because a durable store that fills with project-specific trivia stops being read, and an unread store improves nothing. The second is separating capture from application. The moment you notice a lesson is usually a bad moment to apply it well, because you are mid-task and low on attention, so the move is to log it cleanly now and apply it in a dedicated pass later when you can do it properly. The workspace these lessons come from runs exactly this split. Skill-specific lessons get logged to a queue and applied in a session whose only job is draining that queue. Cross-cutting lessons get written as durable memory entries with the reason and the how-to-apply attached. The architecture that actually enforces behavior lives in the workflows and checks, not in the memory, which holds only the general lessons. Memory reminds. It does not enforce.

The loop has one hard dependency that is easy to violate: the improvement signal has to come from outside the model. Asking a model to "check your work" with no new information is not a correctness signal. A model told to revise without an external check will often turn a right answer into a wrong one, because nothing independent is telling it which is which, and it cannot separate a real error from a fluent non-error by staring harder at its own output. The loop works when the signal is a real correction, a failing test, a human catch, a verifier the model cannot talk its way past. It does not work when the signal is the model grading itself, and a loop built on ungrounded self-reflection can degrade the thing it was meant to improve.

The other failures are about the bookkeeping rotting. Capture without application is the common one: logging corrections feels like progress, but a queue nobody drains is a graveyard of good intentions, and the mistakes keep happening while the lessons pile up unread. The apply has to actually occur. Miscategorization is the slow one: send every lesson to a single store and it bloats past the point of being read, which silently breaks the whole loop because the store you stopped reading can no longer change anything. And there is a human failure that gets worse precisely as the system gets better. When outputs are usually right, reviewers stop genuinely reviewing and start rubber-stamping, so the rare wrong output sails through unchecked exactly because the system earned that trust. The defense is behavioral, not technical: review as if something is wrong, especially when you expect it to be fine.