Introducing Code Reality Labs

For the last couple of years I have been fixing the same bug over and over. Not in one codebase. In the way AI agents work.

An agent is only ever as good as what it knows. Give a brilliant model the wrong picture of your system and it will hand you code that is confident, fluent, plausible, and wrong, and it will do it fast. The model was never the bottleneck. The bottleneck is context: what the agent believes about your code, your history, and your intent. When that belief is a guess, everything downstream is a guess too.

Code Reality Labs exists for one reason: to make the context AI runs on real. Correct, persistent, and something you can verify, not something you take on faith.

It started as irritation, not a business plan

I did not sit down to build five products. I wanted my own agents to stop guessing, and every time I removed one reason they guessed, the next reason underneath it became impossible to ignore.

It started with static analysis, because an agent that cannot see your real call graph, data flows, and framework boundaries is guessing about the code in front of it. That became TheAuditor. Analysis is only worth as much as its accuracy, though, and accuracy has to be proven rather than claimed, so BenchProctor grew up beside it to keep us honest.

Then the work ran into the client wrapping the model. The cost of wiring everything together, in tokens and in day-to-day usability, was simply too high, so Warden happened: a client that treats context as a budget instead of burning it. Separation of concerns did the rest. Memory did not belong inside the client, so Curator was born out of plain necessity, because perfect knowledge of today’s code is amnesiac by the next morning. And after one too many power cuts killed a long-running job with nothing to bring it back, Arbiter became necessary too: the supervisor that dispatches the work, routes it, and recovers it.

Five products. Each one earns its keep on its own, in its own domain. But look at the list and the through-line is obvious. I kept removing the reasons agents guess, and the reasons formed a stack.

One standard, five front doors

What makes these cohere is not a shared codebase or a forced bundle. It is a single question: what would an AI agent need if its context had to be correct, persistent, and actionable? Answer that honestly and you get exactly these five shapes.

That is why they live under one roof. Not so you have to buy all of them, because you do not, and you should not have to. Each is built to earn its place while standing completely alone. The roof is there so the standard behind them stays consistent: the same refusal to let an agent act on a guess.

BenchProctor is open under Apache-2.0 because the industry must be able to run and inspect the yardstick. TheAuditor, Curator, Arbiter, and Warden are proprietary products with public release channels. The measurement layer stays open because a benchmark you have to take on faith is not a benchmark.

What this blog is

This is the company’s voice, not a product’s. Here we write about the through-line: where the stack is going, the principles behind it, and how the pieces fit together. Each product keeps its own blog for the deep, specific work. This is the altitude above them.

We called it Code Reality Labs because that is the whole job, said plainly. Keep AI tied to the reality of your code, not its imagination.

Welcome. Let’s stop letting agents guess.

Code Reality Labs · Founder note