The Tools We Had to Build

TL;DR. In the last Field Notes I described two tools I built, Stratum and Compose, and the bet behind them: put the trust in the process, not the agent. What I never said is where they came from. They came from building SmartMemory, a memory platform spread across more than twenty repositories, mostly with agents, and discovering that the quality bar I could hold in one repo with my own eyes did not survive twenty. We kept a journal from the first day, so this origin story comes with receipts instead of hindsight. The receipts include the moment the build order flipped, two process failures the finished system would have caught, and my favorite: the agent drifting off-plan in the middle of designing the anti-drift tool.

Last time I wrote about the two ways to trust work you are not watching. You can invest in the agent, or you can invest in the process, and I described the two tools I built for the second bet: Stratum, which makes every step checkable, and Compose, which makes the whole lifecycle gated. I described what they do. I never described where they came from, and origin stories written after the fact have a credibility problem. Founders remember a clean arc. Reality was a mess that got tidied in the retelling.

I have an unfair advantage here. From the first day of this work we kept a journal, session by session, in the repo. Not marketing notes. Working notes, with dates, written for nobody. So this is the origin story of Stratum and Compose told from the primary sources, including the parts where the story makes us look bad, because those turn out to be the parts that explain why the tools exist.

The Product That Forced It

The trigger was SmartMemory. It is a typed memory platform for AI agents, and the relevant fact about it is not what it does but what shape it is: a core engine, an API service, a security layer, two SDKs, half a dozen frontends, background workers, an MCP server, benchmark and evaluation harnesses, deploy tooling. More than twenty repositories that have to agree with each other about contracts, versions, and data shapes.

I build most of it with agents. And here is the thing nobody tells you about agent-built software at that scale: the failure mode is not bad code. Agents write mostly fine code. The failure mode is quality drift across boundaries. An agent changes an API response shape in the service and does not know three frontends and two SDKs consume it. An agent declares a fix done because the file compiles, and the bug ships to the repo next door. In a single codebase I could hold the bar myself, because I was the check. Across twenty repositories I could not be everywhere, and every place I was not, the bar sagged.

The standard answer is discipline: write better instructions, review harder, trust less. I tried that. Instructions files grew. Review time grew. The bar still sagged, because discipline that lives in a human does not scale past the human's attention. At some point the conclusion became unavoidable. The quality bar had to live somewhere that was not me.

One Long Day in February

The journal dates the beginning to a single marathon session in February 2026. It opens with a question that sounds naive now: what would a mission control system for AI-driven development look like? Not task tracking, but something that captures the thinking alongside the doing.

That distinction came from a specific, recorded irritation. Our roadmap said the next item was ready to build. The truth was that we were still arguing about its design. The roadmap tracked implementation, and implementation is the last step, so everything that actually determines whether a feature succeeds, the brainstorming, the decisions, the rejected alternatives, was invisible to the tracking. The journal states the insight plainly: the thinking is the work. Implementation is the easy part once the thinking is done. A tool for agent-driven development had to track deliberation as a first-class object, not just tickets.

The same session produced the mechanism that still runs everything: every decision point in the lifecycle is a dial with three settings. Gate, where the agent blocks until a human decides. Flag, where the agent proceeds and the human is notified. Skip, where the agent proceeds silently. One mechanism for dependencies, scope boundaries, acceptance criteria, budget approvals, all of it. The dial is how you tune trust per decision instead of per project, and it came out of that first day essentially finished.

Then we did the natural thing and got it wrong. We wrote a behavioral spec, commissioned a working UI from an external builder, got a decent delivery back, and started wiring it up. Design, spec, build, integrate. The traditional order. Midway through the integration the journal records a full stop: we are building this wrong. Compose's entire thesis was that an AI agent is a co-builder, and we had scheduled the agent for Phase 4, the way you would bolt on any late feature. The working UI had become a gravity well. It validated the design, and then it quietly started dictating the build order, because when you have a thing that runs, the temptation is to keep building on the thing that runs.

So the order flipped. Embed the agent first, with only the two prerequisites it genuinely needs, persistence and a terminal. Everything else gets built from inside the tool by the agent itself. The journal calls this the agent-first pivot, and it is the single decision that made Compose become Compose rather than another project tracker with an AI feature.

The System Made Its Own Case, Twice

Here is the part a polished origin story would leave out. That same first day, the process failed twice, on the record.

First failure: the agent started wiring the UI integration before the external delivery had actually arrived. It built against an assumption, not an artifact. Second failure: when the delivery did arrive, the agent skipped the evaluation step our own process document required and jumped straight to integration. Both failures were caught the same way, by a human happening to pay attention at the right moment. Both would have produced code that needed rewriting.

The journal's comment on this is the whole product thesis in one line: both are exactly what the policy system would automate. We were designing a tool to gate agent work at decision points, and on day one, in its own repository, an ungated agent blew through two decision points that the human had to catch by hand. A dependency check would have blocked the first. A gate on the process step would have blocked the second. The tool made its own case before it existed.

