Memory for Agent Loops
Long-running loops need memory strategy: what to keep, what to summarize, what to retrieve, and what to forget.
The recommendation is adapted into a bounded keep, summarize, retrieve, and forget decision table rather than treated as a product endorsement.
Open evidence sourceWhat should persist between runs, and what should be re-read from the live project instead of trusted from memory?
What we tested
We separated stable project instructions from one-run evidence. Package manager, validation commands, boundaries, and ownership rules belong in maintained instructions; current failures, diffs, command output, and blockers belong in a dated run note and must be refreshed.
Observed result
The split kept durable rules compact while preventing a previous run's conclusion from replacing current repository state. The next iteration could retrieve the last decision, but it still had to re-run validation and resolve conflicts against live files and configuration.
What this does not prove
The exercise does not compare memory products or establish an optimal retention period. Auto memory, instruction files, retrieval stores, and conversation history have different precedence and privacy behavior that must be checked in the chosen runtime.
Why it matters
Without a memory plan, a loop either forgets what it learned or drowns in context. Deciding up front what to persist and what to drop keeps loops both coherent and affordable.
Practical checklist
- Keep durable facts (goal, constraints, decisions)
- Summarize long histories instead of re-sending them
- Retrieve only the observations relevant to the next step
- Forget stale or one-off detail
Example
A multi-day refactor loop keeps a short “decisions so far” note, retrieves the files touched this session, and summarizes everything else — rather than re-reading the whole repo each run.
Common failure modes
Practical evidence
Keep, summarize, retrieve, or forget
Current goal, constraints, accepted decisions, unresolved blockers, and approval state.
Long run histories and completed investigation paths whose detail is no longer needed every turn.
The few prior errors, files, or decisions relevant to the next concrete action.
Superseded hypotheses, one-off logs, stale branches, and details contradicted by current source state.
A saved note says a test is flaky, so the loop ignores a new deterministic failure. Current repository evidence must override the old note.