auth9, orchestrator, deck: one person's three answers to the same question

This is a companion to One methodology, three projects, three different endings. That post is about how the method fared on three projects; this one is about the products themselves: what each is, where orchestrator and deck chose opposite answers, why the correction happened, and what comes next.

Data as of September 6, 2026. I had an agent go through each of the three repositories with the same outline, and every claim traces back to a specific file. This post is the synthesis.

---

The three side by side

	Gen 1: auth9	Gen 2: orchestrator	Gen 3: deck
When	2026-01-29 ~ 06-27	2026-02-09 ~ 08-26	2026-08-27 ~
Commits	491	1,606	207 (10 days)
Size	~215k lines	~200k lines Rust + 10k TS	~34k lines
What it is	IAM platform × AI-native SDLC experiment	control plane for agent workflows	native macOS attention board
Now	experiment finished	archived	in daily use
In one line	method × external spec	method productised, intent from taste	intent from observation, method minimised

Their roles: auth9 validated the method; orchestrator expanded it, but too early and with a product philosophy that came from my own preferences; deck is the course correction. deck’s docs reference orchestrator in one direction; there is not a single reference the other way.

orchestrator and deck: opposite choices on seven things

These are two answers by the same person to the same question, how to work with a crowd of coding agents, that point in opposite directions and are each internally consistent. Putting them side by side is instructive.

1. Who operates. orchestrator says “Humans steer, agents execute”: workflows run on their own for days, and only exceptions reach the attention inbox. deck says the agents are running and the human decides where to look. “No automatic card movement, ever.”
2. Control or projection. orchestrator is a control plane: declare the desired state, the system converges, it owns execution. deck is only a projection over tmux (“tmux owns the shells; deck is only the board projection”). If it crashes, no agent dies. It owns nothing.
3. How the surface grows. orchestrator: 126 visible CLI commands, 12 K8s-style resource kinds, a large surface with a gatekeeper (the “concept budget”: any new top-level concept must argue why it isn’t just a field). deck: 0 CLI subcommands, 8 settings, and the small surface is the design (“Resist adding features tmux already provides”).
4. How trust is built. orchestrator through measurement and gates: every CHANGELOG entry carries measured numbers, mutation tests kill tests that pass by accident, a two-sided coverage ratchet. deck through honesty and epistemic humility: “QUIET IS NOT READY”, crash windows marked ambiguous rather than claimed successful, every error message in the shape “what was done + what it rolled back to”.
5. Platform or tool. orchestrator: daemon plus gRPC plus 46 SQLite tables, cross-platform, aimed at operators. deck: Apple Silicon macOS only, single instance, local JSON, built for my own daily use, zero telemetry.
6. Who pays for tech debt. orchestrator keeps institutional ledgers (legacy error codes, freshness records) and settles them in breaking-version windows; the upgrader pays, and the governance system runs up debt of its own. deck prevents debt with a small surface and digests the rest in place at startup (hardening the data directory, redacting old logs, silently clearing legacy fields); it never asks the user to reset. How a product treats debt reveals what it really believes about whether it has users.
7. How it works with AI. orchestrator goes platform: 30 skills plus a feature-request registry plus gate guardrails, multiple agents committing directly, trust delegated to machine verification. deck goes delegation: zero skills, numbered task briefs kept outside the repo (with acceptance criteria, authorisation boundaries, progress checkboxes), all external write access retained by me, trust built on honest reporting. Each project’s way of being developed is exactly how its product treats agents.

Shared DNA: rejecting false greens (mutation tests, “never stub the writer and call it proven”); recording “why not” more carefully than “what was done”; redaction and privacy as hard constraints; light dependencies, Rust plus Tauri, MIT; AI-native development. And one principle running through all of it: never let the system claim something it has no evidence for.

How the correction happened

1. Institutional cost ate product velocity. orchestrator’s last month of commits before archiving was entirely the governance system converging on itself, with zero new features. The gate system was designed for a “multi-person, long-lived platform”; the team was two people and the users rounded to zero. Institutional cost is fixed; the return scales with users.
2. orchestrator diagnosed its own contradiction. A July design document records that about 70% of the production workflow was coordination overhead paid for a dumb-agent contract: “The dumber the agent contract, the smarter the YAML must be.” Follow it through: the smarter the agent, the thinner the case for an external harness, and the model vendors are the ones making agents smarter.
3. Dogfooding showed the real bottleneck was me. Seven months in, my actual pain wasn’t “agents lack governance”, it was “I can’t keep an eye on all of them”. The attention inbox was the most useful part of the whole platform. deck is that inbox lifted out on its own, with everything else deleted.
4. The core premise didn’t hold. Agents in 2026 can’t sustain “autonomous loops for days”. Working, needs-input, turn-done is the reality. When vision and observation disagree, I go with observation.
5. Asymmetric ability to validate. orchestrator’s target user is a platform team, and I can’t validate that on myself. deck’s target user is me, and its hypotheses get tested in daily use. deck is testing a product-first AI-native SDLC: first something I use every day, needs surfacing from use, method brought in as required.

How I’d grade the correction: the execution was clean (a zoom-in pivot, a clean stop, the learning kept, validation first); the cause was seven months without contact with anything that could falsify the hypothesis; the verdict is still open, because deck hasn’t been used long enough. Archiving itself was one more application of the shared principle: a repository with a fresh commit at the top is claiming “someone maintains this”.

What can be carried over from auth9

auth9’s four findings are in the previous post; here are only the parts confirmed as transferable:

• Mutation verification: demand that a test prove it can still fail.
• Typed discipline: agents have no memory, so conventions have to sink to the level of the compiler.
• Two-sided ratchet: rising too far without updating the baseline is also a failure, otherwise regression detection quietly dies.
• The concept budget and its gate paradox: a gate can only check what it can see. That sentence applies to the method itself: it can verify that an implementation matches intent, it cannot generate correct intent.
• The repository as institutional memory: an external memory designed for collaborators who have none of their own.

Next

What the fourth generation is, I don’t know. deck is still in use, and what problems it exposes, and which of them deserve a mechanism, will only be clear after enough use. This lineage already holds one lesson about “design first, then look for validation”, and I’m not pre-specifying this time.

What I can commit to is method, not content:

• Needs come from use. deck’s agent status module is the only precedent so far: a heuristic shipped first, real use exposed its limits, then typed status reporting was introduced. Every future mechanism follows that order.
• Import one piece at a time, never the whole set. The practices proven on orchestrator (mutation verification, typed discipline, two-sided ratchets, the concept budget) are options, not a plan. Which one, and when, is decided by the concrete problems deck throws up.
• Never let the system claim something it has no evidence for. That one doesn’t change between generations.

Everything else, I’ll learn from deck.