Most agent memory tools optimize two moments: write a fact, read a fact. This paper argues that agent context is a five-stage lifecycle — design the memory schema, ingest with structure, scope to the organization, prefetch what the next turn needs, and compact with validation — because unmanaged context cost grows with the square of conversation length, and one unvalidated summarization step can push accuracy below the no-memory baseline.
Production agents fail because of bad context more often than because of bad reasoning — that is the paper's opening claim. An agent accumulates conversation history, tool definitions, and tool outputs. Most hand-built agents re-send the whole history on every model call. That pattern makes token cost grow with the square of the conversation length. The obvious fix, summarization, fails in its own way: in one documented case, a summarization step compressed 18,282 tokens to 122, and task accuracy fell from 66.7% to 57.1% — below the accuracy with no context at all. The summarizer did not know what later turns would need, so it deleted it.
The author blames the framing. The industry calls this problem "memory". Memory names a store: a place to write facts and read them back. A store optimizes exactly two moments. A production agent must decide five things at five moments: what to retain, in what structure, which fraction belongs in this turn's context, what the next turn is likely to need, and what to do when the relevant context exceeds the model's budget. A store makes none of these decisions.
The paper names the discipline Agentic Context Management and splits it into five primitives. One disclosure first: the author founded Maximem, a memory-infrastructure vendor, and the paper's reference implementation is Maximem's own product. The taxonomy is the durable contribution; treat the product claims as the vendor's claims.
Architecting. Before the system stores anything, something must design the memory schema for this agent: which categories of information to capture, how long to keep them, how to compact them. A support agent and a coding agent need different schemas. The reference system generates the schema per agent with an LLM; most tools ship one fixed schema for every agent.
Ingesting. Raw turns and tool outputs must become structured facts with entities, relations, and the time range in which each fact holds. Extraction quality bounds retrieval quality: a system that stores "the user mentioned a pricing plan" can never retrieve "the user upgraded from Starter to Pro on April 3". Entity resolution also lives here — "Sarah", "Sarah Chen", and "SC" must map to one identity, or that person's history splits into three fragments.
Scoping. Memory operates in a hierarchy: the individual user, the customer organization, and the platform operator. Retrieval searches the narrowest scope first, and each scope is isolated from the others. Most memory tools scope to the user only. A flat store either loses the organizational context or leaks one user's data into another user's session.
Anticipating. Retrieval sits on the agent's critical path: every turn blocks on a round trip to the store before the model can answer. Speculative prefetch predicts what the next turn will need and prepares it before the request arrives. It also surfaces context the agent does not know it should ask for. The paper claims a hit rate above 60%, but gives no methodology, and the prediction mechanism is proprietary.
Compacting and consolidation. This is the paper's most portable idea: compaction must be validated. After the system compresses a conversation, it tests whether the key information is still recoverable from the compressed result, emits a validation score, and retries with less aggressive compression when the score falls below a threshold. Each pass re-compacts a bounded context plus recent turns, not the full transcript, so the validation overhead stays linear in conversation length.
Each primitive is anchored to a named production failure. One example: an audit of a popular memory library found 10,134 entries stored over 32 days, of which 38 were usable — a 99.6% junk rate from storing raw signals without extraction. The paper maps eight such failures (lost detail, identity fragmentation, scope bleeding, cross-session amnesia, blocking retrieval, the summarization accuracy drop, quadratic cost) to the primitive whose absence produces each one. That table works as an audit checklist on its own.
A side study compares keyword and vector retrieval across five corpora of 10,000 documents each. Vector search wins where the query and the answer share no words: natural-language-to-code scores 0.91 versus 0.29 on mean reciprocal rank (1.0 means the correct document always ranks first), because a query for "sort a list" must find a function named bubble_sort. Keyword search wins where terms are exact identifiers: science questions score 0.81 versus 0.61, because "mitochondria" is a key, not a concept. Building the embedding index also took 60 to 100 times longer than the keyword index. The author's conclusion: combine keyword search, vector search, and graph search (links between stored entities), because each covers queries the others miss. The study is small and self-run — one operator, one engine per method, no document chunking — and the paper labels it motivation, not a controlled benchmark.
The deeper observation: most retrieval benchmarks score a hit when one relevant document appears in the top results. An agent needs every document in its reasoning chain. Retrieving one relevant document while missing the bridge document that completes the chain is the failure that matters most for agents, and almost no benchmark measures it. The paper names this the reasoning-sufficiency gap.
The reference system, Maximem Synap, scores 92.0% on LongMemEval (500 questions over long multi-session chat histories) and 93.2% on LoCoMo categories 1–4 (question answering over conversations of roughly 300 turns), with gpt-5-mini as both answer model and judge. The weakest category is multi-session reasoning at 75.2% — questions that must join information across separate sessions. The paper reports this plainly as the reasoning-sufficiency gap described above.
Caveats. The vendor-comparison table reprints each vendor's self-reported number under that vendor's own methodology; the paper itself states the rows are not comparable. The system's internals are proprietary and not described. The paper reports no latency and no token-cost numbers, although its central argument is about both. One detail does support the reported scores: they were produced with a smaller answer model than the strongest competitors used, which suggests the context layer, not the answer model, supplies the gain.
Check your cost curve. If your agent re-sends its full history each turn, your input-token cost grows quadratically. A fixed context budget with periodic compaction makes it linear. At the paper's illustrative settings, the saving is roughly 80% at 100 turns and 96% at 500.
Validate your compaction. This transfers directly to any harness. After you summarize a conversation, ask a model whether the facts you care about are recoverable from the summary. If they are not, retry with less compression. An unvalidated compaction that drops a critical fact is worse than none, because the agent then answers confidently and wrongly.
Audit your memory store. Count how many stored entries are usable. Check whether one entity appears under several names. Check whether facts are stored with enough structure to answer the questions you will actually ask.
Combine retrieval methods. Keyword and vector search win on different query types. If your retrieval is vector-only, queries that use exact names and identifiers are your weak point; if keyword-only, paraphrased queries are.
Keep the integration surface small. The paper's whole lifecycle reduces to three calls around each model invocation: scoped retrieval of past context, validated compaction of the current conversation, and asynchronous ingestion of the new turn. That is a reasonable target shape for a home-grown context layer too.