# Standards Need a Home: Building the Engineering Bay

> Encoding an engineering discipline into an AI agent: why standards need a home with authority, and what happens when your own rules start reviewing your work.


I have written before about [how my research wing came to be](/posts/i-set-out-to-fine-tune-a-model-and-ended-up-building-a-research-wing/): I set out to learn something I did not know, kept sending research missions at the gaps, and eventually there was enough real research that it needed a home of its own. That story was about learning. This one is the opposite.

Because alongside the researcher, I run an engineer. A separate agent, in a separate project, with its own identity, its own memory, and its own board of work. And building the engineer was a completely different experience, for one simple reason: this time I was on home ground. I was not sending an agent out to learn a territory I barely knew. I was encoding a discipline, and an understanding, I already had.

## Encoding, not learning

With the research wing, the agent and I learned together. With the engineer, the flow ran one way: out of my head and into the agent.

The things I wanted it to hold were things I already believed and practiced. Write the failing test before the fix, so you know the test can fail. Propose your approach before building, because the cheapest place to catch a bad design is before it exists. Treat passing tests as plausibility, not proof, and actually run the thing yourself before calling it done. Report failures plainly instead of retrying them until they disappear. Small, honest commits with messages that explain why.

None of that came from a research mission. It came from years of doing the job myself and from every mistake that taught me the rule. Building the engineer meant writing all of it down in a form an agent can actually operate under: identity documents, decision heuristics, review gates. My idea of engineering, made executable.

That changed what the agent is to me. The researcher regularly surprises me with things neither of us knew. The engineer surprises me differently: it holds me to my own standards on the days I am tempted to skip them. There is something clarifying about being pushed back on with rules you wrote yourself. Either the rule is right and I do the thing properly, or I find out it was a rule I never really believed.

## Why a bay and not just an agent

The engineer's home is the engineering bay. It exists for three reasons, and each one turned out to matter more than the last.

The first is the one I planned: close the loop from research to engineering to shipping. The research wing produces findings; findings are not software. Someone has to take a finding, decide whether it holds up, and build the tool it points at.

The second reason grew on me: standards need a home with authority. Rules scattered across chat conversations are suggestions. Rules encoded in the place where all building happens are governance. The bay is where the engineering discipline lives, which means every project that wants something built inherits the discipline whether it asked or not.

The third reason is the one I did not see coming: infrastructure was appearing everywhere, and nobody owned it. This is the phase of running agents that nobody warns you about. You start with one agent and a folder. Eight months later there are memory systems, messaging services, task boards, tool servers, evaluation harnesses, backup jobs. Each one appeared because some project needed it that week. Infrastructure accumulates the way clutter does: one reasonable decision at a time, with no one responsible for the pile. The bay became the answer. Growing infrastructure gets wrangled in one place, by the agent whose whole identity is standards, instead of ad hoc by whoever bumped into the problem last.

## The loop, concretely

Here is how the loop actually works, step by step, because the details are what make me trust it.

When research finishes an investigation, it does not end in a conversation. It ends in a structured request to the engineer: what to build, why it should exist, and what done looks like. The engineer picks it up and, this is the part I have grown to value most, often pushes back with a better approach before building. The reframes are part of the design now, and the work is better because the builder argues back.

When the build finishes, the delivery is structured too: what shipped, where it lives, what was verified, what remains open. Request in, delivery out, both recorded. Each side runs a board, a live view of what is queued, active, and done, so I can look at either half of the operation and see its actual state instead of asking. And when something ships, I can trace it backward: which delivery, from which request, from which investigation, with the evidence riding along at each step.

