What Is an Agent Flywheel? Why Most Spin Fast and Compound Nothing

A flywheel is supposed to get easier every turn. That is the whole promise of the word: you push once, momentum builds, and each rotation costs less than the last. So here is the uncomfortable question nobody asks about the "agent flywheel" everybody is suddenly building. If your agent is faster this week than last week, is your product actually compounding, or are you just spinning a heavier wheel harder?

Those are not the same thing. A flywheel that spins fast but stores nothing is just a fan.

#What an agent flywheel actually is

An agent flywheel is a loop where the output of each run becomes the input that makes the next run better. You point a coding agent at a task, it produces work, something checks that work, and what it learns feeds back in so the next task starts from a better place. Turn after turn, the wheel picks up speed on its own.

The term is having a moment because the pieces finally ship inside the tools. Augment Code describes its version as a four-stage loop: execute, coach, distill, improve, "to compound AI agent gains across sessions instead of" starting cold every time. Google's developer team shipped a quality-flywheel skill that automates testing and grading so prompt tweaks stop silently breaking your agents. Even on Hacker News, builders trade notes on their own agent flywheel workflow, with one describing it honestly: it "feels a bit like using power tools to shape wood but the final product needs a lot of sanding and polishing."

Read those three descriptions again and notice what they have in common. Execute, then grade. Build, then check. Produce, then verify. The flywheel is not the agent going fast. The flywheel is the loop that turns each run into something the next run can stand on.

#The part that makes it compound

Here is the hypothesis this whole post rests on. An agent flywheel compounds only if each pass leaves behind a durable artifact the next pass reads. Take that artifact away and you do not have a slower flywheel. You have no flywheel at all, just a fast loop that forgets.

This is worth sitting with, because it contradicts the way the flywheel usually gets sold. The pitch is about autonomy: the agent runs, you walk away, it keeps going. But autonomy is the flywheel's speed, not its momentum. Speed without stored energy is exactly the fan problem. The agent can rip through ten tasks an hour and, if nothing accumulates between them, you are no further along than when you started, you are just further along faster.

What actually accumulates? Not the code. The code is the output, and output is not the same as compounding memory. What compounds is the record of intent and judgment around the code: what "done" meant for this feature, which decisions were already made and why, what got verified and what evidence proved it. Peter Steinberger, who built the open-source agent gateway OpenClaw and now works at OpenAI, put the shift bluntly:

Here's your monthly reminder that you shouldn't be prompting coding agents anymore. You should be designing loops that prompt your agents.

Peter Steinberger on X

The quote reframes the work. If you are designing the loop instead of driving it, then the thing you are actually designing is what the loop remembers between turns. That is the flywheel's mass. This is the same shift behind loop engineering: the leverage is not the agent, it is the system around it. Get the memory right and every rotation gets cheaper. Get it wrong and you are hand-pushing a fan that looks like a flywheel.

#Fast loop versus real flywheel

The difference shows up in one concrete place: what happens on the second, third, and tenth pass.

A fast loop starts every task from roughly the same spot. The agent scans the repo, re-derives what the code does, guesses at the conventions, and produces something plausible. It is quick, but there is no gradient. One builder on r/Anthropic described the tax precisely: the models "come back the next day to ask a simple question" and have to "scan your whole repo and think about what it does every time," so you "effectively get charged hundreds of times again for code that it wrote and knew better than you." That is a loop with no memory. Every turn pays full price.

A real flywheel starts each task from the artifact the last one produced. The plan for this feature already exists, with acceptance criteria written down. The decision to use a particular auth pattern is recorded, so the agent does not relitigate it. The last verification left evidence, so the next task knows what is already trusted. The agent does not re-derive; it reads. Each turn is cheaper than the last, which is the only thing that earns the word flywheel.

Put them side by side and the gap is obvious:

Fast loop: prompt, generate, ship, forget. Next task: scan the whole repo again, guess the conventions again, hope it lines up.

Real flywheel: plan with criteria, build, verify with evidence, record. Next task: read the plan, read what is verified, build on top.

The first one accelerates your typing. The second one accelerates your product.

#Where BrainGrid fits

