How memory is written & ingested
The write pipeline. Raw conversation in, durable memory out: extract candidates (multi-pass), verify them, classify into a schema, dedup by content-address and supersede stale values: before anything is persisted. Each pattern is sourced to a framework doc, a first-party engineering post, or an arXiv paper.
Content-Addressed ID + Dedup
WriteMulti-Pass Extraction
WriteVerification Gate
WriteClassification Routing
WriteWrite-Time Fact Extraction (ADD/UPDATE/DELETE)
WriteSupersession (version chains)
WriteSummarization / Compaction
BothReflection / Self-Edit
WriteLifecycle Hooks (pre / post-message)
BothExtract, verify, classify, dedup, supersede: the write pipeline
Harvest is the write path: what gets remembered, when, and in what form. It is the least-specified part of most agent stacks and the one that quietly determines everything downstream.
Show more
Write too much and retrieval drowns in noise; write too little and the agent has no continuity. The approaches that hold up extract structured facts at the end of a run rather than storing raw transcripts, because a log is cheap to keep and expensive to search.
How does an agent decide what to remember?
An extraction step reads the conversation and pulls out the parts worth keeping as separate facts, instead of storing the whole transcript. Each candidate is checked, given a type, and only then written. Everything else is dropped or left in the raw log.
Should I store the whole conversation or just extracted facts?
Both, for different jobs. Raw transcripts are cheap to keep and useful when debugging, but noisy and expensive to search. Extracted facts are what the agent actually retrieves. Most stacks keep the log and index the facts.
When should memories be written, during the conversation or after?
After the turn, or at the end of the run. Extracting mid-turn adds latency to the reply the user is waiting for. Running it after the response, or as a background job, keeps the conversation fast and lets the extractor see the whole exchange.
How do you stop duplicate memories piling up?
Derive each record's id from a hash of its content, so writing the same thing twice does nothing. That catches exact repeats only. Near-duplicates worded differently need a separate pass that compares meaning and then merges or replaces.
What happens when a new memory contradicts an old one?
The write step should settle it rather than store both. The usual approach is to look up existing memories on the same subject first, then explicitly add, update or delete. If contradictions are allowed to accumulate, retrieval returns both and the model picks one at random.
When should a conversation be summarised?
Once the history grows longer than is useful to keep word for word. Older messages fold into a short summary that stays in context while the raw turns move to storage. It keeps the gist inside the context window at the cost of detail you cannot recover.