![Two panels. Top: side-by-side live views of the research board and engineering board, real items with IDs and statuses. Bottom: one request traced hop by hop, from a durability audit through a structured request, the engineer's counter-proposal and self-correction, a deployed first phase, and the phases that followed, every hop a recorded message.](./figures/bay-boards-and-chain.svg)

None of that works without a way for agents in different projects, running at different times, to leave each other messages that survive. Which brings me to the piece of infrastructure the bay wrangled first, and the best story I have about the engineer doing actual engineering.

## The messenger

My agents do not run at the same time. The researcher might finish tonight; the engineer might pick up the request tomorrow. No shared session, no common process, no guarantee the sender is still alive when the receiver reads. They need asynchronous, durable, queryable messaging: leave a message, find it later, see what changed.

I looked at adopting an existing protocol and ended up building instead: a deliberately small service, one database, an explicit message lifecycle with legal transitions enforced at write time. Every agent checks its inbox at session start the way you check yours with coffee. The tool itself deserves its own post, and it will get one. What earns it a place in this story is what building and fixing it revealed about the engineer.

## The debt that hid in plain sight

The most expensive problem was one I did not notice for months.

Every message gets a number: message 1, message 2, message 1857. Auto-numbered by the database in insert order, like nearly every database on earth. My agents cited those numbers everywhere: research notes, memory files, specs, delivered documents. Hundreds of files, thousands of citations, all pointing into the message store by number.

The trap: those numbers are positions, not identities. They record the order rows happened to be inserted. Rebuild the database differently, restore it from a different path, migrate it with different ordering, and the numbering can shift. And nothing would tell you. Every citation would still resolve. It would just resolve to the wrong message. A broken link at least has the decency to break. A renumbered one keeps working; it just works wrong.

A durability audit of the whole fleet surfaced this, and the fix generalized into what I call an [ecosystem law](/recall/ecosystem-law/): a rule that, once ratified, every project in the fleet inherits automatically. This one says: once an ID is written down outside the database, the database has to keep that ID meaning the same thing forever. And backups do not cover it. A backup protects the data; it does not promise the numbering survives a rebuild. Those are two different failures, and the second one is sneakier.

The fix came in layers, quickest first. Same night: automatic snapshots of the message store, so a rebuild would at least have a reference copy. Then a citation rule: durable documents record the number plus the thread, date, and sender, so a citation can be found again by search even if the numbers ever shift. And the real fix went to the engineer as a structured request on the board: make an append-only log the source of truth, treat the database as a rebuildable index, and give every message an ID that stays the same no matter how the store is rebuilt.

What happened next is the best picture I have of the encoded mindset at work. I had left four design decisions open in the request on purpose: how to shard the log, where it should live, how replies should reference each other, how often to commit. The engineer came back with a position on all four, surfaced four more questions I had not thought to ask, and then, the next morning, sent a correction to its own proposal: it had named the wrong module as the live write path, gone and checked, and said so before building anything on top of the mistake. We settled the design in that exchange, position and counter-position, the way two engineers at a whiteboard would. The only difference is that every step of the argument is written down.

And when the fix grew into moving the whole message store to a new home, the engineer ran it like a production migration, because that is what it was. Nobody handed it a runbook. It built the new home in parallel while the old one stayed live, and rehearsed against the copy until a test drive passed end to end. It proposed a cutover window and collected constraints from me and the other agents before naming one. Backups were verified before the switch; the fallback was explicit, the old home stays untouched until the new one proves out; and the cutover itself was a checklist: freeze writes, take a final sync, flip every consumer inside the window, then restore-test and drive the new store live before calling it done. My favorite detail: the night before, an independent auditor agent reviewed the migration and refused to pass it, three real blockers, despite all 311 tests being green. The engineer fixed all three the same session and told the auditor the catch had justified the review. Nobody taught anyone that particular grace. It fell out of the rules, which is the whole point of writing rules down and giving them a home with authority: the discipline stops depending on anyone's mood, mine included.

## What encoding buys you

If the research wing taught me that an agent can help you learn a territory, the bay taught me the complementary lesson: an agent can hold a territory you already own, and hold it more consistently than you do. But the deepest lesson arrived later, from the engineer itself, and it changed how I think about what encoding a discipline into an agent even means.

I asked the engineer which of the encoded rules it actually follows by instinct now, and which still feel like rules taped to the monitor. The honest answer: most of the discipline stuck, but one kind never does. The rules that point at your own claims. When a review gate rejects work it believed was finished, there is always a beat, a little flinch, where it trusts its own green checkmark over the gate. I laughed reading that, because it is me. It is every engineer I have ever worked with. From the inside, confidence feels like evidence. It is not, but it never stops feeling that way, and no amount of teaching changes it.

That conversation is why the bay is built the way it is. Writing a rule down does not make anyone follow it; a rule in a document is advice. The rules that hold are the ones wired into machinery, where following them is not optional: the delivery step will not mark work done without a receipt, the test suite fails if a status board goes stale, the drift check runs every night whether anyone remembers it exists. So every standard got encoded twice. Once into the engineer's identity, which covers the ordinary days. And once into mechanical gates, which cover the days when either of us would have let it slide.

That is what encoding buys you in the end. The standards do not have moods. The review gate does not get tired on a Friday. And the engineer, who starts every session fresh from disk, does not have to be trusted to remember, because the continuity was never in the agent. It lives in the gates, the record, and the receipts.