fleet-architecture
We run a fleet of agent-operated repositories, and several of our consumers need more than one model to do their jobs. Bounty Board reviews, Flatline checks, red-team passes, adversarial review, post-PR triage: each of these asks multiple models to look at the same work and disagree productively. For a while,
loa-craft
A code review that nothing consumes is a log file with better manners. For a while, that was the honest description of our Bridgebuilder phase: a multi-model reviewer that ran against a finished pull request, produced findings, and then watched most of those findings evaporate, because nothing downstream was obligated
running-the-fleet
In a fleet of agent-run repositories, the merge to main is the last point where judgment is exercised. Someone, or some agent acting under review, decided the change was correct and let it land. Everything that happens after that decision is clerical: figure out what kind of change it was,
loa-craft
Every long-running agent session in the fleet eventually meets the same wall: the context window fills, and the harness compacts. The transcript that held the working state, the task in progress, the files already touched, the decisions already made, gets summarized down to a fraction of itself. Summaries are good
knowledge-systems
An agent that forgets everything between sessions relearns the same lessons at full price, every day, forever paying tuition on a course it has already passed. An agent that remembers everything indiscriminately has a different problem: a memory full of half-true, unowned, undated notes that contradict each other, where recall
loa-craft
At the top of the Loa configuration in each of our repos sits a short section titled Key Protocols. It is three lines long. One line establishes memory, one establishes the order in which feedback is consumed, and one establishes git safety. In July 2026 we promoted this section from
loa-craft
We operate a fleet of repositories where agents write most of the code. The failure mode we fight most often is not wrong code. It is extra code: the speculative flag, the abstraction with one caller, the error handler for a state the system cannot reach. A human engineer gets
knowledge-systems
In July 2026 we promoted a decision into the fleet's canon: learning from skill execution happens invisibly, while the skill runs, with no scheduled review and no ceremony. A learning is either detected in the moment and passed through four quality gates, or it is not kept at
loa-craft
Every repository in our fleet runs on Loa, the operating layer of slash commands that carries a project from first idea to deployed artifact. Loa grew the way most command surfaces grow: one honest, specific name per phase of work. Planning got /plan-and-analyze, then /architect, then /sprint-plan. Implementation got /implement.
governance-engineering-101
Our agents do not read their inputs first. A pre-execution layer reads them first, and that layer has authority to stop the run before a single tool call is issued. The specification is short enough to fit in one line of our operating doc: PII filtering (blocking), injection detection (blocking)
loa-craft
One of our operating records is four words long in substance: prompts are automatically enhanced before skill execution, silently, and logged to the trajectory. It reads like an implementation note. It is closer to a constitutional question, because it decides who knows what the fleet was actually asked to do.
governance-engineering-101
The fleet is a small number of repositories where most of the writing is done by agents and most of the reading is not done by a human at all. That inverts the usual bottleneck. Producing a change is cheap. Deciding whether the change is allowed to land is the