Muster: The Task Record Is the Coordination Substrate

How a governed fleet of AI agents built and publicly shipped the product that packages its own governance, in roughly 2.5 hours, on a $3-a-month box

Muster by Analog Elk. A field report by Michael Walliser (walliser.me) · 2026-06-29, with 2026-07 addenda on the intelligent layer and the live demo

Working name: "Elk OS" survives in the CLI (bin/elk-os) and env vars. Muster began as the internal tool of my agency, Analog Elk; the agency is now the case study, not the headline. This is an operating system for agentic software teams.

Live now: the portal, with the build's own task board inside, read-only demo login demo@muster.dev / muster-demo. The Directus Studio (the admin surface) is deliberately not publicly exposed; the portal is the read window, and everything the demo login can reach on it is the same read-only scope at the API. Landing and this paper: musterr.dev (the double R is deliberate). Source: github.com/AnalogElk/muster.

### [2026-07-25] Dated notice: the category in this paper has been superseded This document is preserved as written. It is a dated field report from 2026-06-29 with 2026-07 addenda, and its body has not been revised to match current positioning. Correcting a dated record by quietly rewriting it would cost more than the inconsistency it fixes. Three things a reader should carry into it: 1. The category changed. This paper calls Muster "an operating system for agentic software teams". The product is now positioned as the agent-connected back office: projects, clients, invoices, knowledge, assets, and delivery records, wired into Claude Code. The task record is still the coordination substrate, and section 3 still defends that. It is now one desk of six rather than the whole product. 2. The build metrics are historical. "Roughly 2.5 hours", "about 30 subagents", "over 2 million tokens", "$2 to $4 per month", and the 2026-07-02 note about 18 PRs across 8 repositories all describe specific dated runs. They are evidence about those runs and are no longer quoted as current product claims. The box now runs always on, not duty-cycled. 3. The install boundary is narrower than section 8 implies. Docker is the hard dependency, but the portal additionally needs a published image or a source checkout you supply, and a clean self-host does not reproduce every section of the public demo. Current claims, and the limits that bound them, live at musterr.dev. Where this paper and that page disagree, the page is current and this document is the record.

Abstract

On the evening of June 29, 2026, an empty git repository became a live, internet-reachable, self-hostable software product. The arc from scaffold to public demo took about 2.5 hours of wall-clock (17:56 to 20:23 Pacific), spanned 8 phases, 27 commits, and 90 files, and was executed by a governed fleet of roughly 30 Claude subagent invocations that consumed over 2 million tokens. The result runs on a single AWS instance for about $2 to $4 per month at demo duty-cycle (stopped when idle; §8 firewalls the costs), and you can open it right now.

That an agent fleet can emit 90 files quickly is not the interesting part. Volume is unfalsifiable and ages badly. The interesting part is the apparatus that let a long, multi-session, ship-grade build hold together without a human reviewing every diff, and the fact that the system used that apparatus on itself. Muster used its own task board as the build's spine, its own parallel fan-out to construct one of its own subsystems, and its own adversarial verifiers to keep its own sellable template clean.

This paper makes one architectural claim and defends exactly it:

The task record, not the chat transcript, is the coordination substrate between a human and a fleet of AI agents.

That claim has a mirror image on the product side, and it is the reason Muster does not look like the rest of the "AI for work" category. The reflex of that category is to bolt a chatbot onto the side of your real system: the work keeps living where it lived, and a model answers questions about it from the outside. Muster inverts the arrangement. The work substrate itself, the shared task board, is the surface both parties operate on. A human dragging a card and an agent claiming a row over MCP are first-class writers of the same record. Chat is where an agent thinks; it is never where the team coordinates. When Muster later grew an in-portal assistant of its own, a local, private, permission-aware intelligent layer (§4), that same discipline held: the assistant is a window onto what the system already knows, not a new place where work gets dispatched.

Two honesty notes up front, because the rest of the paper depends on them. First, the contribution here is not new primitives. Claude Code already ships subagents, a session-loaded CLAUDE.md, and worktree support. The contribution is assembling existing primitives into a coordination architecture anchored on a durable task board, and reporting what that buys. Second, this is n=1: one build, by the tool's author, of the tool itself, the single most favorable possible case. Read it as an existence proof and a reasoned playbook, not a controlled study. I did not run the control, and I will say so again where it matters.

