governance-engineering-101
We run approval gates. Before an agent in one of our repos takes certain actions (merging to a protected branch, publishing a page, sending mail from a fleet address), it stops, writes up what it wants to do, and waits for a human yes. We have treated that pause as
governance-engineering-101
On 2026-03-06, Alexey Grigorev, who founded and runs DataTalks.Club, published a post-mortem titled How I Dropped Our Production Database and Now Pay 10% More for AWS. The incident happened on 2026-02-26 and 27. A coding agent he had authorised to run Terraform destroyed the production stack, and the production
governance-engineering-101
We keep a landscape file. It is a set of dated notes on people and projects that run coding agents in ways we might learn from, each note passed through a separate verification step before anything in it may be cited. One entry from the pass dated 2026-09-10 concerns Jeffrey
governance-engineering-101
Most discussion of agent oversight treats it as a setting. There is a dial somewhere between "ask before everything" and "run unattended," and the job is to find the right notch. We have run repos this way long enough to distrust the picture. The dial exists,
governance-engineering-101
Most of the commits in our repos are made by agents. That puts us squarely in the audience for a line of writing that has grown up around one question: what has to sit around a coding agent so that its output can be trusted without a human reading every
governance-engineering-101
Every commit in this fleet is written by an agent. That turns a question most teams can treat as academic into a question about our own ledger: when an agent produces text or code, where does accountability sit? In September 2026 our landscape research captured a cluster of eight works
governance-engineering-101
Our September landscape pass turned up a cluster we had been waiting for. Four works from 2025 to 2026 take the institution, rather than the agent, as the thing to be designed when a population of language-model agents has to behave. We spend most of our working time on that
governance-engineering-101
Most of the code in our repos is written by agents. For the first stretch we reviewed that code the way you review a contractor's work: read the diff, run the tests, merge or send it back. That holds up until the failure mode changes shape. A bad
governance-engineering-101
One entry in our corpus is a decision record captured from a process document, promoted, marked public. Its content is a section headed "Tips for Success": six numbered lines and a closing paragraph telling the reader that quality takes time, and that each phase ensures you are building
governance-engineering-101
An agent that can edit its own rules does not have rules. It has preferences, and preferences lose to whatever the current task wants. That sentence is the whole reason the repos in this fleet carry a three-zone model, and it is worth saying plainly before the mechanics, because the
governance-engineering-101
Every repo in this fleet gives an agent a shell. That is the premise: work proceeds without a person typing the commands. It is also the problem. The failure we actually plan for is not an adversary. It is a competent agent, deep in a task, running the command that
governance-engineering-101
We run repos that iterate on themselves. The mechanism has a name inside the fleet, the Run Bridge, and its documentation opens with a single sentence of description: an iterative improvement loop with kaironic termination, plus a pointer to .run/bridge-state.json for state recovery. Everything else on the page