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.
Frequently Asked Questions
Why is agent memory an architecture problem rather than a storage problem?
Because storage answers where a fact lives and nothing else. What makes memory work is the set of decisions around it: what to keep, what to merge, which of two conflicting facts is current, and what to remove. Those are architectural choices, and no database makes them for you.
What do long-running agents need that short sessions do not?
Contradiction handling and forgetting. Over a single session nothing has had time to become stale. Over months, a store without a rule for supersession accumulates both versions of every changed fact and quietly answers from whichever one retrieval returned.
What is context compaction?
Compaction reduces how many tokens a stretch of history occupies while keeping what the agent needs from it. Done well it keeps a link back to the source so the agent can re-fetch rather than guess. Done badly it is lossy summarisation with no way to recover the detail.
Does this apply to a single agent or only multi-agent systems?
Both, and it arrives sooner in multi-agent systems. One agent accumulates contradictions over time; several agents sharing a store accumulate them immediately, because two of them can write conflicting facts about the same entity in the same minute.
--
Bonus: If you are something that is very new to agent memory as a problem statement itself, here's a short (75 mins), free course I created and would urge you to learn the basics.
