The Judgment Decorator

Every loop starts with judgment and ends with realignment

Andrew Chen wrote something recently that anyone building with agents will recognize: the skills he builds “just end up generating more and more things for me to review. What I want now is actions. More outcomes, fewer copilots.” The better his agents get, the taller the pile on his desk. The pile isn’t tooling immaturity, and it doesn’t shrink as the agents improve - it’s structural, and the structure has a name.

Judgment is conserved. You can move it around a system, but somebody pays for it somewhere. A copilot pays at the end of every task: each output lands in front of a human because nothing else in the system knows what done means. Review scales with output volume - O(outputs), if you like - which means the pile grows precisely as fast as your agents improve. That’s the trap in “just review everything”: the cost curve points the wrong way forever.

The alternative isn’t removing judgment. Nothing else in the loop can supply it. The alternative is moving where it gets paid: write down what good means - once, explicitly, in a form a machine can check work against - and the cost curve flips. Review stops scaling with outputs and starts scaling with changes to the standard. You approve edits to the definition of good, not every artifact the definition approves.

An outcome, in this frame, is a loop that closes without you. And a loop can only close when “done” is a predicate the system can evaluate - and the predicate turns out to have three parts: is it correct (done), is it good (quality), and is it aligned (still serving what we’re actually trying to do). Code has decades of tooling for the first part. The second and third are where agents drift, and where the review pile comes from.

Here’s the design pattern hiding in all of this. Judgment shouldn’t sit at the end of the pipeline; it should wrap each loop, like a decorator. Steering goes in before the work starts - the standards, the definitions, the context the agent needs to know what good means here. Verification comes out after - the work checked against those same definitions before it lands. Judgment isn’t removed from the system. It’s factored: hoisted out of the review queue and into a wrapper every loop passes through. Every loop starts with judgment and ends with realignment.

This isn’t hypothetical. Basis, whose tax agents run for hours and sometimes days in production, found that outcome-checking breaks down at that horizon - too many decisions, too little generalization - so they supervise the process instead, and last week they open-sourced the written behavior specs that make it work. Their conclusion, which I’d frame as the whole argument in one line: the ground truth for an agent isn’t its output, it’s how it behaves.

The decorator is where the metaphor ends, not where the problem does. Decorators don’t rewrite themselves. The definitions of good that wrap your loops have to evolve - every failure that slips through is a sentence missing from a standard somewhere, and the fix is editing the standard, not reviewing harder. That evolution is its own loop, and it needs the same care: definitions under version control, changed deliberately, reviewed like the load-bearing code they now are. The wrapper is static machinery; the judgment inside it is a living document.

None of this is new, exactly. Companies have been trying to wrap human loops in judgment for a century: mission statements, standard operating procedures, OKRs - all attempts to write standards explicit enough to manage by exception instead of by inspection. Mostly it half-worked, because people read documents loosely and enforcement was social. The difference now is that the reader is literal. Agents actually consult the standard, checks actually run, and management-by-exception stops being an aspiration and becomes an architecture.

Which leaves the question that I think matters more than any of the tooling: who gets to own judgment? It has to live somewhere. Post-train it into the weights and the model provider holds your definition of good. Encode it in a framework and the framework does. Write it down, in files you control, and it stays yours - portable across models, inspectable, yours to change. Everyone racing to make agents more capable is implicitly answering this question one way or another. It seems worth answering it on purpose.