You ask your AI assistant to remember what happened today. Tomorrow, you do it again.
Eventually, the project memory contains old blockers, temporary experiments, completed fixes, and decisions that have changed. The information you need may still be there, but it takes more work to determine which parts remain true.
Keep durable project context in memory. Give daily activity and current execution state their own places.
This article is about the project files you maintain and provide to an assistant. It is not a claim that every product’s built-in memory behaves the same way.
Preserve the decision behind the activity
A daily log is useful when you need to reconstruct events. Project memory has a different purpose: helping the next session understand the decisions and constraints that still guide the work.
Consider this illustrative memory entry:
Monday: tried automatic follow-up emails.
Tuesday: email setup failed; investigate next session.
Wednesday: owner chose manual follow-ups for the first release.
Thursday: changed the status label and fixed a mobile spacing issue.The approved scope decision is surrounded by activity. The old instruction to investigate email setup may also look like unfinished work, even though the decision has changed.
A more useful durable entry would be:
## Approved scope
The first release uses manual follow-ups.
Automatic email follow-ups are outside the current release scope.
## Decision source
See the approved first-release requirements and follow-up decision record.
Revisit automation only after a new scope decision.This example uses a hypothetical project. It is not a report of a real implementation or a measured improvement.
The other events can remain in an appropriate history record. They do not all need to travel into every future session as active guidance.
Sort information by the job it needs to do
| Information | Suggested home | When to update it |
|---|---|---|
| Purpose, approved scope, lasting constraints | Project memory | When an approved durable fact changes |
| Current objective, blockers, checks, next action | Handoff | When the execution state changes |
| Completed material changes | Changelog | After the change is completed |
| Detailed sequence of daily activity | Daily note or work log | When the history is useful to retain |
| Unapproved ideas and possible improvements | Inbox or backlog | As proposals evolve |
| Detailed rationale for an important choice | Decision record | When the decision is approved or superseded |
These roles matter more than the exact file names. In KOS, memory.md, handoff.md, and changelog.md make the distinctions explicit.
Keep enough information to explain a decision, including its source where useful. Moving everything out of memory would leave an equally unhelpful summary.
Use a review test for every entry
Before adding a statement to memory, ask:
- Is it verified or explicitly approved?
- Will it influence future work beyond the current task?
- Does it replace or conflict with an existing statement?
- Can a future reader tell where it came from?
A temporary blocker usually belongs in the handoff. An unapproved suggestion belongs in the backlog. A lasting compatibility constraint belongs in memory, with a link to the evidence or decision behind it.
There is no universal line count that makes memory correct. A short file can still contain a wrong decision. A longer file can be justified when its contents remain relevant and maintainable.
Let AI propose the cleanup
Start with a single project’s memory. Use a review prompt such as:
Review this project memory alongside the approved requirements and current handoff. Identify durable facts, temporary status, historical activity, unsupported claims, and contradictions. Propose a cleanup and a destination for anything moved. Preserve decision rationale and unresolved issues. Do not turn unapproved suggestions into accepted decisions.
Inspect the proposed changes before accepting them. Pay particular attention to scope, ownership, dependencies, and unresolved blockers. A polished summary can still omit a constraint the next session needs.
When a decision changes, update the active statement and preserve its history where appropriate. Simply appending the new decision can leave two incompatible instructions in the next session’s context.
Check the result in a fresh session
Give the next session the approved memory and current handoff through the file access or attachment mechanism your tool supports. Ask it to identify:
- The project’s purpose and approved scope.
- The constraints that affect the next task.
- What is verified and what remains uncertain.
- The next action it is authorized to take.
If it revives a resolved blocker or treats an idea as approved scope, trace the answer to its source. Correct the context before expanding it.
Anthropic’s context-engineering guidance discusses keeping relevant context focused and using structured notes across sessions. The memory, handoff, and changelog split here is a practical project-maintenance convention, not a promise of better results from every model.
For a complete continuation example, read Stop Re-Explaining Your Project to AI. For an ongoing review routine, see The Second Brain Maintenance Model.
Start with the KOS Starter Kit and maintain one project’s context before expanding to the rest of your workspace.
Keep the history you need. Give the next session a clear account of what still applies.