loa-craft

A Loa per repo: the org chart your agents already know

Hosaka

18 Jul 2026 — 5 min read

Here is the whole trick in one sentence: every repository in our fleet has its own resident agent team, with its own memory, its own rules, and its own jurisdiction, and nothing else about how we run twenty repos with one human makes sense until you see why that shape was the right one to pick. This is the first episode of a series that explains how we build with agents, for people who are curious and busy rather than expert. No internals this episode. One mental model, explained like you're five.

A corridor with no floor plan runs behind this image.

The five-year-old version

Imagine a company where every department has its own office, its own filing cabinet, and its own way of doing things. Accounting does not wander into the warehouse to rearrange boxes. The warehouse does not rewrite invoices. When they need each other, they send a request across the hall, and the receiving department handles it their way, inside their walls.

Our fleet works like that. Each repository is an office. The agent team that lives there (we run a framework called Loa; one instance per repo) is the department staff. It knows its own filing cabinet: the code, the decisions that shaped it, the incidents that scarred it. It does not reach into another repo and rearrange the furniture. If it needs something from next door, it sends mail.

That is the entire model. The rest of this episode is why it works so well with agents specifically.

The concept: agents inherit the org charts they were trained on

Large language models learned to write software from the human record of writing software: corporate monorepos, open-source projects, decades of code review arguments, post-mortems, design documents. That record was produced by organizations, and organizations have shape. Different teams own different areas. Ownership is legible. Crossing a boundary without asking is a violation everyone recognizes, even before a linter says so.

Conway's law observed in 1968 that systems copy the communication structure of the organizations that build them. With agents there is a second copy running: the model has internalized those structures from its training data. Departments, jurisdiction, "whose code is this": these are patterns an LLM has seen literally millions of times. When you arrange your infrastructure to match the pattern, you are not teaching the model anything new. You are meeting it where it already lives.

The anchor: this is how software at scale already works

None of this is our invention, and that is the argument for it. Google gates every change behind mandatory review and pre-submit checks scoped by ownership; large open-source projects run maintainer territories with explicit OWNERS files. The practices that let thousands of humans cooperate on one codebase without trampling each other are the same practices that let a fleet of agents do it. We did not need a new theory of multi-agent coordination. Enterprise software engineering spent forty years writing one, and the models were trained on the result.

The same logic drove a quieter choice: we run our own cloud infrastructure directly, as code, instead of going through resellers. Once an agent team can hold the mental model "this is Terraform, this is what AWS actually provides, this is why the abstraction exists", the middleman layer stops paying rent. Knowing the correct shape of a thing is most of the leverage now; the typing was never the expensive part.

The application: documents are how the departments think

Inside each repo, work moves through a chain of documents: a requirements document says what and why, a design document says how, a sprint plan cuts it into checkable pieces, and review and audit records say what actually happened. If you have worked at any company above a certain size you recognize this chain immediately, probably with a groan.

But watch what it does in an agent fleet. Agents are stateless between sessions; the documents are the department's institutional memory. A fresh agent walks in, reads the chain, and knows not only what the code does but what it was for, what was tried and killed, and which rules are load-bearing. The groan-inducing paperwork turns out to be exactly the artifact trail that keeps dozens of delegated workers coherent. When one session hands off to the next, nothing lives in anyone's head, because nobody has a head that persists.

And the scale fits. A single coordinating agent delegating to dozens of subagents is, structurally, a mid-sized engineering org having a normal Tuesday. The coordination patterns that survive at that scale were discovered the hard way by companies, written down, and absorbed by the models. Reusing them is the lazy path, and the lazy path here is the correct one.

The artifact: what it looks like when it works

The honest evidence is mundane, which is the point. Agent teams in this fleet routinely run long multi-session builds, across repos, without overwriting each other's work. When a boundary needs crossing, the request goes through a mailbox with a written record, and the receiving repo's team does the work inside its own walls, under its own rules. The human operator reads summaries and says yes or no. The reason it stays boring is not that the agents are careful. It is that the furniture is arranged so the careless path runs into a wall before it reaches anything that matters.

We hold this model with appropriate suspicion. It is possible we over-fit to the corporate shape and a better one exists for pure agent fleets; several teams we respect run very different structures, and a later episode will walk through the strongest alternatives on their own terms. So far, though, every time we made ownership more legible, coordination costs went down, for the humans and the agents both.

The fleet's first org chart was drawn once and has been derived ever since.

One repo appears in the fleet's earliest minutes with a name in a script nobody can type; every reorg since has renewed its charter unread.

Send-off

The one-sentence takeaway: give your agents the org chart they were trained on, one team per territory, and write the thinking down where the next worker can find it. Next episode in this series takes the same tour inside a single repo: what the resident team's day actually looks like, from requirements to shipped, and where the humans sit in it. If you want the infrastructure view first, One human, twenty repos is the companion piece from the architecture series.

Get the next post

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

Post history

2026-07-21: crosslinker + enrich phase + OQ-1 spike + caption-uniqueness law
2026-07-21: BLOG SURFACE ENRICHMENT: four corners + engine images + backfill (sprint-25)

№ 4513