Task-State File
A per-task working file (TODO.md, checkpoint.md) tracking the current job's plan, progress, and open questions, deliberately deleted at task completion.
When to use
Working memory for any multi-step task; the artifact form of checkpoint-resume and compact-and-continue.
Specification
| Memory type | working |
|---|---|
| Storage | one flat file per task, lifecycle-bound to the task |
| Retrieval | always loaded during its task; never loaded outside it |
| Update method | agent-written continuously; reconciled on resume |
| Decay / staleness handling | Deletion at completion is the design: working memory that outlives its task becomes noise in the long-term store. |
| Risk level / maturity | low / established |
Privacy and safety
Low, task-scoped; the leak risk is content migrating into long-term memory without review.
Failure modes
- File not deleted, polluting future context
- State drifting from reality between sessions
- Long-term facts buried in a file about to be deleted
Assessment
The boundary discipline is the pattern: task state lives here and dies here, and durable learnings must be explicitly promoted to long-term memory before deletion, not left to fate.
Evaluation method: Cold-resume test: can a fresh session continue from the file alone?