Most teams building AI agents are treating memory and inference cost as something the next model release will eventually fix. They believe that a bigger context window, a smarter retriever, a cheaper token rate, etc. would absolve the need for a system for solving agent memory.
This posture is convenient but it is wrong. What an agent remembers, when it forgets, and how much it costs to reason are architectural decisions. They get made long before any model is involved, and no amount of model improvement fixes a bad architecture underneath it.
Memory is a lifecycle, not a buffer
Most agent systems today treat context as one shared blob: everything goes in, nothing meaningfully comes out, and the "solution" to running out of room is a bigger window. That is not a memory system, it is a pile.
A lifecycle approach breaks this into stages that each need their own design:
- Ingestion: what gets written to memory in the first place, and at what granularity
- Scoping: what is relevant to this agent, this user, this task, versus what is just noise that happened to be nearby
- Decay: what loses relevance over time and should be forgotten deliberately, not accidentally truncated when the buffer fills up
- Retrieval: what gets pulled back into context for a given turn, and why
Treat these as one undifferentiated blob and you get exactly the failure modes everyone complains about: agents that "forget" things that mattered and "remember" things that did not.
Where the cost actually goes
Most of the token spend in agent systems is not the reasoning itself, it is carrying forward context that no longer earns its place. Every stale fact, every resolved sub-task, every turn of small talk that gets re-sent on every subsequent call adds up, and it adds up silently, because nothing in a shared-buffer architecture prompts you to ask whether that context is still worth its cost.
Getting this right requires treating cost as a lifecycle property too, not a line item you optimize after the fact.
We argue a methodology and 5 primitives would be a better approach
I wrote this up formally in a 23-page paper, "Agentic Context Management". It includes a full evaluation harness and the underlying study data, so the argument is not just conceptual, it is something you can check.
This is the same thinking behind the memory work we have been doing at Synap, now written up with data behind it.
Paper: arxiv.org/abs/2607.21503
Genuinely interested in where people think the lifecycle framing breaks down, especially anyone running multi-agent systems where scoping gets a lot harder.
About Author:
I am the founder of Maximem.ai - an agentic context management and agent memory company.
Top comments (4)
The lifecycle framing breaks down hardest at the scoping stage in multi-agent systems, specifically when multiple agents have overlapping write access to shared memory — because each agent's definition of "relevant to this task" may be locally correct but globally contradictory, and without a write-discipline protocol (what granularity, which predicate namespace, which entity-resolution rule) you end up with a graph of assertions that is internally inconsistent rather than a coherent memory substrate. The decay primitive is also the most under-implemented: most teams either skip it entirely (context pile), or implement it as a recency cutoff, which decays by time rather than by task-completion signal, so a resolved sub-task stays alive as long as it's recent. A stronger implementation ties decay to explicit state transitions — a fact's valid_until boundary is set at write time based on what event would make it false, not how old it is. The ingestion granularity choice compounds everything: coarse-grained writes are cheap but make scoping expensive; fine-grained writes make scoping cheap but impose write-discipline costs that most agent frameworks don't even expose as a configurable knob.
The write-discipline point is the missing operational layer. In shared multi-agent memory, provenance alone isn’t enough—each assertion needs scope, validity conditions, confidence, and a clear rule for resolving contradictions.
I’d measure memory like an inference system: tokens written and retrieved, retention time, stale-retrieval rate, contradiction rate, and the downstream latency, energy, and cost. That turns decay from a generic TTL into a control loop tied to task state.
The coarse-versus-fine granularity tradeoff is measurable too. The right unit isn’t the smallest fact; it’s the smallest fact that can be scoped, invalidated, and reused without dragging unnecessary context into the next call.
The lifecycle framing is exactly right. Context management is not just a retrieval-quality problem; it is a resource-allocation problem. Stale context can degrade reasoning while adding latency, cost, energy, and water impact on every future call.
I’d add one observability primitive: every memory operation should report why an item was retained or retrieved, its age and confidence, tokens injected, and marginal inference impact. That makes compaction, caching, and forgetting measurable instead of heuristic.
For multi-agent systems, scoping may need to happen at workflow boundaries—not only agent or user boundaries. The useful unit could be the context required for a specific decision, with an audit trail showing what was included, excluded, and reused.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.