Why bwmem sleeps: consolidation in long-running agents

Most agent memory demos are a vector store with a nice wrapper. Embed every message, search on each turn, paste the top k into the prompt. It works beautifully for a week. The trouble arrives somewhere around month three, and it is not a bug — it is the design working exactly as specified.

What append-only memory does to you

Three things go wrong, and they compound.

Recall degrades as the corpus grows. This is the counterintuitive one. More stored memories means worse retrieval, because the nearest neighbours of any query become a crowd of near-duplicates. A user who has mentioned their job forty times across six months has forty embeddings clustered in almost the same place. Ask "where do they work" and you retrieve ten copies of one fact, having spent your entire context budget learning one thing.

Nothing ever becomes false. A vector store has no opinion about time. "I live in Tokyo" from March and "I moved to Berlin last week" from September are both simply present, both retrievable, equally weighted by cosine similarity. The agent does not become wrong so much as it becomes simultaneously right about incompatible things, which is worse, because it will confidently pick whichever one embeds closer to the question.

Cost scales with history, not with relevance. Every turn embeds, every turn searches a larger index, every turn stuffs more into the prompt. The agent's running cost rises for its most engaged users. The design punishes you precisely where it is succeeding.

An agent that only appends is an agent that eventually drowns — not in what it forgot, but in everything it kept.

Consolidation is the part that gets skipped

The borrowed intuition is sleep. Biological memory does not simply accumulate: it replays, compresses, discards, and moves what survives from episodic storage into something more durable and more general. The useful part of the analogy is not romantic, it is architectural. Writing and consolidating are different operations on different schedules, and neither belongs in the request path.

bwmem runs consolidation at three cadences, and the reason there are three is that different kinds of structure only become visible at different time horizons:

• Episodic, at session end. Summarise what happened, extract structured facts, note the topics. This is where a conversation stops being a transcript and becomes a small number of claims.
• Daily. Reconcile the day's facts against what was already believed. Merge duplicates, supersede what changed, surface contradictions. Cross-session patterns are invisible from inside any single session.
• Weekly. Compress further, and let genuinely cold material fall away. What survives a week of not being recalled is usually not needed.

Each pass costs LLM calls, which is exactly why it belongs in a background queue and not in the turn the user is waiting on. Consolidation is the part that makes the system cheaper in month six, so it is also the part that looks like pure overhead in week one. That is why it gets cut.

Facts are not messages

The single change with the largest effect: stop treating retrieved text as the memory. Extract facts — key, value, confidence, provenance, timestamp — and store those alongside the embeddings.

Once memory has a shape, several previously hard problems become ordinary:

• Deduplication becomes key comparison plus value similarity, not a hope that the vector search happens to spread its picks out.
• Supersession becomes possible at all. "Lives in" is single-valued; a new value replaces the old and the old keeps its dates. "Speaks" is multi-valued; a new value joins the set. The distinction has to be declared, because no amount of embedding will infer it.
• Contradiction becomes detectable, because you are comparing claims rather than paragraphs.
• Context assembly becomes a budget you allocate deliberately across several sources — facts, recent messages, summaries, emotional high-points, graph neighbours — instead of whatever ten chunks the index returned.

That last point is the one that changes the prompt most. Semantic search answers "what text resembles this query". It is a bad proxy for "what does the agent know about this person that matters right now", and treating the two as the same thing is most of why long-running agents feel eerily forgetful about basic things while reciting some irrelevant exchange from April.

Emotional weighting, minus the mysticism

bwmem scores moments on valence, arousal and dominance and keeps the outliers preferentially. This is not an attempt to give software feelings. It is a retention heuristic, and it earns its place empirically: the moments a person reacted strongly to are disproportionately the ones that matter later, and they are cheap to identify at write time.

Compression always needs a policy for what to drop. Recency alone throws away the important-but-old. Frequency alone keeps small talk. Affect is a third signal that correlates with significance and is nearly free to compute alongside the embedding you were already generating.

What this costs you

Consolidation is not free, and the honest ledger looks like this:

• It is lossy on purpose. The system will discard something you later wanted. That is the trade being made, not a defect — but it means consolidation must be inspectable, and destructive passes want provenance.
• It needs infrastructure. Postgres with pgvector, Redis for the queue. A background pipeline is a thing that can fall behind, and a consolidation backlog is a real operational state you must be able to see.
• It is asynchronous, so it is eventually consistent. A fact recorded one minute ago may not be reconciled yet. Anything that reads memory has to be correct in the presence of not-yet-consolidated writes.

All three are ordinary engineering problems with ordinary solutions. They are worth taking on, because the alternative is not "simpler" — it is a system that works impressively for a month and degrades, quietly, for the rest of its life.

bwmem is the memory layer from our own long-running agent, pulled out and published under AGPL-3.0 so it can be read and argued with. There is a longer write-up here.