Operator OS in a box
The same model does wildly different work depending on what you build around it. So I tried to extract the environment (memory, judgment, trust, improvement) into something runnable, and prove the capability was never really in the model.
Run the same coding agent in two setups and you'll watch it behave like two different tools. One has a guard that refuses the dangerous command, an eval that tells it when it's wrong, a memory that survives across sessions, and a clean loop for getting better. The other is a chat window. Same model in both. The first one is dramatically more useful, and the difference has nothing to do with the weights.
I kept noticing this and wanted to prove it to myself, cleanly. So I took the environment I'd built up around my own agents and tried to extract it: strip out everything personal (my actual memory, my real guard values, my fixtures) and keep only the pattern, as something runnable that someone else could pick up and adapt.
The repo is the smallest coherent thing I could build that is that environment, organized around four jobs that, in a good setup, you've moved out of the model's head and into the world around it.
The four things you externalize
Memory: what the agent should know without being told again. Instruction files, path-scoped rules that only load when they're relevant, prompt and plan templates, an index convention so the agent can find its own context. You externalize memory so the model isn't re-deriving your conventions every session.
Judgment: what "good" means, made executable. A runnable eval loop: a rubric, a synthetic fixture with a planted bug or two, a scorer, and a harness to run it. You externalize judgment so quality stops being a feeling and becomes a number you can watch move.
Trust: what the agent is simply not allowed to do. A guard dispatcher that fails closed, a couple of worked example guards, a tiered policy, and a hard-deny set the agent can't talk its way past. You externalize trust so safety doesn't ride on the model choosing to be careful in the moment.
Improvement: how the whole thing gets better over time. The flywheel: a failure becomes a fixture, the fixture fails red, you fix it green, and now that failure can never silently come back. You externalize improvement so progress compounds instead of evaporating.
The honest line on what's built
The honest split matters here, because the gap between runnable and pattern is where this kind of thing usually oversells. The guard dispatcher runs today, allow and deny dispatch confirmed, fails closed. The eval loop runs: rubric, scorer, harness, a synthetic fixture it correctly catches, with the model call left as a clearly-marked stub for you to wire up. The shared state spine runs, with a green smoke test. The rest (the memory conventions, the improvement flywheel, the routing tables) ships as documented patterns and extension points, not turnkey systems. It's a reference, not a product, and it says so.
One deliberate choice runs through all of it: no vendor model names anywhere. The routing tiers are just fast, standard, and deep, with a note on how to map them to whatever you're using. The idea is supposed to outlive any particular model, because that's the entire point: the model is the part you swap.
Why I find this freeing
The usual instinct, when an agent disappoints you, is to reach for a bigger model. Sometimes that's right. But most of the time the leverage is somewhere cheaper and more permanent: a guard you write once and never re-litigate, an eval that catches the regression you'd otherwise ship, a memory file that means you never re-explain your conventions. You don't level up your agent by renting more intelligence. You level it up by building a better world for it to work in.
Intelligence is the utility you pay for by the token; the durable asset is the machinery you own around it. This extract is just that belief, made into something you can clone and run.