Give Initialization Its Own Session
Explore how to give initialization its own session in AI coding agent processes to ensure environment readiness before feature work begins. Understand the importance of readiness contracts, precise probes, and repeatable setup steps that keep environment issues distinct from implementation tasks. This lesson helps you create initialization gates that verify system health, data seeding, and configuration correctness to enhance overall harness reliability.
We'll cover the following...
- Didn’t the initialization command succeed?
- What belongs in the initialization phase?
- What should the gate prove?
- How should initialization report failure?
- Should initialization repair every failure automatically?
- Can you spot false readiness before work begins?
- What can you add to your harness?
- How do you test your contract?
- What’s next?
At 09:12, a new Wrenfold agent session executed ./init.sh. The dependencies were installed, the server process started, and the final line printed READY.
The agent opened CLIN-482 and began the recurring-booking change. Seventy minutes later, the end-to-end suite failed before reaching the new endpoint. CLINIC_TIMEZONE was missing, the database had no seed appointments, and the server’s health route had been returning 503 since startup.
Nothing had become ready. The script completed a list of actions, then printed a conclusion it never tested.
The agent spent its feature session discovering setup failures one at a time.
Didn’t the initialization command succeed?
A successful command is evidence only for the behavior it checked.
npm install returning zero proves the package manager completed. A process identifier proves a process exists. Neither proves the API can answer a request, reach its database, or exercise the seeded booking path.
Initialization fails when it treats activity as readiness. “Started the server” is an action. "GET /health returned 200 and confirmed the database connection" is an observed condition.
The same distinction applies to every setup claim:
A file exists vs. its required values parse.
A migration run against the expected schema is queryable.
A seed command finished vs. a known record can be read.
Tests exist vs. the canonical baseline passes.
Ground is the layer this lesson repairs, and it is why the reliability side of harness engineering starts before the first edit. A capable model cannot repair an environment problem that the harness mislabels as a coding problem.
What belongs in the initialization phase?
Initialization establishes the conditions that feature work depends on. It does not implement the feature.
For a new harness, give this work its own session. That session can create the setup command, validation probes, seed path, and first readiness report. Stop when another fresh session can reproduce the result.
Once the contract ...