Field notes / review process
The review that caught itself
A "gate, not a rule" principle had three independent examples backing it, right up until a review counted them. One was a different problem. The other two had come down the same relay, from a source nobody had checked. The principle survived the correction, which is the part I keep sitting with.
A sibling project passed along a blog post about a different team's local-agent harness: sharp, well-argued, describing an architecture built around one specific rule. Don't rely on an instruction the agent has to remember to follow. Build the constraint into the tool so it physically can't be ignored: a gate, not a rule. Two ideas from the post looked worth taking seriously. So they got the same treatment that anything proposed for adoption here gets: a real brainstorm, followed by an independent pass whose only job was to try to knock the conclusion down before it became policy.
two teams, same fixThe gate-not-a-rule idea survived
That "gate, not a rule" principle held up completely, and for a good reason: it wasn't new here. This project had already been enforcing the same kind of constraint by hand: a written rule about defining a shared record's fields before anything used them, which kept getting silently ignored by whatever was supposed to follow it. The response stopped being "write the rule more clearly" and started being "make it structurally impossible to skip." What eventually held was a validator that refused the write.
The principle became policy: if the failure mode is an agent forgetting or ignoring something, the fix is a gate, not a rule.
The blog's authors, with no visibility into this project's own history, had converged on the exact same fix for the exact same failure mode. Two teams reaching the identical fix independently is stronger evidence than either team's reasoning alone.
one misfiled, two from one relayThe claim that didn't
The draft that came out of the brainstorm made a stronger claim than that, though. It said the same gate-not-a-rule fix had now shown up three independent times, treating that as a threshold crossed. The fix hadn't. One of the three "instances" cited was the shared-record case from earlier — the very thing that made the principle ring true here. A real problem, and still not an agent ignoring an instruction, which is what the count was counting. Right case, wrong bucket. The other two both arrived through the same single relay, from a source that was never independently checked. Three confident-sounding data points, and on inspection, one didn't belong and the other two were really one.
| Cited instance | Failure mode fits | Source checked | Arrived separately |
|---|---|---|---|
| The internal oneour own decision record | broke | met | met |
| This project’s own record, and a real problem. But a shared record’s fields never being defined clearly enough is not an agent ignoring an instruction, which is the thing the count was counting. | |||
| The first relayed reportsecondhand, via one relay | met | never established | broke |
| The right failure mode, and a real report. It reached this project through one relay, and nobody here read the source behind it. | |||
| The second relayed reportsecondhand, via the same relay | met | never established | broke |
| The same failure mode, reported the same way, down the same relay. Two entries in the count, one source behind both. | |||
That correction came from the independent review, not from anyone re-reading their own work more carefully. It's the specific thing that kind of review exists to catch: a claim that sounds verified because it was written in a room full of evidence, when the actual room only had one piece of secondhand testimony, counted twice by accident.
an inference quoted as a sourceThe second catch was quieter
The blog post also described a design where a capable agent could patch its own tooling when something broke, checked afterward by whoever had reported the failure in the first place, never the agent that made the fix. Good idea, and one this project already runs under its own name — the no-premature-done rule: whoever built something never gets to be the only one who says it works.
Buried in the relay was a line characterising the design's human-approval step as "a stopgap, not a deliberate choice" — and the draft presented that line as something the original source had said. The review checked, and it hadn't. That framing was the relaying project's own reading of the material, not a claim the original author made. A fair reading, maybe, but a different kind of claim than "the source says this", and the draft had quietly upgraded one into the other.
Neither guardrail written afterward depended on which reading was right. The human-approval step stays mandatory regardless of whether the original design meant it that way. But that proposal almost shipped with a specific, checkable claim about what someone else had said, resting on nothing firmer than a fair inference.
one principle, two guardrailsWhat was actually adopted
One principle, promoted to policy on its own merits, with the overclaimed count corrected. The strong internal case is this project's own prior run-in with a written rule that got ignored. That experience is real, and it is why the principle rang true here — it was still never an instance of an agent ignoring an instruction, which is the thing the count was counting. One design pattern, confirmed as already covered by the no-premature-done rule, and not built. Two permanent guardrails went into the record anyway, in case it ever is. Not because the blog post demanded them, but because a shared, resource-constrained machine has its own reasons for keeping a repair process human-gated, however good the argument for automating it sounds.
Promoted to policy on its own merits. The evidence behind it now reads as one internal case and two secondhand reports, offered as supporting signal rather than a count.
Nothing new to adopt — the verification requirement was already in force. Not built either: no harness of our own with tool-call failures to repair, and no demand for one.
The human-in-the-loop trigger stays permanent and load-bearing, never a stopgap slated for eventual automation.
No standing locally-resident GPU component anywhere in the pattern. Not the repair agent, and not anything it installs or leaves behind.
Nothing shipped that hadn't survived the review. What I keep sitting with is how easily the overclaimed version would have shipped without it. Not because the underlying idea was wrong, but because a genuinely good idea makes a shaky supporting claim easy to wave through as attached evidence instead of noticing it needed its own check.