Step 1 of 4
Design the todo data model and tool
Structured plans beat prose plans because the harness can enforce them.
Design a todo subsystem for the agent. Data model: a list of items, each with id, content (imperative phrase), and status (pending | in_progress | completed). Tool interface: todo_write(items) replaces the full list (simplest correct design - the model always sends the complete list). Harness rules to implement: reject lists with more than one in_progress item; reject status regressions from completed to pending without an explanatory note field; store the list in loop state, not in the message history. Write the tool schema and the validation rules first.
Expected after this step
A todo tool schema plus harness-side validation rules.
Should not happen
- ✕Letting the plan live only in the model's head where it evaporates under context pressure
- ✕Multiple items in_progress so progress becomes untrackable
- ✕Marking items complete without evidence the work happened
- ✕Plans created but never updated - a dead artifact instead of a working memory
Verify before continuing
Do not move on until every check is true. The complete button stays locked until then.
Do not continue if…
- !Letting the plan live only in the model's head where it evaporates under context pressure
- !Multiple items in_progress so progress becomes untrackable
- !Marking items complete without evidence the work happened
- !Plans created but never updated - a dead artifact instead of a working memory
If the AI messes this up
Use this when the AI fakes progress or breaks the feature. It forces a real fix.
The todo tool accepts partial updates and state is drifting. Switch to full-list replacement: the model sends the entire list every call, and the harness validates it as a whole - simpler and self-healing.