Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems
Abstract
Production AI agents' failures are less often due to an inability to reason well and more often because they cannot manage what is in their reasoning context: conversation histories, large prompts, large tool definitions, and ballooning tool outputs. Agents drown in their own accumulating history while paying a token cost that grows every turn, producing missing recalls within and across conversations. The incumbent response treats this as a storage-and-retrieval problem. We argue that framing is too narrow. Actively managing what an agent holds in mind is a lifecycle, not merely a store: it spans deciding what to remember, extracting and structuring it, choosing the right store per data type, consolidating and forgetting while preserving provenance, deciding what is relevant now, anticipating what is needed next, and compacting context to a budget without losing what matters. In serious production this operates not over a single user but across an organizational scope hierarchy. We name this discipline Agentic Context Management (ACM) and decompose it into five primitives: architecting, ingesting, scoping, anticipating, and compacting & consolidation. We then make the economic case: naive context accumulation grows token cost quadratically in conversation length, crude summarization buys linear cost at the price of an accuracy cliff, and only validated compaction achieves linear cost with preserved fidelity. We describe a reference implementation, Maximem Synap, that realizes the five primitives as a multi-tenant service and reports 92% on LongMemEval and 93.2% on LoCoMo under the configuration detailed in Section 6. We close with dimensions existing benchmarks do not yet capture, latency, token efficiency, and context-rot resistance, and the frontier of decision-level and organization-level context the category points toward.
Community
Author here.
Short version: most agent memory failures are not reasoning failures, they are context-management failures, and the field keeps treating that as a storage and retrieval problem when it is really a lifecycle and architecture problem.
We break the lifecycle into five primitives (architecting, ingesting, scoping, anticipating, compacting and consolidation) that operate across a user, customer, client scope hierarchy, and we make the cost case: full-append context grows quadratically, crude summarization buys linear cost by dropping accuracy, and only validated compaction gets linear cost with fidelity intact.
The reference implementation (Maximem Synap) reports 92% on LongMemEval and 93.2% on LoCoMo with a smaller answer model (gpt-5-mini). The eval harness and a file-vs-vector retrieval study are linked in the paper, so you can poke at the methodology.
Would really value feedback from people running agents in production, especially on the scoping and forgetting pieces.
I've been running agents in production long enough to know that context management is the silent killer — and this paper names it correctly as a lifecycle problem, not a storage one. The framing of "what the agent holds in mind" vs "what it can retrieve" maps directly to the failures I see: agents that can find the right document but still hallucinate because the relevant bit got evicted from the window. What I'd want to see tested is how this holds up under real tool-calling load — when every function call dumps another 2K tokens of structured output back into the context. The paper's architecture makes sense on paper, but the eval needs to measure what happens when the agent is juggling five parallel tool calls and the context manager has to decide what to keep in real time. That's the regime where most context strategies fall apart. I'd also be curious about the overhead: how many tokens does the management layer itself burn per turn, and at what point does the cost of managing context exceed the cost of just paying for a bigger window?
Thanks for your comment.
Let me address the 2 aspects you have questions/ concerns on:
- Eval needs to measure what happens when agent is juggling five parallel calls: 100% agree, and it is something we call out in the paper. We are producing and will soon ship a new eval mechanism that isn't as static as the existing alternatives
- Overhead: We did cover the overhead in the paper; and it is an important piece for us. By using the overhead + compacted context; agents still use 40-90% lesser tokens empirically and mathematically.
Happy to answer any further questions.
This is an automated message from the Librarian Bot. I found the following papers similar to this paper.
The following papers were recommended by the Semantic Scholar API
- Oracle Agent Memory as an Enterprise Memory Substrate for Long-Horizon AI Agents (2026)
- Less Context, More Accuracy: A Bi-Temporal Memory Engine for LLM Agents Where a Lean Retrieved Context Beats the Full History (2026)
- User as Code: Executable Memory for Personalized Agents (2026)
- Agent Memory: Characterization and System Implications of Stateful Long-Horizon Workloads (2026)
- Why Git Is the Memory Solution for the Agentic Development Lifecycle (2026)
- Exploring Cross-Scenario Generality of Agentic Memory Systems: Diagnostics and a Strong Baseline (2026)
- TRACE: State-Aware Query Processing over Temporal Evidence Graphs for Conversational Data (2026)
Please give a thumbs up to this comment if you found it helpful!
If you want recommendations for any Paper on Hugging Face checkout this Space
You can directly ask Librarian Bot for paper recommendations by tagging it in a comment: @librarian-bot recommend
Get this paper in your agent:
hf papers read 2607.21503 Don't have the latest CLI?
curl -LsSf https://hf.co/cli/install.sh | bash Models citing this paper 0
No model linking this paper
Datasets citing this paper 0
No dataset linking this paper
Spaces citing this paper 0
No Space linking this paper