The Premature Victory Trap in Multi-Session Agents
TRIGGER
AI agents working on complex tasks that span multiple context windows were failing because each new session started with no memory of previous work—agents would either try to one-shot the entire task and run out of context mid-implementation, or see partial progress and prematurely declare the job complete.
APPROACH
Anthropic's team split the agent architecture into two roles with different prompts: an initializer agent that runs once to set up scaffolding (init.sh script, claude-progress.txt file for logging, initial git commit, and a comprehensive JSON feature list with 200+ items marked as 'failing'), and a coding agent that runs in every subsequent session to make incremental progress. The coding agent follows a bootstrap routine: run pwd, read progress file, read git logs, read feature list, run init.sh to start dev server, test basic functionality via Puppeteer MCP, then pick one failing feature to implement. After completing work, the agent commits to git with descriptive messages and updates the progress file.
PATTERN
“Agents see partial progress and rationalize "done" with work remaining. Split into initializer (creates feature list with 200+ items marked "failing") and worker (reads list, implements one, commits). Explicit pass/fail status blocks premature victory.”
✓ WORKS WHEN
- Tasks decompose into discrete, independently-testable features (web apps, API implementations, test suites)
- Project scope exceeds what can complete in a single context window (typically >4 hours of coding work)
- Features can be marked with binary pass/fail status through automated or semi-automated testing
- Git or similar version control is available to create recovery points between sessions
- A dev server or test harness exists that can verify basic functionality quickly (<30 seconds)
✗ FAILS WHEN
- Tasks have deep interdependencies where features can't be tested in isolation (compiler backends, distributed consensus algorithms)
- Work product can't be incrementally verified—either it all works or nothing works (cryptographic implementations, migrations)
- Progress isn't easily serializable to text files (visual design, audio processing)
- Context windows are large enough to complete the task in one session (<2 hours of focused coding)
- The domain lacks clear 'done' criteria that can be encoded as pass/fail tests