Give Initialization Its Own Session
Explore how separating initialization into its own session improves the reliability of AI coding agents. Understand creating readiness contracts that define clear conditions, probes, and recovery steps. Learn to verify environment setup before feature work begins, preventing failed implementations caused by hidden setup issues.
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 ...