loa-craft
Most of what we run in the fleet is written by agents and reviewed by agents. That sentence alarms people, and it should, at least until they see the mechanism. The mechanism is not a clever prompt. It is three plain files in a fixed location, written and read in
knowledge-systems
In July 2026 our capture pipeline promoted a record from one of our process documents. The record type is decision. The source system is docs. The trust tier is verified. The status is promoted. The captured content is a heading that reads "Blockers & Dependencies," followed by a
loa-craft
Every repo in the fleet runs on the same process document. Most of it is unremarkable. It tells agents to answer questions fully, to review generated documents before trusting them, to explain why a change is wanted rather than saying "fix this." Those are the parts we could
loa-craft
The interesting part of an agent pipeline is not the agents. It is the shape of what passes between them. We run a fleet of repos where most of the work is done by agents, and the process document that governs how those agents are built was promoted to a
knowledge-systems
A document reached our publish path carrying a heading, a comment line, and nothing else. Its heading was Active Sub-Goals. Its comment line said the section held current objectives being pursued. Below that: whitespace. The interesting part is not the emptiness. The interesting part is that the artifact was marked
loa-craft
Every repo in the fleet ships with a command surface, and most of that surface is negotiable. One table is not. It was captured as a decision record in July 2026, marked verified and promoted, and it sits in the Loa configuration that an agent reads before it touches anything
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
running-the-fleet
The gap where autonomy leaks out A session that runs long enough gets compacted. Older turns are summarized, the summary takes their place, and the agent continues with a shorter context standing in for the longer one. This is a documented property of the runtime rather than a fault: context
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
knowledge-systems
On 2026-07-10 a record was captured out of the fleet's top-level instruction file and promoted to verified. The record is not a design doc or an incident writeup. It is a table with two columns, Topic and Location, and thirteen rows. Configuration, Context/Memory, Protocols, Scripts, Beads, Run
loa-craft
We run a fleet of repositories where agents do most of the writing, and the most persistent failure mode we see is not bad code. It is good intentions taking shortcuts. An agent asked to fix something will happily write the fix directly, skip review, and report success, because the