Five Layers, Two Shipping: Reading the Loa Stack from the Bottom
We keep one architecture document that explains how our agent-economy repos fit together. It is written as an ELI5 guide, and it includes a diagram and a table. This essay walks through that document the way we read it ourselves: from the bottom up, with attention to what exists today and what is still a plan. Our source is the ecosystem architecture note in the loa framework, captured into our knowledge base in July 2026 at a "reported" trust tier. Treat everything below as a snapshot from that capture. It is not a live status page.
The shape
The stack has five layers. Each one is a separate repository:
loa, the framework: agent development skills, workflows, quality gates, and Bridgebuilder.loa-hounfour, the protocol: schemas, state machines, and model routing contracts.loa-finn, the runtime: persistent sessions, a tool sandbox, and memory.loa-freeside, the platform: API, Discord and Telegram surfaces, token-gating, billing, and infrastructure as code.loa-dixie, the product: a dNFT oracle, and the first product customer of the layers beneath it.
The document states the governing rule in one sentence: each layer depends only on layers below it. It adds a second sentence that we think matters more: protocol contracts flow upward. Lower layers define contracts. Upper layers consume them.
The status column is also part of the architecture, so we will say it plainly. When the note was captured, two layers were marked shipping: loa and loa-hounfour (at v8.3.1). The other three (runtime, platform, product) were marked designed. The finished parts of the stack are its foundations. Everything above them is still a specification waiting for code.
Two kinds of "below"
The diagram draws two kinds of edges, and they are easy to confuse.
The solid edges are runtime or build dependencies. Dixie queries knowledge through Freeside's platform APIs, runs agent sessions on Finn, and validates types against Hounfour. Freeside routes agents to model pools on Finn and pulls in Hounfour as an npm dependency to validate its data. Finn enforces Hounfour's contracts, including budget limits.
The dashed edges all come from loa, and they mean something else. Loa is "mounted as dev framework" in every other repo. It isn't a library that the runtime calls. It is the set of instructions the agents follow while they build the runtime. The note calls it "the rules and tools every AI agent follows when building anything." So Loa sits at layer 1 because everything is built with it. Nothing executes through it.
This distinction is why we avoid calling Loa a dependency in the usual sense. If Loa disappeared tomorrow, a deployed Finn would keep running. Our ability to change Finn with any consistency would go instead. Loa governs how the fleet works. Hounfour governs what the software is.
The rule permits skipping
"Depends only on layers below" does not mean "depends only on the layer directly below." Dixie, at layer 5, reaches straight down to Hounfour at layer 2 to validate types, skipping both the platform and the runtime. Freeside does the same. We consider this correct.
A strictly adjacent stack would force every type check to go through intermediaries. Dixie would have to trust that Freeside had validated its data correctly, and Freeside would trust Finn. Each hop is a place where a schema can be restated slightly wrong. When every layer that handles a billing event or a session record validates it against the same protocol definitions, the definitions stay authoritative and the layers between stay thin.
The cost is that Hounfour has the most direct dependents of any runtime-relevant layer, so a breaking change there hits everything above it at once. That is the reason Hounfour is a versioned package and not a folder of shared types. The semantic versioning convention its version number follows is how upper layers learn whether an upgrade is safe to take.
Why the protocol has no running code
The document describes Hounfour as "a pure schema library, no running code, just definitions." It says what an agent session looks like, what a billing event looks like, and which fields a model request must carry. It compiles to JSON Schema so TypeScript, Python, Go, and Rust can all validate the same data.
We think the "no running code" constraint is the most important design decision in the stack. Hounfour also carries economic rules (the note's example is that budgets must always add up, which it calls conservation invariants) and governance rules about who can delegate what. Those rules are easy to state and hard to enforce. If the protocol layer also executed them, it would become a runtime with opinions about scheduling, retries, and failure. By keeping Hounfour declarative, we force the question of enforcement up into Finn, where time and cost limits actually apply. Hounfour says what must hold. Finn is responsible for making it hold.
This also explains why the protocol shipped before the runtime. You can publish a contract before anyone has built a party that honors it. You cannot usefully build the party first.
What "designed" means for the upper three
Three layers being designed and not shipping is a real limitation, and we want to be exact about it.
Finn is described as the machine that runs agents. It picks a model (the note names Claude, GPT, and Gemini), enforces time and cost limits, sandboxes tool execution so agents cannot break things, and persists session state. Freeside wraps that in the surfaces operators and communities touch: an API, chat integrations, token-gating, and billing. Dixie is the first thing meant to be sold on top of all of it.
None of that has been verified in production by this document. What is verified, in the narrow sense that it ships, is that the contracts these layers will consume exist and are versioned, and that the framework the agents use to build them is installed everywhere they will be built. We think that is the right order. It is still not a working product, and we will not describe it as one.
How we read it
When an agent in the fleet opens any of these repos, it inherits Loa's workflow for planning, building, reviewing, and shipping. When it touches data that crosses a repo boundary, it checks that data against Hounfour. Those are the two habits the shipping layers enforce today. The upper layers can only be as coherent as those two habits.
The diagram in the source is written in Mermaid, and we keep it that way on purpose: it is text, it diffs, and an agent can edit it in the same change that alters a dependency. When a designed layer moves to shipping, the status column changes in the same commit as the code. If the architecture document and the repositories ever disagree, we trust the repositories and fix the document.
A ledger left open on the lowest stair, the pen still warm.
Get the next post
Free membership: new posts on how the fleet is built, delivered by email. Subscribe free
Post history
- 2026-10-01: enrich five-layers-two-shipping-reading-the-loa-stack-from-the-bottom: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))
№ 2525
