The Init Phase Your Loop Is Skipping
Most loops start work on iteration one. That is the bug.
The agent reads its standing instructions, picks up the goal, and immediately starts changing things. No pause to confirm the world matches what the instructions claim. No check that the tools it thinks it has actually respond. It just goes. And when the first iteration fails — as first iterations do — you get handed a mess you can't cleanly read: was the work wrong, or was the environment never sane to begin with? You can't tell, because the run never separated the two.
That question is the whole argument for an init phase.
The tangle you're paying for
Call it the Blind First Iteration — the diagnostic is that iteration 1 fails and you can't say why without re-running it by hand.
Here's the mechanism. When setup and work share an iteration, that first iteration is secretly doing two jobs at once. It's the agent's first attempt at the actual task, and it's also the first time anyone confirmed the repo builds, the test command exists, the dependencies installed, the standing instructions still describe reality. Those are different failures with different fixes. A wrong approach means edit the plan. A broken environment means edit the machine. Fold them together and every early failure is ambiguous — and ambiguous failures are the expensive kind, because the debugging starts with "reproduce it and watch," which is exactly the manual work the loop was supposed to remove.
An init phase pulls those apart. It answers "is the environment sane?" before the loop is allowed to ask "is the work correct?" After that, a failure means something specific, because the other cause was already ruled out.
What actually belongs in init
Init is not a warm-up prompt. It's a short, bounded phase with a pass/fail of its own — the agent either confirms the ground is solid or it stops and says why. Four checks earn their place:
| Check | What it confirms | Skipped, you get… |
|---|---|---|
| Repo/stack matches the standing instructions | CLAUDE.md says "Next.js + Postgres, no ORM" — is that still true on disk? | The agent acts on a description that rotted three commits ago |
| The tools respond | Run the test/build/lint command once before trusting it in a loop | An iteration that "passes" because the test runner was never actually installed |
| Prior state is loaded | Read the memory/progress file if one exists, rather than assuming a cold start | Yesterday's finished work gets re-solved this morning |
| A known-good baseline exists | Confirm the repo builds green before the first mutating action | A red build after iteration 1 that you can't attribute to the change |
That last one is load-bearing. Establish that the repo is green before the agent touches anything, and the first failing build after a change is unambiguous: the change did it. Skip the baseline and green-before is a guess, so red-after tells you nothing.
Notice these are cheap. Running the test command once, reading one state file, one git status — seconds of work that convert every later failure from "reproduce and stare" into "read the message." Init doesn't slow the loop down. It's the fastest debugging you'll ever buy, paid once at the top instead of over and over on every murky iteration.
Not a new idea, and that's the point
The clearest standalone treatment of this we've seen is Learn Harness Engineering by Walking Labs — a genuinely good, theory-first course on building agent harnesses. Its lecture on why initialization needs its own phase makes the case directly: don't let bootstrapping hide inside the first work iteration, because setup mistakes and execution mistakes read differently and you want to keep them that way. It's worth reading in full alongside this if you're building harnesses seriously.
The idea shows up under other names too. The Plan stage of the Plan → Work → Review → Release harness is doing part of this job — a plan written to a file before work begins is context the loop verifies against instead of assumes. And The Anatomy of an Agent Loop makes the adjacent argument in its "build the harness before you automate anything" section: get one manual run reliable first, because a loop multiplies whatever is underneath it. Init is that principle enforced inside the loop, every run, not just once when you set it up — because environments drift, and a harness that was sane last week is not guaranteed sane today.
Give init a gate, not a vibe
If init can't fail, it isn't a phase — it's a comment. Give it a hard stop: if the baseline build is red, if the test command isn't found, if the state file is corrupt, the loop halts before iteration 1 and escalates. That's the same default-fail posture the directory grades every loop's verifier against, moved to the front of the run. A loop that refuses to start work on unproven ground is one you can actually leave alone overnight.
Add it to your harness the same way you'd add any stage: one bounded phase, its own artifact, its own definition of done. If you're assembling a harness from scratch, the loop builder is the place to wire the check in before the first work iteration — not after it's already burned a cycle you can't read.