Agentic Context Management: Treating Agent Memory as a Lifecycle Problem

Source: arXiv — 2026-07-23

Summary

This paper argues that production AI agents don't usually fail because of weak reasoning — they fail because they can't manage their own context over long sessions, drowning in accumulated history while per-turn token costs climb the whole time. Instead of treating context management as a single retrieval problem, the paper reframes it as two distinct problems: a lifecycle problem (what happens to information as it ages — when it's compressed, summarized, or dropped) and an architecture problem (how context is structured and organized in the first place, not just what's retrieved into it). The proposal is a concrete framework for managing both.

Key Takeaways

• The failure mode being targeted is specific and common: an agent's context window keeps growing across a long multi-turn session (tool calls, intermediate reasoning, past results), and every turn gets more expensive and less focused even though the model's reasoning ability hasn't changed.
• Splitting "context management" into a lifecycle problem and an architecture problem is the paper's main conceptual move — most existing agent memory work (RAG-style retrieval, simple summarization) only addresses part of one of these, not both together.
• The lifecycle piece is about aging policy: deciding when a piece of context should be compressed, summarized, archived, or discarded as a session progresses, rather than keeping everything or naively truncating the oldest turns.
• The architecture piece is about structure: how context is organized and partitioned (not just what gets pulled in via retrieval), so an agent can address the right slice of its own history instead of re-reading everything every turn.
• The stated cost problem — token cost per turn rising as history accumulates — makes this directly relevant to anyone running agents in production against a metered API, not just a research concern.

Reel Script

Hook Your AI agent isn't getting dumber the longer it runs — its memory is getting more expensive and more cluttered, and that's a solvable architecture problem, not a model limitation.

Core Concept Picture an agent working a long task: it calls a tool, gets a result, reasons about it, calls another tool, and so on for dozens of turns. Every one of those steps gets stuffed into the context window — the model's working memory for that conversation. The problem is that context window just keeps growing, and since you're billed per token, every single turn gets more expensive than the last, even though the actual reasoning difficulty hasn't changed. Most fixes treat this as one problem — "just retrieve the relevant bits" — the way RAG systems do. This paper says that's incomplete: there are actually two separate problems. One is a lifecycle problem — think of it like deciding what to do with old files: keep them exactly as-is, summarize them into a shorter note, archive them somewhere else, or throw them out. The other is an architecture problem — how the remaining information is organized, so the agent can find the right slice of its own history instead of scanning everything every single turn, the way a well-organized filing cabinet beats a pile of loose papers even if both technically contain the same documents.

Hands-On The practical framework the paper lays out treats these as two separate, composable decisions you make explicitly rather than one implicit "just truncate the oldest stuff" policy: first, an aging policy — for each piece of context, is it still needed verbatim, should it get compressed into a summary, should it move to cold storage the agent can query on demand, or should it be dropped entirely — applied continuously as the session runs rather than only when the context window is about to overflow. Second, a structural policy — organizing what remains so retrieval within the agent's own history is targeted, not a full re-scan every turn. The paper's framing is useful even without adopting its exact method: if your agent's cost-per-turn is climbing on long sessions, ask separately "what's my aging policy" and "what's my structure," because a fix to one without the other leaves half the problem unsolved.

Takeaway If you're running agents on long sessions and watching token costs climb turn over turn, this is worth reading before you reach for "just add RAG" as the fix — retrieval alone doesn't solve the aging half of the problem. Treat agent memory as two separate design decisions, not one.

Discussion

(No questions yet — ask follow-ups via a Claude Code chat session on this repo; answers get appended here.)