The weakest AI workflow is a prompt that has to be rediscovered every time. Someone remembers the magic phrasing, copies the right paragraph, adds a warning, squints at the answer, and decides whether the result feels good enough. That can produce useful work. It cannot compound.
Prompts are starts. Context makes them situated. Harnesses make them falsifiable. Loops make them improve. Flywheels make the improvement reusable by the next person, repo, route, or agent run.
The ladder is the product
The useful progression is not "write a better prompt." It is prompt -> context -> harness -> loop -> flywheel. Each stage removes one kind of human memory from the process and turns it into a durable surface.
A prompt says what you want. Context says what the work is allowed to know and touch. A harness says how good will be judged. A loop says how the next attempt learns from the previous one. A flywheel says the whole mechanism now starts stronger by default.
Prompt
Name the task, constraints, refusal state, output shape, and decision boundary.
Context
Attach files, source receipts, prior decisions, current repo state, and ownership limits.
Harness
Convert "good" into replayable checks with failure messages that show the correct path.
Loop
Rerun the check, compare quality and correctness, and preserve the next command.
Flywheel
Promote the repeated loop into a default script, skill, route, gate, or visible ledger.
Stage one: prompt names intent
Prompts are still useful. They compress intent. They let a person point the machine at a shape of work before the code, files, or tools are fully organized. The mistake is asking the prompt to also remember policy, context, proof standards, release state, and recovery behavior.
A strong prompt should be small enough to survive contact with reality. It should say: here is the task, here are the forbidden moves, here is the output shape, here is what to do when evidence is missing. If the prompt has to carry everything else, the workflow is already waiting to drift.
Stage two: context names the real boundary
Context is where the work stops being generic. Which files matter? Which route is live? Which prior decision should not be reopened? Which user-visible contract is already tested? Which dependency is allowed to change? The prompt cannot infer those facts reliably every time. The context layer must provide them.
This is why repo memory, source receipts, route indexes, worktree status, and artifact paths matter. They are not decoration around the prompt. They are the difference between a plausible answer and a bounded action.
Stage three: harness names good
A harness turns the desired behavior into a command. That command might be a unit test, smoke script, schema validator, browser proof, design audit, deploy receipt, or route-specific canary. The important part is that it can say no before a person has to absorb the same defect again.
The harness also has to combine correctness and quality. Correctness asks whether the output satisfies the contract. Quality asks whether the output is useful, legible, bounded, and recoverable. A passing test with terrible failure text still leaks work back to the operator.
Stage four: loop names correction
A loop is not repetition. It is repetition with a sensor and a correction path. Run the canary. Read the failure. Patch the smallest surface that owns the defect. Rerun the same command. Escalate only when the claim widens. Leave the next command behind.
Without that discipline, the workflow becomes random escalation. A small prompt issue turns into a model swap. A missing route marker turns into a search rewrite. A slow downstream dependency turns into a new architecture. The loop protects the system from anxiety-driven widening.
Stage five: flywheel names reuse
A flywheel exists when the lesson survives the session. The next operator does not need to remember the clever prompt, the hidden route, the fragile grep, or the failed deploy edge case. The repo knows. The script knows. The test knows. The ledger knows.
That is the compounding effect. Each shipped loop lowers the cost of the next loop. The first version may be a manual checklist. The second version becomes a script. The third version becomes a hard gate. The fourth version becomes a default habit. At that point, the prompt has become infrastructure.
Backpressure is the graduation test
The easiest fake flywheel is a happy-path loop. It passes one prompt, one fixture, one route, and one demo. Real flywheels have to survive pressure: too many jobs, slow consumers, rate limits, retries, cancellations, partial failures, and stale receipts.
Backpressure simulation is the test that asks whether the loop still tells the truth when the system is overloaded. Does it refuse new work cleanly? Does it retry with a cap? Does it preserve ownership? Does it say what failed? Does it leave a correction path? If not, the flywheel is still a demo loop.
Do not ask for a better prompt until you know which stage failed. If intent is unclear, fix the prompt. If facts are missing, fix context. If good is subjective, add a harness. If the same defect repeats, close the loop. If the loop helps twice, promote it into the flywheel.