Memory and State Management
Memory Consolidation — Stack
Memory consolidation › Stack
Technology landscape as of 2026-10-10. Knowledge cutoff May 2026.
Selection criteria
You are choosing how a recurring, expensive, lossy rewrite job is scheduled, isolated, resumed, and reviewed.
- Idempotency and resumability. Whether a pass that fails halfway can be retried without producing a second copy of the work it already did.
- Isolation from serving. Whether the job can run without competing with interactive retrieval for the same database connections, index, or rate limit.
- Cost control. Consolidation is a bulk model workload; whether the mechanism supports batch pricing, concurrency caps, and a hard spend ceiling matters more than its latency.
- Input selection. Whether the mechanism can define precisely which items a pass covers, so the output can name its range and be invalidated when that range changes.
- Atomic swap. Whether the derived item and the state change to its inputs can be committed together, or whether a crash can leave the store in a half-consolidated state.
- Review and rollback. Whether a pass can be inspected before its output becomes retrievable, and reversed afterwards by batch rather than item by item.
- Observability of drift. Whether the system records generation depth and the share of retrievals served from derived rather than primary items.
Options
| Option | Best for | Watch out for |
|---|---|---|
| Scheduled batch job (cron, Kubernetes CronJob, dbt-style scheduled transforms) | Predictable nightly consolidation over a bounded set | Runs regardless of whether a user is mid-session; a failed run is silent until someone notices stale output |
| Durable workflow per subject (Temporal, Restate, Step Functions) | Passes that must be resumable, retried safely, and observable per subject | Operational weight; one workflow per user is a lot of workflows and the engine becomes a dependency of memory quality |
| Stream processor with windowing (Flink, Kafka Streams, Materialize) | Continuous consolidation as events arrive rather than in nightly bursts | Window semantics and late arrivals are subtle; model calls inside a stream operator are an awkward fit |
| Lazy consolidation at read time | Stores where most subjects are never read and nightly work would be wasted | Latency spike on the unluckiest request; concurrent readers can trigger duplicate passes without a lock |
| Session-end hook in the application | Consolidating what a conversation established while the context is still available | Fires at an unreliable moment; sessions that end by timeout or crash may never trigger it |
| Batch inference APIs for the model calls (provider batch endpoints) | Large consolidation volumes where hours of latency are acceptable | Turnaround is not guaranteed; the job must tolerate results arriving long after the inputs changed |
| Managed memory services with built-in summarisation (Zep, Mem0, platform memory APIs) | Teams that want consolidation without building the pipeline | The summarisation prompt, cadence, and retention of inputs are the vendor's and change without your release |