[2026-07-02] The n has since grown: in one 48-hour window this apparatus carried 18 PRs to production across 8 repositories, and its 3-reviewer risk gate stopped four machine-written changes with reproducible evidence, including one fix proven to be a no-op by its own deploy preview. Still author-run; no longer one build. See the postscript.

1. The problem: a bigger context window did not solve coordination

The baseline I am comparing against is not a strawman product. It is a workflow: a single agent, one rolling context window, working a session at a time, with no shared task store, no cross-session memory, no parallel fan-out, no adversarial verification, and no enforced collision discipline. Call it the ungoverned single-agent workflow. It is genuinely excellent for a large class of work. It is also structurally weak at a different class, and the weakness is a coordination weakness, not an intelligence weakness:

• The rolling window is the project memory, so the project's memory is as durable as a browser tab.
• A build that spans days re-reads files it already understood and re-litigates decisions it already made.
• One agent is one perspective on one timeline. You cannot attack a problem from several angles at once.
• The builder audits its own work in its own context, sharing every blind spot it is trying to find.
• "Don't commit secrets" lives in a human's head, so eventually it doesn't.
• Point two agents at the same checkout and they silently clobber each other.

The field spent 2025 and 2026 treating the context window as the bottleneck and celebrating million-token windows accordingly. A 1M-token window is still one window, one timeline, one agent. Scaling the window made the single-threaded ceiling more visible, not less. Once subagent fan-out went mainstream and you could spawn thirty agents, the unsolved problem stopped being "can they work?" and became "how do they agree on what is done, and stay out of each other's way?" Parallelism without a shared place to coordinate is just faster chaos.

There is a second industry reflex worth naming here, because it is the mirror image of the first and Muster rejects both. Where the research conversation fixated on the size of the context window, the product conversation fixated on the chatbot: bolt an assistant onto the side of whatever system you already run, and let people ask it questions. Both moves keep chat at the center, one as the place work happens, the other as the interface to work. Neither gives a fleet a shared, durable place to agree on what is done. The million-token window and the side-panel chatbot are the same mistake wearing two hats.

The bottleneck in agentic development is shared, durable, addressable coordination state. The fix is not a bigger window or a cleverer prompt. It is an operating system around the model.

2. The thesis: the task record is the coordination substrate

Chat is where agents think. It is a poor place to coordinate. A transcript is single-threaded, ephemeral, and unaddressable: there is no stable handle to "the decision about the schema." You cannot run a multi-agent, multi-session build on it, for the same reason you cannot run payroll on a hallway conversation.

Replace chat-as-substrate with a durable, addressable task record, a shared board every agent reads, claims, updates, and closes, and the properties invert:

A precise claim is worth more than a sweeping one, so let me separate three things the draft of this paper kept collapsing. There is not one atom; there are three substrates with three jobs:

• The task record is the coordination substrate: claimable units of work.
• Memory files are the knowledge substrate: lessons not derivable from code or git.
• The append-only log is the narrative substrate: what happened, in order.

The argument of this paper is about the first one. The other two are necessary support, and I will name them as such rather than folding them into a single slogan.

2a. The hard part: what makes "claim" safe?

A CTO's first question is the right one. If the board is the coordination substrate, what stops two parallel agents from grabbing the same row? This is the load-bearing engineering question, and I will answer it honestly rather than wave at it.

Muster does not rely on the Directus row being magically atomic. It isn't. A row has assigned_to and status, and the protocol is a compare-and-set: read the row, confirm it is unclaimed, write your identity and an in-progress status, then proceed. But Directus does not give you a true row lock by default, and I have observed the failure this implies: my own working memory carries the note "version collisions happen across parallel sessions, re-check before bumping." Two agents can race a row and produce a lost update.

In this build, contention was controlled one level up, by disjoint dispatch. The orchestrator (me, plus the top-level Claude session) handed each fan-out agent a non-overlapping slice of work, and physical isolation came from worktrees, not from the board. So the precise, defensible claim is this: the task record is where work is represented, persisted, and audited across the fleet; staying off each other's toes came from disjoint dispatch and worktree isolation, not from the board solving contention by existing. If you scale past human-arbitrated dispatch, you need real claim semantics (optimistic concurrency with a version check, or a queue in front of the board). I have not built that, and I am not going to pretend the row gives it to you for free.

3. The apparatus: six organs of an agent operating system