This is exactly the gap BrainGrid is built to close, because the flywheel's stored energy is the thing it produces on purpose. You describe what you want, and the Planning Agent turns it into a requirement with real acceptance criteria, the questions you did not think to ask, the data model, the definition of done. That requirement is the artifact the loop reads on the next turn. The Builder Agent builds against it, in the BrainGrid Cloud sandbox with a live preview or in your own GitHub repo through Claude Code, Cursor, or Codex over MCP. Then every change is verified against those criteria, and a feature is not done until the evidence says it does what you intended.

Run that on the kanban, feature after feature, and the momentum is the point. Every criterion you write, every decision the plan captures, every verification that leaves evidence accrues to your product's record. The loop does not start cold on task eleven because tasks one through ten wrote down what they meant. That is a flywheel with mass. The agent forgets between runs. The record does not.

To be honest about the trade-off: building this way is slower on turn one. Writing a plan with acceptance criteria before the agent starts feels like friction when a raw prompt would already be generating code. It is friction. It is also the exact energy you are storing in the wheel. You pay it once, up front, and get it back on every rotation after. Skip it and turn one is faster, but there is no turn-ten payoff, because nothing compounded.

#What this means if you are building right now

If you are running a coding agent day to day, here is the concrete implication. Look at your third feature, not your first. On the first feature, a fast loop and a real flywheel look identical, both produce a working result quickly. The difference only appears once the work stacks. By feature three or four, the fast loop is re-deriving context it already had, generating conflicting patterns, and quietly slowing down, while the flywheel is speeding up because each feature stood on the recorded one before it.

So the question to ask about your setup is not "how autonomous is my agent." It is "what does my agent read at the start of a task that it did not have to figure out from scratch." If the answer is nothing, you have a fast loop. If the answer is a plan, a set of criteria, and evidence of what is already verified, you have a flywheel. Strip away every trend and every tweet about autonomy, and that single question is the whole game.

A flywheel is not defined by how hard you push it. It is defined by whether it keeps turning after you stop.

#FAQ

#What is an agent flywheel?

An agent flywheel is a loop where each run of an AI coding agent produces something that makes the next run better, so momentum builds turn after turn. In practice that means the agent executes a task, its output is checked, and what it learns or records feeds back in, so the loop compounds instead of starting cold every time. The key ingredient is a durable artifact between runs, a plan, acceptance criteria, or verified evidence, that the next pass reads rather than re-deriving.

#How is an agent flywheel different from just running an agent in a loop?

A plain loop repeats the same action, but nothing accumulates between iterations, so every pass starts from roughly the same place and pays full cost. A flywheel is a loop where each pass leaves behind something the next pass builds on, so it gets cheaper and faster over time. The difference is memory: a loop with no stored record is fast but flat, while a flywheel stores intent and judgment so the curve bends upward.

#Why does my AI coding agent get slower or more expensive over time?

Usually because it has no durable memory between tasks, so it re-scans your repository and re-derives what the code does every session. Builders report being "charged hundreds of times again" for context the agent already had, because nothing from the last run carried forward. The fix is to keep the source of truth outside the agent's context window, a plan and acceptance criteria the agent reads at the start of a task, so it does not pay to rediscover the same thing repeatedly. Keeping that record in a durable place the agent reloads, rather than in the chat it forgets, is the whole idea behind the state file pattern.

#What makes an agent flywheel actually compound instead of just spin fast?

A durable artifact that persists between runs. Speed alone is just autonomy, the agent going fast, and a fast loop that forgets accumulates nothing. What compounds is the record around the code: what "done" meant, which decisions were made and why, and what was verified with evidence. When each task reads that record instead of guessing, every rotation is cheaper than the last, which is what earns the word flywheel.

#Do I need acceptance criteria for an agent flywheel to work?

Yes, because the flywheel needs something to verify against, and criteria are what turn "the agent produced output" into "the output does what I intended." Without a written definition of done, the loop can run fast but cannot tell whether each pass moved the product forward or sideways. Acceptance criteria are the stored energy of the wheel: you write them once, and every future run reads and checks against them instead of relitigating what the feature was supposed to do.

BrainGrid is the plan-first app-building platform that turns your idea into a requirement with acceptance criteria, builds it with your agent, and verifies every change, so your agent flywheel compounds instead of spinning in place. Try it at braingrid.ai.