The harness that ships: why completion is the moat

Agentic coding has a signature feeling, and the feeling is speed. Code appears, tests pass, a demo runs, and the session ends with the sensation of enormous ground covered. The tell that something is off is the tsunami of half-finished products the field is now drowning in: repositories that sprinted for a weekend and never reached anyone. Speed and completion turn out to be different quantities, and only one of them is a moat. This is the craft-level tour of Loa, the harness the fleet built to make long-running work finish. The plain-language version was the previous episode.

Subscribe free

Speed is not completion

The field is full of things that were fast to start and impossible to finish. An agent can scaffold a plausible product in an afternoon; the same agent, three weeks later, cannot tell you which of the afternoon's decisions were load-bearing, which were placeholders, and which quietly broke when the fourth feature landed. The work was never wrong, exactly. It was abandoned, because nobody, human or model, could hold the thread long enough to carry it to production.

The fleet treats this as the central problem, not a footnote. We build real products with agents, over runs that last months and cross many repositories, and the discipline that makes those runs finish is worth more than any trick that makes a single session faster. What follows is how that discipline is encoded. None of it is exotic. Most of it is borrowed, on purpose, from how large engineering organizations already kept thousands of people coherent across decades. (One thing up front: this is not a pitch to adopt the harness. It is an account of what we run ourselves.)

The ledger is how a long run keeps its place

Agents forget. Between sessions a coding agent starts from nothing, and a project that spans dozens of sessions has no memory of its own unless the memory lives outside the agent. Loa's answer is an internal ledger: a durable record of every unit of work, its state (ready, in progress, blocked, done), its dependencies, and the run that owns it. A session does not begin by guessing what to do next. It reads the ledger, finds the ready work, and picks up where the last session set the pen down.

This is the difference between a run that compounds and a run that wanders. Without a ledger, a long build degrades into re-litigation: each fresh agent re-discovers the same context, re-makes settled decisions, and drifts from the plan a little more. With one, the plan is a shared object that outlives every session that touches it. The same idea powers durable workflow engines and checkpointed pipelines everywhere; the wrinkle here is that the workers are stateless by nature, so the ledger is not an optimization. It is the one thing standing between an infinite production run and an abandoned repo.

Document-driven, so the evolution stays legible

Inside a Loa repo, work moves through a chain of documents before it becomes code: a requirements document, a design document, a sprint plan, then review and audit records of what happened. If you have worked anywhere above a certain size you recognize the chain, probably with a groan. Watch what it buys in an agent fleet.

Because the chain is committed alongside the code, the history of the system's own thinking is diffable. You can read not only what the code does today but why it looks the way it does, what the design assumed, where the plan was cut, and which review caught what. When a decision is revisited a season later, the revisit starts from the recorded reasoning instead of from someone's memory of a conversation that may never have happened. Version control was always about intent as much as text; document-driven development takes that seriously and puts the intent under the same microscope as the diff.

The archive keeps its dead ends

The most undervalued artifact in the fleet is the record of things that did not work. Loa keeps architecture decision records in the style Michael Nygard proposed in 2011: short, dated, immutable notes that capture a decision, its context, and its consequences. Alongside them sit registries of known failures and a shelf of killed approaches, each with the reason it was killed and, where it matters, the condition under which it would be worth reopening.

Writing down a dead end stops the fleet from paying for it twice. A team of forgetful agents is especially prone to re-walking a path that was already explored and rejected, because the rejection lived in a session that has since evaporated. A killed approach with a recorded reopen condition turns a lesson into an asset: the next planner meets the wall before running into it, and reconsiders the wall only when the stated condition actually changes. This is the instinct that makes aviation safe. The NTSB publishes every investigation as a permanent public record, and Google's blameless postmortem culture exists so an outage teaches the whole organization once rather than each team separately. A practice that records only its wins is condemned to keep rediscovering its losses.

The corpus hiding in the review threads

The richest vein of knowledge in a mature project is not in its documentation. It is in the argument: the review comments, the back-and-forth on a pull request, the anecdote someone drops to explain why a tempting shortcut is a trap. Those threads are where the reasoning actually lives, and in most organizations they are write-once and read-never, buried the moment the branch merges.

The fleet treats that discussion as a corpus to distill. The recurring lessons, the patterns that keep reappearing across reviews, the near-misses that never became incidents but taught something anyway: these get mined out of the review history and promoted into durable, citable form. A rule that emerged from a specific painful thread carries more weight, and survives longer, than a rule handed down from nowhere, because its provenance travels with it. The conversation that produced a decision is part of the decision.

Why the fleet builds its own tooling

There is a reason the fleet writes its own harness instead of assembling one from parts. The practices above only mature by being run against real, long-lived work, the kind that has a chance to rot. A harness dogfooded on toy demos stays a toy; one used to carry actual products from ideation through delivery and into iterative improvement gets bent, repeatedly, by the failure modes that surface only over months. Ours has been shaped that way over many cycles, and it keeps getting sharper because it keeps being used on the real thing.

That is the deeper claim, and it is a claim about the fleet rather than about the tool. We use our own designs and practices, recursively, to build our own enterprises: a system that produces itself and refines itself as it runs, in the sense the Chilean biologists Humberto Maturana and Francisco Varela called autopoietic. The harness that builds the products is built and refined by the same discipline it enforces. Speed is cheap and getting cheaper. The ability to start something enormous and still be shipping it, coherently, a season later is the rare thing, and it is the thing worth owning.

The oldest decision record cites a review that never convened; every audit initials it, files it back, and leaves the count unchanged.

Send-off

The one-sentence version: agentic velocity is a feeling, completion is a discipline, and the discipline is made of a ledger that remembers, documents that stay legible, and an archive that keeps its dead ends. For the plain-language tour of how one resident team per repository makes any of this run, start with the beginner's episode.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Read next

• The repo remembers: how agents build hosaka
• One human, twenty repos: how hosaka is architected
• How a Feature Ships When Your Engineers Are Agents

Post history

• 2026-07-21: crosslinker + enrich phase + OQ-1 spike + caption-uniqueness law

№ 2414