Muster is a coordination architecture with named organs. Read it as a transferable mental model; you can build all six on any vendor's stack.

The spine: the shared task bus. A Directus 11 instance over Postgres 15, exposing an os_* schema (os_tasks, os_sprints, os_projects, releases, repositories, organizations, contacts). The human watches it in the portal; the agent fleet reads and writes it over Directus's native MCP server at /mcp, not custom glue, gated by a single mcp_enabled setting. The credential is always an environment reference (Bearer ${DIRECTUS_ADMIN_TOKEN}), never a literal, so the real token lives only in a gitignored .env.

The memory: durable cross-session knowledge. On-disk memory files with a one-line index. Lessons that are not derivable from code or git survive the session boundary here.

The narrative: an append-only log. A running build log that records what happened, in order, separate from both state and lessons.

The muscle: ROI-governed fan-out. Not "spawn eight agents." A scout surveys the work, an ROI governor decides what is worth parallelizing, and only then do agents spawn with disjoint roles (ground → build → audit → verify) so they decorrelate instead of duplicating.

The immune system: adversarial verification and loop-proofs. Independent verifier agents whose mandate is to disprove the builder's claim, plus from-scratch loop-proofs that re-run the one-command install from an empty volume and check the contract holds.

The constitution: governance as plain-English code. A numbered, versioned ruleset (CLAUDE.md) loaded into every session as non-optional context: secrets are env-only, one trunk equals production, semver is automated, never edit a contested worktree path, and a literal "definition of done" ceremony. This build ran under the author's ten-section constitution; the repo ships a distilled per-profile cut (six to seven sections) that wire renders into every deployment. The rules are imperative and testable. This is what makes a stateless model behave like a long-lived teammate.

The whole thing stands up with one command. bin/elk-os is a resumable, idempotent phase machine (init → up → migrate → seed → wire → doctor) whose only hard dependency is Docker (the migrate/seed phases additionally use stdlib python3). The doctor subcommand is the credibility instrument: a green/red board that checks every subsystem from an empty start and exits nonzero on red. It is a from-scratch acceptance test, not a smoke check.

A note on alternatives, because "task board vs raw chat" is a soft target nobody serious argues for. The real competitors to a task board are: git itself (branches and PRs as the unit of work), markdown plan files in the repo (which my own spec-flow kit uses), and framework-managed handoff state (LangGraph, CrewAI, AutoGen). A board earns its place over markdown-plan-files for one reason: it is a queryable, concurrently-writable, human-watchable store with a stable ID per unit. Plan files in git serialize fine for one agent but invite merge conflicts the moment several agents update status at once, and they are not watchable in real time by a non-technical stakeholder. A board over a database gives you the query surface and the live human read-side that flat files do not. That is the honest reason to reach for one, and it is a smaller, more defensible claim than "tickets are novel."

4. The intelligent layer: local, private, and permission-aware

This section describes the newest part of Muster, and the most revealing one for a technical reader, because it is where the temptation to abandon the thesis is strongest. It postdates the 2.5-hour build by two weeks (designed and built in July 2026), so unlike everything in §3 it did not build itself. I am putting it in the body rather than a postscript because it is the headline new capability and the clearest evidence of the engineering judgment the rest of this paper only asserts.

Recall the three substrates of §2: the task record (coordination), memory files (knowledge), and the log (narrative). The intelligent layer takes the knowledge substrate and makes it queryable and conversational, without touching the other two. It is two pieces: a private engine, and an assistant that treats that engine as untrusted.

