The loop

A way of executing work that survives the two things that reliably wreck long agent sessions: drift, and declaring something done without evidence.

It is a discipline rather than a program. The gates are the whole product.

The phases

diagnose  →  research  →  design  →  plan  →  implement  →  verify  →  ship gate

Each phase has an exit condition, and the order is fixed.

Diagnose — name the actual problem before touching anything. The reported symptom and the defect are different objects, and the gap between them is where most wasted work happens. Exit when you can state what is wrong, not what looks wrong.

Research — establish what is true and how you know it. This is where a claim earns the word "because". Durable findings go to research so the next session inherits them instead of re-deriving them. Exit when you can state the cause rather than the symptom.

Design — only for work with unknowns: a schema, a contract, an assumption about code nobody has read. Skip it for genuinely small work; don't skip it out of impatience.

Plan — turn the shape into ordered steps, each with a checkable outcome.

Implement — one step at a time, on a branch. No step starts before the previous one is verified.

Verify — evidence, not vibes.

Ship gate — the loop stops here. Committed and verified locally is a terminal state, not a pause on the way to a push. The decision to release belongs to the person running the work, and the loop's last act is to say plainly what is done, what was verified, and what is still open.

Evidence before done

A step is done when you can point at something: a passing test named by count and suite, a command whose output is shown, a probe of the surface you actually changed.

"The change looks right" is not evidence. If you can't produce any, the step isn't done — it's in progress, and saying so is the useful thing to do.

Issue routing

When something goes wrong mid-flight, classify it before reacting:

The third row is what protects a plan from dissolving into whatever was noticed most recently.

Scope protection runs both ways

Scope discipline is usually described as "don't do extra". It fails in both directions, and the second is more damaging:

• Don't expand. Work found mid-step becomes a follow-up, not a detour.
• Don't shrink. Quietly narrowing a task to the part that's easy is drift wearing a disguise. If the scope should shrink, that's a decision to state, not one to make silently.

Confidence gates hypotheses

A plausible cause that hasn't been distinguished from the alternatives is still a guess. Either test it or label it — building on an untested hypothesis wastes all the work that follows.

Surviving context loss

Long work outlives the conversation that started it. Durable findings belong in research; the plan's current truth belongs in a plan.

A handoff is the explicit version of this: the state of the plan, what was verified and how, what is in flight, and the next action — written down rather than remembered. It is worth producing at the end of a session, and worth reading before resuming one. A handoff that only lists what was done is half a handoff; the useful half is what is not yet true.

When to use it, and when not to

The loop is overhead, and overhead is only worth paying when the work can go wrong in ways you would not notice.

Worth it when the task spans more than one session, touches code you have not read, has a cause that is not yet established, changes a contract or a schema, or is being run with fewer interruptions than usual. Those are the conditions under which drift is invisible and "done" is easy to declare wrongly.

Not worth it when the change is small and its correctness is obvious on inspection — a typo, a copy tweak, a version bump, a one-line fix to code you just wrote. Running the full ceremony there produces artifacts nobody will read and slows down work that was never at risk.

The judgement is about matching ceremony to risk, and it is a real judgement — treating every task as loop-worthy is its own kind of drift.

What it never does

The loop does not push, merge, deploy, or release. Its terminal state is committed and verified locally, with a clear statement of what's done and what's next. Shipping is a decision for the person running the work.

Next: Research.