I'm testing out Jeffrey Emanuel's agent flywheel cause I want to learn more about his agentic coding process.
I've seen him on twitter and how much code he pushes. 300k commits in 12 months. He appears to be one of the most prolific at this sort of thing, at least in the public sphere. I've also used a few of his tools for a bit and like them, like ntm and dcg.
This is for engineers who code with AI, who follow Jeffrey Emanuel online but don't understand his workflow particularly well, because it's not really written up anywhere outside of the tools themselves. Basically me 10 days ago. I found that the setup wizard for agent flywheel + the ntm palette commands to be the best source of information on the workflow.
The point of this was for me to learn it through actually implementing something using his process.
The numbers
The short version
The main thing to understand about the workflow: It relies on an agent swarm that can communicate with each other, driven by beads, to commit direct to trunk, and then relies on heavy verification methods to ensure that the code is correct. Optimistic file locking is used to prevent agents from conflicting with each other.
- 01 PLAN.mdhuman + models
One big markdown plan. Drafted with Opus, revised by GPT Pro, then adversarial review rounds.
- 02 beads (br)316 tasks
The plan is split into a graph of tasks with dependencies. bv tells an agent what to pick next.
- 03 orchestrator1 agent
One Claude in ntm. I talk to it; it nudges, grows and shrinks the swarm.
- 04 workers3–5 agents
Each claims a bead, reserves the files it will touch, writes code and tests.
agent mailMessages between agents + advisory file reservations.
- 05 ./dev commit124 steps · ~4 min
Runs the fast gate on the exact tree being committed. Fail = no commit.
- 06 main444 commits
No branches, no PRs, no human review. The bead closes and the worker picks the next one.
The project
I picked a nice sized project to work on: a CRUD, CP, multi-node key-value store, using Raft to ensure consistency.
Databases are quite interesting, and I also felt that focusing on the consensus angle would be a good way to really test out the verification and testing methodology, because it goes a bit further than just writing unit tests. You have to simulate multiple nodes communicating with each other at the same time, and problems related to timing and concurrency etc.
So I'm going to keep the db api simple and instead lean into the verification as the main focus point. This will push the verification stages hardest and perhaps introduce me to a few new techniques. The plan ended up with:
- unit tests: nothing fancy here
- property tests: you specify invariants that a unit under test should follow, and then the infrastructure generates hundreds or thousands of individual test cases to verify with.
- compile-fail tests: verify that your type level domain code is correct by creating snippets of code that shouldn't be able to compile.
- reference-model differential tests: using a simpler representation of your logic, you run thousands of generated test cases against it to generate traces that you can then replay against your application code, to ensure they both behave the same way.
- golden vectors: compare inputs and outputs to example files on disk to make sure they are byte level identical.
- FoundationDB-style deterministic simulation: ensure that all sources of indeterminism are wrapped in interfaces that can then be stubbed out for deterministic versions. The same seed produces the same outputs.
- nemesis / swarm testing: a bit like Netflix's chaos engineering, you throw random mixes of faults at the system to ensure that it behaves the way you want.
- checker self-tests via bug injection: similar to mutation testing, you make changes to the code that should break the application and make sure that the tests fail. Very high value, as agents can often write fragile and crappy tests.
- API conformance suite: checking that the real HTTP server performs as expected against a written spec of the API when hit over the network.
- crash probes: e.g. run
kill -9during risky ops to ensure recovery. - fuzzing: throw random garbage bytes at the parsers (journal, HTTP, network messages) and check they never crash. Planned, not built yet.
- code coverage ratchet: subsequent changes can only ever improve coverage metrics.
I'll build it in Rust, a language I've never written myself. Rust was chosen just because I've not used it before. I'm curious about building a project in it, it seemed like a good match for this project, and it's what he uses for a lot of his projects, so I thought the tooling would be a good match. I'll use his Rust project setups as a baseline for the config:
- Repos used as the baseline: frankensqlite and frankenredis, the two closest to a KV store (storage engines with conformance suites), plus pi_agent_rust and beads_rust.
- What it borrowed: his AGENTS.md structure, and strict lints enforced in config:
unsafe_code = "forbid", clippy pedantic + nursery, and a written reason next to every allowed lint.
I spun up a fresh Hetzner box to do this, as the agent flywheel needed Ubuntu 24 and I didn't want to interrupt my main box. I followed the happy path full install as per the agent flywheel setup script. This mostly went fine, took 20 minutes.
How the workflow works
As I waited for setup, I got Claude to explore his repos and projects and give me a bit of a breakdown of how it works:
- 1-3 hours should be spent on the planning process, creating a detailed md plan.
- Trunk based development, no branching.
- Agents plan tasks with beads (br).
- And use agent mail to reserve glob patterns for what they want to work on.
- Validation is batched up and run with the Rust build tool.
- No human code review.
The tools:
- ntm (Named Tmux Manager): runs multiple AI coding agents in separate tmux panes
- br (beads): agent-first issue tracker
- bv: viewer for beads, agents use it to pick their next task
- agent mail: messaging and file reservations between agents
- dcg (Destructive Command Guard): safety hook that blocks destructive commands
- ubs (Ultimate Bug Scanner): bug scanner across lots of languages
- rch (Remote Compilation Helper): offloads builds to other machines
- cass: search over your coding agent histories
What stood out:
- Trunk based dev is new to me. How will I feel about not reviewing any code? How to maintain code quality?
- I borrow the workflow from
ntm palette, which gives the base set of template prompts that he uses. - I like that agents can create beads and tag me to deal with them.
Planning
- I used Opus 5.5 to draft the first version of the doc, around 2k lines. I scan read it to make sure it looked good.
- Then used GPT 6 Pro in chatgpt.com to do a revision pass and suggest changes.
- Then back to Opus to synthesise.
- At this stage, I pasted it into the repo and got a fresh Opus 5.5 sub-agent and a fresh Codex agent to do adversarial review:
- Then told it to fix the 10 highest priority P3's, and committed this as the plan.
- Took me around 4 hours, on Sep 30.
⋯
Most effort went on the first prompt and the initial back and forth with Opus, in the claude.ai app. I also allowed the GPT Pro review to run for a long time and to make lots of changes / suggestions before synthesising. After that tbh I got a bit lazy. I figured the plan was "done" once reviewers converged on no new P1/P2 issues.
- I'm aware that I probably didn't read everything as closely as I should. Plan fatigue is real. I'm trying to solve this in another project of mine (
auto plan) to make plans easier to digest. Not sure that a huge MD file is a good way for a human to consume this data. - I also learned that when you ask an agent to review a large file, it will effectively sample it. It might miss a lot, especially in a large plan.
- There is also a lot of churn, as subsequent reviewers will re-review stuff that's already been reviewed and find new issues. Need to gate this somehow.
Next time I'd probably encourage the plan builder to use less text, more diagrams, etc. But I'm not sure tbh, this is an ongoing problem I'm thinking about.
Running the swarm
Once the doc was finished, I used my main Claude driver to get a single agent working on the first stages. It completed it and picked up the next work item.
Agent mail UI is also kinda cool, fun to see the agents talking to each other.
I also like the pattern of using 1x ntm Claude to control the others. I just talk to this one, and it manages, grows and shrinks the rest of the swarm.
To be fair, I'm not even sure if this is actually from Jeffrey Emanuel's workflow. His workflow says that a human should keep an eye on the sessions and nudge them every fifteen minutes. I thought it would just be easier to get an agent to do this for me, and it would do a better job at interpreting the issues than I could, especially as I hadn't really read the code and might not understand some of the more technical questions it could ask. Probably not what I'd want in a commercial project.
It did most of the work of nudging the other agents. When it had a technical question, I mostly just accepted the recommended replies, and then my input was mostly just nudging the supervisor to nudge the workers.
how we doing?
yes nudge everything along
how we doing
anything else we can nudge along?
File locks
The most novel technique here for me, is how you can use file locks to prevent agents from overwriting work when they're committing to main. So far this has worked pretty well, with, at least from what I can see, no major conflicts or problems caused by multiple agents trying to edit the same file at the same time.
The worker nodes seem to spend quite a lot of time waiting for beads to become available or for file locks to be released. So yeah, it was pretty cool when you would see one idle for a bit, then it would check the messages, come back alive and continue its work.
No code review
I've not reviewed any of the code, which is fine. It wouldn't really make much of a difference anyway, because I don't really understand Rust, so I wouldn't even know if what I was looking at is good or not. I did use linting to try to keep the code cleaner, but in terms of big picture architecture, I'm still kind of uncertain how everything fits together.
e.g here, me trying to understand some of the concensus mechanics:
I still probably need to do a wave of probing and testing on the finished build, to make sure that it actually works and to get a better sense of what we've actually created here.
Bumps along the way
Bad luck with a cheap Hetzner box, and probably a fair bit of user too stupid. For the issues that I ran into, I mostly just got the agents to fix them.
Oct 3: core dump. I did get a core dump crash that happened whilst doing tests on a clean checkout.
ok something happened to another agent in this ntm session and it crashed and core dumped, can you take a look?
- UBS scanning a file starts about 990 ast-grep processes at once, which hit systemd's per-agent process cap on a 2 CPU box and took Claude Code down with it.
- A shared
CARGO_TARGET_DIRmeant two checkouts reused each other's builds, so checks could falsely fail.
UBS was the trigger, but really this is a very small machine (4gb ram, 2 cpu). So, some minor infra issues that slowed us down.
Oct 3: box too small. 4gb ram isn't enough, so I had to pause everything and restart.
I upgraded to the next largest Hetzner box, a 4 CPU, 8GB machine, and it's run fine.
The recovery story is a bit tricky. I restarted the machine to upgrade it and had to piece together the old sessions. Maybe I missed a ntm feature for this. But it would be nice if I could do a better job of auto-recovering sessions.
Oct 3: dangling agent mail. I got the master driver to restart / clean up some old ntm agents so they were all on Opus 5.5. This left some dangling agent mail references, probably my fault for killing them mid-session.
Oct 6: the queue freezes.
I was clearly getting a bit annoyed here :)
workers still arent doing anything
what the fuck is blocking this? give me the low down. how can we reset and continue? and there are uncommitted code changes.
About an hour of nothing happening. Here's what the agents eventually dug out:
- The tracker db broke. beads (
br) stores everything in FrankenSQLite. A WAL-index recovery failed, and after that everybrcommand refused to run withSYNC_CONFLICT. Fourth time that day. - Recovery made it worse.
brauto-recovers when it hits this. But every agent was callingbrat once: the dispatcher loop my agents had set up polling every 5 mins, the workers retrying their commits, the coordinator running manual repairs. The recoveries collided mid-flight ("database is busy (recovery in progress)") and re-broke the db almost as fast as it got fixed. There were 200+ failed recovery snapshots sitting in.beads/.br_recovery/. - One stuck worker froze for everyone.
./dev commitcallsbrto check the bead, so CobaltDog couldn't commit. It (correctly) refused to repair the shared tracker on its own and just sat there, holding the file lock onregistry/checks.tomlandxtask/src/check.rs. All three workers needed those two files to register their checks, and my plan banned worktrees, so it's a strict serial queue. Claude called it a "lock convoy". - Side issue. ntm's dispatcher was reserving files under made up names (
keyval_claude_1.3) instead of the agents' real agent mail names, so new assignments failed withASSIGNMENT_FAILED.
could a nuclear option of just clearing all uncommitted git changes and restarting ntm session help
Codex talked me out of the nuclear option: it wouldn't fix the db, and it would have thrown away ~1,500 lines of finished but uncommitted work.
The fix. Codex paused the ntm supervisors, ran one clean br doctor migrate-schema recover with nothing else touching the db, and talked to the workers over plain tmux instead of ntm. CobaltDog's commit landed with all 102 gate steps passing, then the other two went through one at a time. About 15 mins once Codex took over.
Needed a lot of supervision at this point.
Slow commits. The verification pipeline needs to be carefully built, because currently it takes about four minutes to run the commit hooks, which is quite a long time. This would be one of the first things I'd consider optimising before working on this more. Maybe by splitting it to run shorter verifications more often aka scaling test-time verification in the words of Alex Lavee.
The cost
I ran through my $200 a month Claude Max subscription in about a day of the swarm starting (Oct 3 → Oct 4), so I had to pause it and wait for the reset on Monday Oct 5 to be able to continue.
Next thing I realised was that all sessions were slamming up to Claude Code's default of like 95% context window before compacting, which probably used my token usage up a lot more. I couldn't find a way of managing agents running out of context in the tooling, but that might just be me. So I changed this to 200k tokens in Claude config and switched the workers to Sonnet. It seems to be fine, I've not run out of a subscription since.
When I was waiting for the limits to reset, I asked Codex to have a look at my Claude sessions:
Even after the optimisations, it said that we would need between three and four Claude Max $200 a month subscriptions to be able to run this 24/7, which would be about $800 a month. It makes sense that if you were going to be doing this 24/7 you would need a lot of subscriptions. Pretty cool!
Verdict
How important your verification stack is.
This repo built some pretty cool scripts for committing and running different levels of compliance checks at different points in the workflow.
Trunk based development can be pretty effective with the file lock system, and it means that code gets deployed much quicker, because you don't have loads and loads of pull requests waiting for your review. If this project was built using a pull request review workflow, it would have taken much, much longer, because we would have had hundreds of PRs just stacking up that need reviewing, which would block current work.
So for going from zero to something that's kind of usable and deployable, this is kind of unmatched, as long as you're happy not to review the code.
For my next steps, I'm definitely interested in incorporating some of these ideas into my own workflows to see what difference it makes. Trunk based development is a fun way of doing things, particularly for a demo project or experiment project where you may be a bit less worried about code quality and bugs.
One big blocker though: most of my other projects require a more complicated development environment to test out their changes, and services that it can test and run against. Think PostgresDB x Blob Storage emulator x Auth emulator, etc. Could cause problems if you had multiple agents on main all trying to deploy schema updates and test them on the same stack. This would probably be a blocker for doing this in a few of my other projects, and my actual startup projects with paying customers.
Questions I'd ask JE
- Could I do a better job of auto-recovering sessions after a restart?
- How do you manage to answer complex technical questions from agents mid flow that you don't have enough context on?
Next experiment
My next experiment might be a similar run down using Gas City. Gas City is not opinionated about the development workflow and looks more like an orchestration layer, as opposed to Agent Flywheel which is more opinionated about the SDLC.
Still got 80 beads to go on this project though, so will complete that and give it a test drive myself first.
Fin :)