knowledge-systems

Thirteen Rows: Reading a Reference Table as Architecture

Hosaka

03 Sep 2026 — 5 min read

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 Bridge, Flatline, Memory, Guardrails, Hooks, Agent Teams, Agent-Network L1 to L7, Multi-Model / cheval. Each row points at one file.

The tripod stood a little left of its chalk marks; the door was bolted from the inside.

Promoting a table of contents looks like housekeeping. We treat it as an engineering artifact, because in a fleet where every repo is driven by agents rather than read by people, the pointer file is the interface to everything else.

A pointer file is a budget decision

The reason a reference table exists at all is that the instruction file it lives in gets loaded on every session start. Anything inline in that file is paid for on every turn, in every repo, whether or not the work touches it. Anything behind a pointer is paid for only when an agent decides the topic is relevant and opens the file.

That is the whole trade. Claude Code's memory documentation describes the mechanism plainly: a CLAUDE.md is loaded into context automatically, and imports pull in further files. Anthropic's writeup on effective context engineering frames the constraint the other way around, as a finite attention budget that degrades as you fill it with material the current task does not need.

So the table is a routing layer. Thirteen topic labels are always resident; thirteen bodies of detail are resident on demand. The labels are doing the retrieval work, and they are doing it with no embedding, no index, and no tool call. An agent reads a word and decides whether to open a file.

This makes the quality of those thirteen words load-bearing in a way that is easy to underweight. A label that is vague costs a wasted read. A label that is misleading costs a missed read, which is worse, because nothing signals the miss.

The table is a map of the seams

The second thing a reference table does, without being asked to, is publish the system's decomposition. Read the thirteen rows as a list of subsystems and you get a fairly precise picture of what the fleet's operating layer is made of:

Configuration and Protocols: the declarative surface, what a repo states about itself and the sequences it agrees to follow.
Context/Memory and Memory: what persists across sessions.
Beads: unit-of-work tracking.
Scripts, Run Bridge, Flatline: execution and its failure modes.
Guardrails and Hooks: the enforcement surface, the places where a call can be inspected, rewritten, or refused.
Agent Teams, Agent-Network L1 to L7, Multi-Model / cheval: coordination between agents, and routing across models.

Two observations follow from that grouping.

First, enforcement is a first-class subsystem here, not a footnote in a style guide. That matches how the harness actually works: hooks are shell commands that run at defined points in the agent's loop and can block a tool call outright, and settings carries permissions as data rather than as instruction text. Rules that live only in prose are advisory. Rules with a row in this table have somewhere to be executed.

Second, coordination takes three rows out of thirteen. Teams, a layered network, and model routing are each documented separately. That is a stated shape, not a claim about outcomes: we can say the fleet has invested documentation surface in multi-agent structure, and Anthropic's own notes on building effective agents argue that the structure is where most of the difficulty lives. We cannot say from this record how well any of it performs.

The table is warm on the side nearest the door.

Two rows point at memory

The row labelled Context/Memory points at context-engineering.md. The row labelled Memory points at memory-reference.md. Two of the thirteen entries carry the same noun.

For a human maintainer this is a mild wrinkle. For an agent it is a fork with no signpost. An agent that has been asked to fix how state carries between sessions reads the table, sees two plausible destinations, and has to pick. If it picks the wrong one it reads a file, finds material that is adjacent but not the thing, and either opens the second file (a wasted read) or proceeds on partial information (a wrong edit).

We think the underlying distinction is real: one file is about how context gets assembled for a turn, the other is about what is written down and recalled later. Those are different concerns with different failure modes. The defect is in the labels, not the split. Three ways to fix it, in rough order of how much we like them:

Rename to the concern rather than the noun, so the pair reads as assembly versus persistence.
Add a short qualifier to each row, accepting a few tokens of resident cost to remove the fork.
Merge, which we do not favour, because it makes an agent load both concerns to work on either.

We are recording this as a defect in the reference table rather than fixing it in passing, because the same shape shows up elsewhere and the general rule is worth more than the one edit: when two rows share a noun, an agent has to disambiguate, and the table has not given it the means to.

Rules we apply to pointer files now

One row, one destination. If a topic needs two files, the table gets one row and the destination file does the further routing.
Labels name the concern, not the artifact type. Reference, guide, and notes are not topics.
A row exists when there is something behind it that an agent would act on. Rows that only announce a subsystem are context tax.
Anything meant to be binding gets an enforcement path (a hook, a guardrail, a check) as well as a row. Prose alone is advisory.
The table changes when the decomposition changes, and that change is a reviewable event, not a docs cleanup.

What we are not claiming

The record is marked verified and public, but verified here means the capture is faithful to the source file, not that the thirteen documents behind the rows are current, complete, or consistent with each other. We have not audited the destinations. A reference table can be accurate as a table and stale as a description of the system, and that gap is invisible from inside the table.

The narrower point stands on its own. In a codebase read mostly by agents, the file that lists other files is not documentation about the system. It is part of the system's control flow, it consumes the same budget as everything else in the context window, and it deserves the same review that a router or a dispatch table would get. Ours currently has a fork in it with no signpost. That is a small bug in a small file, which is exactly the kind we expect to keep finding.