Protocol
Give agent memory a write-manage-read policy
Memory is a loop, not a folder.
When it fits
- An agent can save notes or facts but the memory store is becoming noisy or stale.
When to avoid it
- Do not let automatic memory silently overwrite authoritative records; consequential updates may need human or source-backed confirmation.
Why it matters
Specify three operations: what earns a write, how stored items are updated or retired, and when retrieval should occur. Attach source, date or version to facts that can change. Merge duplicates and mark superseded decisions instead of endlessly appending. On read, retrieve for the current task rather than dumping the whole store back into context.
Steps
- A write rule says what is worth remembering.
- A management rule handles duplicate, stale and superseded items.
- A read rule specifies when and how memory is retrieved.
- Important facts keep provenance or a version marker.
An example
A project agent stores accepted design decisions and source links, updates them when the decision changes, and retrieves only decisions relevant to the component being edited.
Check your result
You can point to separate rules for creating, maintaining and retrieving memory.
Keep this limit in mind
- Do not let automatic memory silently overwrite authoritative records; consequential updates may need human or source-backed confirmation.
Connected ideas
Use beforeEvaluate what memory retrieves, not just what it stores
Evidence and sources
The memory-harness talk frames durable memory as a write-manage-read loop rather than a passive store.
The write, management and read policies need task-specific evaluation.
Memory Harnesses for Long-Running Research Agents · Memory is a write–manage–read loop