The private engine. Muster embeds a local retrieval engine: a FastAPI service on port 9100 (the self-host overlay binds it to 127.0.0.1:19100, alongside the overlay's already-isolated Postgres, Qdrant, and Redis). Embeddings are computed on the box with fastembed running BAAI/bge-small-en-v1.5 (384-dimensional vectors, ONNX on CPU). Postgres holds the documents and full-text index, Qdrant holds the vectors, Redis caches queries. The load-bearing property is what is absent: no API key, no external inference call, no bytes leaving the machine. Retrieval is entirely local. The lineage is real and worth stating, because it is half the thesis: this engine began as analog-elk-v3, a standalone Claude Code plugin (a local knowledge base plus a RAG API plus agent tooling) that I ran across my own projects. Muster is the synthesis of that plugin with the production portal my agency actually runs on: the portal's shared task substrate plus the engine's private intelligence, packaged as one reproducible self-host stack.

Elk Chat. On top of the engine sits an in-portal assistant, Elk Chat, over your own knowledge base and task data. It was not built as a new surface. It upgrades the portal's existing read-only assistant (Ask Elk), which already carried the part that matters: a role-allowlisted, read-only set of Directus tools, invoked with the caller's own token. The additions are narrow and deliberate: a kb_search tool wired into that read-only tool loop, and per-user rate limiting on the chat route. Extending a shipped, already-gated surface rather than standing up a parallel chat is the boring, correct choice, and it is why the security model below came almost for free.

The engine is an untrusted ranking oracle. This is the load-bearing idea, and the one I would most want a hiring manager to read. The engine indexes everything it is given, including gated and unpublished pages. If Elk Chat pasted the engine's returned text straight into the model's context, it would leak documents the caller is not allowed to see, because the engine has no idea who is asking. So Muster never trusts the engine for visibility. kb_search uses the engine's /query endpoint for one thing only: to rank candidate document slugs. It then re-fetches the actual content through Directus, with the caller's own token, back through the portal's role-based permission filter (buildPageFilter, mirroring the gateCandidateSlugs re-gate the plain KB search already applies). Every candidate is re-gated by the caller's real permissions before a single character reaches the model. The engine is a fast, dumb ranking oracle; Directus stays the sole authority on who may see what. The net guarantee is precise: the assistant can surface only what that user could have opened by hand.

The hardening, because a security claim without the failure modes closed is a slogan. Four concrete moves:

• Read-key auth. /query, /stats, and the ingest routes require an X-API-Key header, compared in constant time (hmac.compare_digest) so the check does not leak key bytes through timing. Only GET /health stays open, for uptime probes.
• A startup guard that fails closed. The auth dependency is fail-open by design for local development: with no key configured, all requests are allowed, which is convenient on a laptop and a foot-gun in production, where a deployment that simply forgot to set the key would silently serve an open API. So the engine will not boot a non-development instance with no key set (enforce_startup_security) unless you explicitly opt into insecurity with a named flag. It fails closed, loudly, at startup, rather than failing open, silently, at request time.
• Trimmed attack surface. /docs, /redoc, and /openapi.json are disabled outside development, and requests are rate-limited per key.
• Orphaned-vector reconciliation. Deleting a document is a two-store operation: the Postgres row and the Qdrant vector both have to go. If an upstream page is unpublished or deleted and only the row is removed, a stale embedding would still surface the old snippet, leaking content the source no longer exposes. So deletes reconcile both stores, and /query additionally drops any semantic hit whose backing row is gone, so an orphaned vector can never answer a fresh query (answers already cached age out within the engine's one-hour query-cache TTL). This is exactly the second-order leak the permission model above would otherwise miss, and closing it is the difference between a demo and a system you would let a client near.

On generation, an honest line about what is and is not local. Muster ships no local generation model. Measured local generation on hardware better than these boxes runs around 0.4 tokens per second, which is unusable. So retrieval is keyless and local, but the generation step uses the deployment's own model credential (ANTHROPIC_API_KEY, with a configurable ASSISTANT_MODEL). Without a key the feature is dark by design: a 503 and an honest in-chat notice, not a broken chat box. This keeps the "no external inference" claim exact rather than convenient: it applies to the engine (embedding, ranking, storage), which is genuinely local, and it does not overreach to cover the assistant's text generation, which a self-hoster points at their own provider. Saying precisely where the boundary sits is the same honesty the cost and correctness sections trade on.

Why this lives in a paper about task records. Elk Chat is the hardest test of the thesis, because a chat assistant is exactly the thing that could quietly become the coordination surface. It does not. By construction it is a grounding window over the knowledge substrate: it answers "what does the system know," and it cannot claim, assign, or close a unit of work. Coordination stays on the board; the assistant reads, it never dispatches. Even Muster's own AI feature is subordinate to the task record. That is the thesis surviving contact with its most tempting counterexample, which is why the intelligent layer reinforces the argument instead of diluting it.

5. The recursion: the system built the thing that ships the system

Every capability the original 2.5-hour build shipped was used to build Muster. (The intelligent layer of §4 is the exception, and a clean one: it came two weeks later, so it is the single capability that did not build itself.)

I want to be careful about what this proves. Self-use shows the apparatus is coherent and usable: it can carry its own non-trivial build. It does not prove the apparatus was necessary (a simpler path could exist) or net-positive in dollars (that is §8's job, and the answer is qualified). This is dogfooding, which is real evidence of fitness and a poor substitute for a controlled comparison. I am downgrading my own earlier phrasing on purpose.

6. The evidence: what got caught, and by which organ

The fleet caught roughly 7 functional bugs and 6 brand-leak references before shipping, none caught by a human running the software. That is the headline. But the honest version splits these into two buckets, because conflating them inflates the multi-agent claim.

Bucket A: clean-room / loop-proof catches (a single disciplined agent could run these too)

These were caught by from-scratch reproduction and live deploy, techniques that do not require parallelism or adversarial diversity. I am attributing them to discipline, not to the fleet, because a single agent that re-derives from zero would also find them. They are still real, and they are still bugs the ungoverned default ships, because the ungoverned default rarely re-runs from an empty volume.

The instructive one, walked end to end so you can see a receipt rather than take my word. The RAG service claimed port :9100. A naive health check reported "healthy." It was lying: a different, already-running engine was answering on that port, and the check was passing for the wrong reason. The trail is on the board: a task row was opened for the RAG bring-up, a loop-proof run in a clean environment (where the impostor process was not present to flatter the check) flipped it red, the closing note recorded the root cause as a co-located listener, and the fix commit (5222976, in the public repo) isolated the port (the default moved to 19100, alongside the overlay's already-isolated Postgres/Qdrant/Redis ports), so no impostor is present to answer. One honesty note on the hardening: the shipped check parses the engine's reported status rather than accepting any 200, but it still does not assert which engine replied; that identity assertion is a filed follow-up, not a shipped fix. "Tests pass" and "the system works" are different claims, and an agent watching its own rolling context sees green and moves on. The thing that caught it was not a smarter agent. It was a from-zero environment.

Also in this bucket: a genuine RAG port collision in the compose topology; a set -e/pipefail bug in doctor that would have silently swallowed failures, the exact opposite of a doctor's job; a compose path where turning RAG off aborted the whole stack; and an arm64-vs-amd64 portal-image mismatch that is invisible in code review and unit tests and only surfaces when real bytes hit a real machine. That last one was diagnosed and fixed live on the box during deploy. A from-scratch agent without a live-deploy loop produces a repo that "should work." This loop produced a box that does.

Bucket B: fleet-dependent catches (need parallel and/or adversarial agents)

These are the ones that genuinely required more than one decorrelated perspective.

The six leak-scrubs are the clearest. Muster ships two profiles, generic and analogelk, and the commercial premise is that generic contains zero trace of its origin. A scrub-audit plus three adversarial leak-verifiers found and cleaned 6 real "AnalogElk" / analogelk.com references before they could ship in the sellable template. I will undercut my own rhetoric here, because honesty is the brand: these six are string-checkable, which means a deterministic grep or linter would also catch them. So they are strong evidence that an automated provenance gate beats good intentions, and weak evidence for fan-out specifically. The fan-out's marginal value over a linter shows up only on the paraphrased, non-literal leaks, and those were fewer and softer.

The seam bugs are the more honest case for the fleet: a required releases.repository_id foreign key missing from the pruned schema snapshot, and AE seed files bare-named and colliding with a kept UI-folder collection. These are integration and packaging bugs that live between subsystems, where a single agent optimizing the file in front of it has no vantage point. Parallel explorers attacking the seams found them.

The governance facts

• 0 secret leaks. DB and admin tokens were always env-referenced, never echoed, never committed, and this was grep-verified, not assumed.
• 0 collisions while building the portal from a shared repo carrying 28 active git worktrees. I want to be precise about how: I did not demonstrate collision-handling under load. I avoided the contention by construction, building the portal read-only from a pinned archive snapshot rather than from the live contested checkout, per the written §9 rule. That is good discipline and a real result, but it is "sidestepped the race," not "won it."
• An honest shipped-vs-aspirational ledger, maintained throughout, the antidote to agentic over-claiming.

On the fleet's true size

"30+ subagents" deserves a breakdown so the number does not read as inflated. The accounted core is the 8-agent schema workflow and the 4-lens live-pricing cost panel. The remainder were explorers, builders, and verifiers spread across the other phases, several of them single-shot. Not all of them produced kept work: some fan-outs returned partial or discarded output that was retried or dropped, and that wasted production is part of the token cost in §8. I did not instrument a precise discard rate, which is itself a measurement gap I would close on a real product run.

7. The comparison, stated fairly

The ungoverned single-agent workflow is faster to start, cheaper per token, and the correct choice for a large class of work. The apparatus is a specialization, not a general upgrade.

Every row is an architecture difference. But re-read §6 before you read this table as a clean win: the Bucket A bugs are available to any disciplined single agent that adopts clean-room reproduction, and the strongest leak catches are linter-catchable. The genuinely fleet-dependent value is narrower than the table's nine rows imply. The right summary: the apparatus is the operating system you wrap around the agent, and its incremental value is real but concentrated in persistence (multi-session builds) and seam-level adversarial verification, not spread evenly across every row.

8. The economics, with the costs firewalled

There are three different costs in this project and the slogans tend to blur them. Keep them apart:

1. Demo hosting: ~$2 to $4 per month. This is the AWS box at demo duty-cycle: the instance is stopped when idle, so the floor is EBS storage (~$2/mo) plus pennies of compute for the hours it is actually up. Run the same box 24/7 and you are in ordinary always-on VPS territory (the repo's own provisioning docs quote ~$6–12/mo). It is what "cheap" refers to, and it has nothing to do with the cost of building the system.
2. Build model-spend: the one-time cost of the 2.5-hour build. Over 2M subagent tokens. In dollars this is small in absolute terms but one to two orders of magnitude above the hosting figure.
3. Ongoing fleet-operating cost: what it would cost to run this apparatus on your next project, which is dominated by token spend and by the human time to govern it.

Now the verdict, stated against my own interest: the apparatus did not primarily buy speed.

Wall-clock: real but secondary, and I will not fake the math. Parallel fan-out helped, but a large share of the build (scaffold, compose wiring, live-box debugging, packaging) was inherently serial. An honest estimate is that fan-out bought something in the range of 1.5× to 2× on overall wall-clock, with the 8-agent schema phase collapsing far more on that phase alone. I am labeling that a rough estimate, not a measurement. I do not have a measured parallel fraction, and the precise Amdahl figure an earlier draft of this paper carried was invented. I am removing it rather than dress up a guess as arithmetic.

Correctness: where most of the value lives. ~7 functional bugs + 6 leaks = ~13 defects caught, 0 known-shipped as of writing (I can count catches; I cannot enumerate misses, so "0 shipped" is survivorship and I will not claim it as a hard zero). [2026-07-02 follow-up: the survivorship caveat was right, the first post-ship self-audit (PR #3) found and fixed 14 shipped defects, enumerated in that PR's commit trail. The ledger firing is the mechanism working, not failing.] Why would a linear run ship some of these? Because the single pass that wrote the analogelk.com reference is the same pass asked to find it, error-correlated, so it ships it. The verification layer's job is error decorrelation. With the caveat from §6: my verifiers are the same base model with different prompts and temperatures, which is weak decorrelation. They share training-failure modes. The decorrelation is real for surface and seam errors and thin for anything where the base model is confidently and uniformly wrong.

Durability: the "possible at all" win. The build consumed over 2M subagent tokens across 7+ sessions. A single window cannot physically hold that; it compacts, forgets, re-reads, re-litigates. By externalizing state into the board, disk memory, and the log, the apparatus turned an impossible-for-one-window task into a resumable one. This is the cleanest win, because it is categorical: a linear run does not finish this build cleanly, it stalls at the context boundary. [2026-07-02 follow-up: this was later tested the hard way. On 2026-07-01 the orchestrating session was killed mid-flight by a machine crash; because every unit of work lived in the task record and per-agent journals, a fresh session reconstructed the full state and resumed with zero lost work.]

The cost, plainly. The apparatus spent over 2M tokens, dominated by coordination rather than production: the same artifact read and re-reasoned several times, plus the discarded fan-out output from §6. There is a genuine token premium on every run, including runs where the verifiers find nothing. You are buying insurance, and you pay the premium whether or not you file a claim.

The caveat I will defend rather than hide. I did not run the control. I did not build Muster twice and measure the delta. "The ungoverned default would have shipped these" is a reasoned argument from the logged catches, not a measured A/B. The bugs and the catches are in the board's history; the counterfactual is inference. I would rather state that than imply a rigor I did not perform.

9. Limitations: when not to reach for this

When it is overkill. A single-file fix, a sub-100-LOC change, a throwaway prototype, anything that fits one window: the ungoverned default is faster and far cheaper, and the memory/board layer is pure overhead. My own workflow kit has a /quick lane for exactly this (Muster does not ship one, deliberately; small work should not pay for the apparatus). If a human reviews every diff, paying several agents to re-derive that judgment is redundant. If the work is genuinely novel and not verifiable, open-ended design with no ground truth, adversarial verifiers add little; they excel only at checkable properties.

The apparatus's own failure modes. Correlated blind spots survive fan-out, as §8 conceded. Verification is only as good as what it was built to check; a verifier that greps AnalogElk misses a paraphrase, a base64'd token, or a brand reference baked into an image asset. I can log the catches and cannot enumerate the misses. Several caught bugs (the doctor pipefail bug, the compose RAG-off abort) were in the governance machinery itself: more moving parts, more places to break. And the task-spine as single source of truth is also a single point of coupling, which leads to the next gap.

The spine is shared mutable state, and I have no graceful-degradation story. If the board goes down mid-build, the fleet loses its coordination substrate, and I have not built a recovery path beyond "the orchestrator notices and restarts." Two agents can race a row (§2a). The board is sold as the solution to coordination while having a coordination problem of its own. On a $3 single-box demo the board is also a literal SPOF, and the live exhibit can 404 if the box hiccups.

The public-demo posture, stated so you do not assume the worst. The headline exhibit is a public, read-only window onto a real Directus instance. Directus itself (Studio and the admin surface) is deliberately not publicly exposed; the board is read through the portal's demo login, and the admin token that can write it is env-only and never in the client. The honest risk acceptance is mine: this is a disposable demo with seed data, not production, and standing it up at a guessable URL with these specific exposures was a blast-radius judgment I made deliberately. If you self-host past a demo, lock the public read surface and never expose the admin instance.

What still needs a human, non-negotiably. This is the part I most want a hiring manager to read, so I am putting it in the body rather than a footnote. The reframe, "this is a product, Analog Elk is just the case study," was a product call no agent made. The shipped-vs-aspirational ledger exists because a human insisted on honesty and defined what counts as shipped; agents optimize toward "done" and only a human reliably separates done from claimed-done. The arm64/amd64 fix happened live on metal with a human diagnosing. Bounding the fan-out, deciding "this is enough verification," is human ROI governance; the machine will fan out forever. These judgment calls are the leadership content of this build, not a caveat to it.

The break-even rule: the apparatus pays off when the work is multi-session (won't fit one window) AND ships to others (correctness and leaks matter) AND can't be continuously human-reviewed. This build was all three. Miss any one and the ungoverned default is the right tool.

10. Generalization: build a coordination substrate for your own fleet

One loud caveat first, because every confound in this paper points the same way: this is one anecdote, self-built, on the most favorable possible case. The playbook below is reasoned extrapolation, untested elsewhere. Treat it as a hypothesis to falsify on your own work, not a proven method.

With that stated, the six organs are transferable, and none of it is vendor magic:

1. Pick a durable store. Any ticket system or database with an API. Make the task row the unit of work, the thing agents operate on. Prefer it over markdown-plan-files once more than one agent updates status concurrently (§3).
2. Give every agent the protocol: claim → work → verify → close, and build real claim semantics if you scale past human-arbitrated dispatch (§2a). Do not assume the row is atomic.
3. Add an adversarial verify pass for anything with a hard correctness or commercial boundary: secrets, PII, licensing, branding. Decorrelate the verifiers as much as you can, and know that same-model verifiers share blind spots.
4. Write the constitution down as numbered, testable rules loaded into every session.
5. Enforce worktree isolation. Every agent in its own branch off fresh trunk; the orchestration root read-only. Cheap to enforce; a clobbered branch is expensive.
6. Validate by clean-room reproduction, in CI, on the target architecture, because a health check that is green for the wrong reason ships broken systems.

Separate state (the task bus) from lessons (memory files) from narrative (the log), each with its own write cadence. Three substrates with three jobs beat one overloaded window. The principle should outlive these particular tools.

11. Run it yourself, and watch the spine

The apparatus is public, MIT-licensed (© Michael Walliser; the os_* schema's lineage from directus-labs/agency-os is attributed in NOTICE), and self-hostable, permissive on purpose: the business is services, and the code is the credential, not the moat. The short path from clone to green board is the whole pitch, and the doctor board at the end is the credibility instrument:

bin/elk-os init      # scaffold + env
bin/elk-os up        # compose core (Directus, Postgres, RAG, portal)
bin/elk-os migrate   # apply os_* schema
bin/elk-os seed      # profile data (generic | analogelk)
bin/elk-os wire      # enable native MCP, wire Claude to the board (env-referenced token)
bin/elk-os doctor    # green/red from-scratch acceptance board

The repository is public: github.com/AnalogElk/muster. It ships bin/elk-os, the CLAUDE.md constitution templates (a distilled cut of the ten-section ruleset that governed this build, the single most reusable artifact in this package, and the one I would copy first), the two profiles, the compose topology, and the local intelligent layer of §4 (the RAG engine plus the permission-aware Elk Chat wiring).

An empty repository became a live, self-hostable product in about 2.5 hours, governed end to end by its own task board, hosted for a few dollars a month, and you can poke the real thing now. The portal is the human read-side of the loop, and the board it renders is the spine itself: sign in with the read-only demo login (demo@muster.dev / muster-demo) and you are looking at the actual coordination substrate of this build, the same os_tasks rows the fleet claimed, worked, and closed to bring the system into existence. (The Directus Studio/admin surface is not publicly exposed; the portal is the read window, and the demo login holds the same read-only scope at the API.)

The model is stateless; the organization around it does not have to be. That is the whole argument. The next generation of dev tools will not compete on model quality, which commoditizes. They will compete on the operating system around the model, and the task record is its coordination substrate. Make the ticket the unit of work, and the chat becomes disposable.

It built the thing that ships itself. Go watch the spine.

Postscript: 2026-07-02, one week in service

Two things happened after this paper was written that bear on its claims, so I am appending rather than rewriting (the log's rule). First, the durability claim met a harder test than a context boundary: the orchestrating session was killed mid-flight by a machine crash. Because every unit of work lives in the task record and per-agent journals, a fresh session reconstructed the full state and resumed with zero lost work. Second, the apparatus carried real production load: 18 pull requests across 8 repositories in one 48-hour window, every machine-written change passing a 3-reviewer adversarial gate, a gate that also refused four changes with reproducible evidence, including a fix it proved to be a complete no-op via its own deploy preview, and a blog rollout it still holds because indexing thin pages before the content exists would be an SEO regression. The system this packages runs a real agency in production: clients, invoices, uptime monitoring, backup restore drills, automated releases (Muster v0.1.1 and the agency platform's v1.21.0, both cut 2026-07-02). Still n=1, still self-reported, but now logged against production, not a demo.

Postscript: 2026-07-14, two weeks in

Three updates since the July 2 note, each checkable from a browser, appended under the same rule.

First, the intelligent layer of §4 is deployed in the public demo, not just described here: the portal at app.musterr.dev ships Elk Chat, and the local engine runs on the demo box. One boundary from §4 is visible in production rather than in prose: the public demo runs keyless, so retrieval is live and the generation step answers with the in-chat "not configured" notice §4 describes. That is the local/external line doing its job in public.

Second, the board behind the demo login stopped being a summary. It carries the original build record with hierarchy and statuses preserved, inside a seeded working agency: 8 organizations, 11 projects, sprints, invoices, releases, and a knowledge base, with the task board itself still growing (69 tasks on the board view at this writing). The read window now shows a working system, not a screenshot's worth of rows. The write posture was re-verified the same day: the demo role reads os_tasks fine and every create, update, and delete attempt returns 403.

Third, the exhibit hardened from a bare IP to a product surface: musterr.dev (the double R is deliberate) with browser-trusted Let's Encrypt TLS, a static landing and this paper served as plain files that survive the live system being down, and self-hosted, IP-anonymized analytics that honor Global Privacy Control, disclosed on a public privacy page.

One correction to §8's hosting frame, in the ledger's spirit: the demo box currently runs always-on, on a larger instance than the build-night machine, while the demo is in active rotation. The duty-cycled $2-to-4 figure remains the floor of the hosting model, not the current posture. The claims did not change; how much of them you can check without taking my word did.

Michael Walliser is a creative technologist and AI-systems builder (walliser.me). The page you are reading is itself part of the deliverable: a static field report that survives the live system being down, with the running system one link away. Muster by Analog Elk is the headline; Analog Elk the agency is the first install. Source: github.com/AnalogElk/muster.