Review an agent system and you end up with a list of findings. The list isn't the problem. Where it goes is.
The default move, most of the time: read it, nod, remember it, be careful next time.
"Be careful next time" is not a fix. It's a feeling, not a constraint. Change the person, the context window, or the model version and it stops existing. The same problem comes back unchanged next round, and you'll think you already solved it.
Entropy applies to agents
Agents copy existing patterns, the good ones and the bad ones alike. Whatever is in the context they read is what they tend to produce.
So "we fixed it this time" almost never means "it stays fixed." Without hardening the standard, the next run drifts back — silently, because nothing is watching that standard.
This is where agent systems differ most from ordinary software. In ordinary software, fixed is fixed. In an agent system, gravity is still there after you fix it.
A finding has exactly three legal destinations
The rule I hold myself to: every line a review produces has to land in one of three places.
- Fix it now. If it can be changed on the spot, change it.
- Encode it as a checker. If it can't be fixed, or will recur, turn it into a check a machine runs every time.
- Write down why it can't be automated yet — along with what currently covers it: who watches, and how often.
A finding that does none of the three is not a finding. Everything left on the list as "watch out for this" or "tighten the wording" will be regenerated word for word by the next review — which is itself the proof.
The test can be harsher: a rule that can't be machine-verified hasn't really entered the process. It's still a piece of prose.
When we built a short-video production line, we started with ten hard rules, each one earned by having work sent back. For the weeks those rules lived in a document, the same mistakes kept happening. Only when they were translated one by one into assertions in a QA script — is the footage actually on topic, is the persistent text inside the safe area, do two adjacent episodes share a shot — did rework actually fall. The order matters: write it into the checker first, then into the handbook. Do it the other way around and rules decay back into prose.
A generator can't evaluate itself
An easy trap: using the same agent, with the same context, to check what it just produced.
It will be systematically lenient. It knows why it wrote that, the reason is still warm in the context, and every questionable spot gets explained away.
Evaluation has to be independent: a separate prompt, separate examples, ideally a separate model. Not to be smarter — to not share the excuses.
Full reviews find new constraints; they aren't routine
A thorough human review is expensive, so its job should be prospecting: finding the class of problem no checker covers yet. Once found, encode it, and let the checker hold the line from then on.
If every human review turns up the same class of problem, that class should have been mechanized long ago — and what needs reviewing isn't the system, it's why you're still doing this by hand.
Checkers need maintenance too
Adding checks feels good, but more isn't better. Too strict and they become noise people learn to ignore; too loose and they're decoration that only provides comfort.
So revisit them: which warnings turned out to be real problems, and which never did. A check that has never fired should be tightened or deleted — an alert nobody believes is worse than no alert.
Still unresolved
When should a constraint move from the prompt layer to the code layer?
The prompt layer is cheap and easy to change, but the model can "interpret" it away. The code layer is rigid and reliable, but every rule there is maintenance. My rule of thumb: when the same recommendation fails to take effect several rounds in a row, promote it.
I still don't have a good answer for "several." Two might be coincidence; five might already have burned a month.