1.2 The Flywheel

1.2.1 One-Sentence Definition¶

The Agentic Coding Flywheel is a methodology where the bulk of human effort goes into an upfront plan document, that plan is decomposed into a dependency graph of atomic tasks (called "beads"), and parallel AI coding agents execute against that graph under human oversight.

There is a second, equally important meaning. "Flywheel" also refers to a compounding effect: each project you build becomes a library for the next project. The tools stack. FrankenTUI feeds FrankenSQLite feeds FrankenTerm feeds Agent Mail Rust. Each rotation makes the next one faster.

"That's what the Flywheel is all about. Making programs and libraries and then turning around and combining them with other new libraries you've made to make still more ambitious new projects." — Jeffrey Emanuel

These two meanings reinforce each other. The methodology (plan, decompose, execute) produces high-quality libraries. Those libraries reduce the cost of the next project's plan. The next project produces more libraries. This is the flywheel.

1.2.2 The Three-Space Model: Plan, Bead-Map, Code¶

The methodology operates across three distinct artifacts, each at a different level of abstraction:

1. Plan space (PLAN.md or similar)

The architecture document. Describes what you're building, why, how components interact, what the interfaces look like, what the edge cases are. Written collaboratively between the human and multiple frontier models. Typically 2,000 to 21,000+ lines for serious projects.

The plan is a read-once artifact. Once beads are created from it, agents work from the bead-map, not the plan. The plan's job is to produce a good bead-map; after that, it is archived.

2. Bead-map space (master-todo-bead-map.md or beads database)

The execution graph. Each bead is one atomic task that one agent can complete in one session. Beads have IDs, descriptions, dependencies, acceptance criteria, and status. A complex project produces 200 to 500 initial beads.

The bead-map is the shared state that all agents read from. It replaces ad-hoc coordination; agents claim beads, execute them, and mark them closed.

"They follow the plan as embodied in the beads task structure, and they use my bv tool to pick the best bead to work on next." — Jeffrey Emanuel

3. Code space (src/, the repository)

The implementation. Generated by agents working against beads, reviewed by humans and other agents, integrated through a merge cycle. Code is the output of the process, not the center of it.

The key discipline: these three spaces are kept separate. The plan informs the bead-map. The bead-map drives the code. Information flows in one direction. Agents executing code do not modify the plan; agents refining the plan do not touch the code.

"The 2:1 planning ratio is the part everyone skips." — ACFS community member

1.2.3 Why the Plan Is the Product¶

In traditional development, code is the deliverable. Plans (if they exist) are secondary artifacts that drift out of sync within days. The Flywheel inverts this.

The plan is the durable artifact. Code is derived from it. If you lose the code, you regenerate it from the plan in hours by re-running agents against the bead-map. If you lose the plan, you have lost the architecture, the design decisions, the rationale for every tradeoff. You would have to reverse-engineer all of that from code, which is expensive when the code was written by agents whose context no longer exists.

Jeff's plans go through 8 to 15 revision rounds before any code is written. One planning document reached 21,000 lines. Plans are version-controlled with the same rigor as source code: every revision is a git commit, and the diff history of the plan is itself a diagnostic artifact.

"I didn't write that plan. I caused it to be written!" — Jeffrey Emanuel

The practical consequence: planning tokens are cheap. Code tokens are expensive. Debugging tokens are ruinous. The effort split looks like this:

The 85% figure sounds extreme. In practice, it means the human spends most of their time reading, refining, and stress-testing the plan. When the plan is solid, execution is largely mechanical.

"Planning Phase: world is Claude Code's oyster. Implementation Phase: leave no room for imagination." — ACFS community member

1.2.4 The Flywheel Effect: Each Tool Strengthens the Next¶

The toolchain is designed so that each tool's output feeds the next tool's input. This creates a compounding loop:

• NTM (tmux manager) spawns agent sessions. Agents use Agent Mail to coordinate. BV (beads viewer) tells agents what to work on. BR (beads rust) tracks what's done. CASS remembers cross-session context. CM feeds learnings back into future plans.

No single tool is revolutionary on its own. The value is in how they interlock. Using three of these tools together is meaningfully more productive than using any one of them alone.

The Five Synergy Loops:

1. Session → Memory: CASS indexes all agent sessions → CM extracts procedural rules → fresh agents inherit prior discoveries
2. Task → Priority: Beads tracks the work graph → BV computes PageRank → agents always work on the highest-leverage task
3. Coordination: Agent Mail handles file reservations and cross-agent messaging → no two agents edit the same file
4. Safety: DCG blocks dangerous commands + SLB requires peer approval + CAAM rotates accounts → "vibe mode" is safe
5. Quality: UBS flags bug patterns → Beads creates blocking fix tasks → agents fix before merging

The compounding goes deeper than tool integration. Each project built with the flywheel becomes a library available for the next project. The February 2026 Rust Agent Mail port stacked 10 self-built libraries on top of each other: FrankenTUI, FrankenSQLite, FrankenSearch, asupersync, fastmcp_rust, sqlmodel_rust, beads_rust, and three others. Each of those libraries was itself built using the flywheel methodology, using earlier libraries as dependencies.

"My agentic coding workflow has gotten so meta and self-referential lately. I can feel the flywheel spinning faster and faster now as my level of interaction/prompting is increasingly directed at driving my own tools. Like this weird prompt I just used, telling Opus 4.5 to use my beads analysis tool to figure out what all its robot friends should most advantageously apply themselves to using graph theory on my hundreds of open tasks and subtasks in beads." — Jeffrey Emanuel

The system is becoming what Jeff calls "a distributed cognitive system with NTM/beads/agent mail as the signaling layer." The tools stack, yes, but the effect goes further: the swarm begins to act as a coordinated intelligence that the human steers rather than directs.

This compounding is why output velocity increases over time rather than plateauing. A practitioner six months into the methodology has accumulated libraries, prompts, and institutional memory (via CASS/CM) that a newcomer lacks. The gap is real, but it closes with each project you ship.

"I find scaling past 2-3 agents has a pretty steep falloff for oversight quality in any non-greenfield work." — ACFS community member

This is a fair observation, and it points to an important caveat: the flywheel's acceleration depends on the quality of your coordination infrastructure. Scaling agents without scaling your planning discipline just scales noise. The toolchain is necessary but not sufficient; the methodology is what makes it work.