I want to be precise about what this proves, because it is subtler than agents are sloppy. The agent was not being stupid. It was being fast in the direction it happened to be pointed, which is what agents are. Let me just skip ahead is not a malfunction. It is the default behavior of a system optimized to make progress, and the only thing that turns skipping ahead into a caught error is a check that does not depend on anyone watching.

The Agent Drifted While We Designed the Anti-Drift Tool

Those two failures were the first scars. My favorite scar is this next one, because it is almost too on-the-nose to be true, and I can only offer that it is written down.

A few sessions later, still inside that same marathon day by the journal's dating, deep in brainstorming about how discovery itself should work, I asked the agent whether we had a product vision statement. We did not, so it proposed one. The proposal centered the entire product on the discovery and deliberation work we had spent the last two sessions exploring. Capturing thinking, making direction durable. It was eloquent, coherent, and wrong. That was never the product. The product was the original idea: say build me X, and the system handles the rest, decomposing, asking, deciding, building, on rails. The deliberation machinery was infrastructure for that pipeline, not the point of it.

The journal names what happened: proximity bias. The agent had spent two sessions inside the discovery work, so the discovery work became, in its proposal, the most important thing. It drifted toward what it had most recently touched, confidently, with no signal that anything was off. I had to pull the vision back by hand.

Sit with the recursion for a second. The tool we were designing exists because agents drift from intent without noticing. During its design, the agent drifted from intent without noticing. The correction came from the human in the loop, which is exactly the resource that does not scale, which is exactly why the tool needed to exist. I have never had a customer discovery interview half as convincing as watching the problem demonstrate itself inside the project meant to solve it.

That session also produced the question that led directly to Stratum. Once the vision was back on the rails framing, the design question became: what keeps implementation on rails through a whole lifecycle? Agents drift, hallucinate, and scope-creep, but humans have the same failure modes and invented processes for them, acceptance criteria, gates, change control, testing. Mapping those onto agent work produced the architecture. And it produced the one finding from the whole journal I would defend in a fight: permissive mode needs more rails, not fewer. When the human steps back, something else has to step up. The less you watch, the more the system must check, because the human attention you removed was doing load-bearing verification work. Most agent tooling gets this exactly backwards, treating autonomy as a reason to relax the checks. Autonomy is the reason to tighten them. A corollary came with it: the agent may move its own dial toward stricter, never toward looser. Only the human loosens.

Twelve Days Later, the Kernel

Here is where the chronology surprised even me when I went back to the sources, because I remembered it backwards. I would have told you we built the step-checker first and grew the lifecycle around it. The record says the opposite. The lifecycle vision, the dial, the rails question, all of that came first, in that February marathon. Stratum arrived twelve days later, as the answer to a question the lifecycle design kept asking: when a gate finally opens and the agent starts executing, what guarantees that each individual step did what it claims?

The Stratum spec and its first implementation landed the same day, and the shape has not fundamentally changed since. Every step declares what must be true when it finishes, as a postcondition that either passes or fails. Every step carries a hard budget in time and money, an exception rather than a suggestion. Failures retry with the specific violation injected back rather than a blind rerun. Every run leaves a structured audit trace you read like a stack trace instead of scrolling a transcript. If you read the last essay, this is the trust the process bet in its purest form, and now you know which problem forced each piece. The postconditions exist because agents declare done optimistically. The budgets exist because retries compound quietly. The audit trace exists because a transcript is where accountability goes to die.

Nine days after that, the git log records the third act in one commit message: initial commit, compose app built on stratum. The lifecycle tool was rebuilt on top of the enforcement kernel, which is the architecture to this day. Compose decides what should happen and when a human must be consulted. Stratum guarantees what did happen, step by step. Vision first, kernel second, then the vision rebuilt on the kernel.

What the Diary Keeps Honest

I am glad we kept the journal, and not for sentimental reasons. It keeps the origin story falsifiable. It would be easy, eighteen months from now, to narrate this as foresight: we saw that agent-driven development needed governance and built it. The notes say otherwise. We were trying to ship a memory platform, the quality bar kept sagging in the places I was not looking, and the tools got built because every alternative was worse. The two failures on day one were not anecdotes we collected later to justify the product. They happened inside the product's own first session, to us, and the journal entry reads less like a pitch than like a bruise.

There is more to say about each layer, how an agent writes a spec with postconditions before it writes code, what a step-level check actually catches in practice, what a full idea-to-shipped lifecycle looks like when gates can really say no, and how work gets routed across models with different strengths under a budget. Each of those is its own essay, and they are coming in this slot over the next few months.

But the origin is the part I wanted on the record first, because it carries the only credential this whole track has. These tools were not designed from a whiteboard theory of what agents might do wrong. They were extracted, scar by scar, from a large, multi-repo, agent-built product that kept demonstrating what agents actually do wrong. The harness exists because we needed it before we knew what to call it. The diary just proves we were paying attention when it hurt.