When an Agent first joins a project, it usually feels like a new colleague with decent memory: you tell it where the repo is, what the conventions are, and what you changed last step — it keeps up.
By day three, things start going wrong. The chat log gets longer and longer. Tool outputs pile up like moving boxes. It forgets the original constraints but vividly remembers three rounds of failed commands. The bill goes up, and the answers get shorter. You think it lacks “memory,” so you wire up another vector database.
All you’ve done is install a bigger shelf at the door of the junk room.
A recent paper featured in Hugging Face Daily Papers offers a more useful framing: the Agent’s problem shouldn’t only be treated as storage and retrieval — it should be treated as context lifecycle management. This isn’t a product conclusion that’s been independently reproduced yet, but it accurately diagnoses the most common symptoms you see in engineering practice.
Paper: Agentic Context Management
0. The Real Enemy Isn’t “Not Enough Context”
When long-context models expanded their windows dramatically, many people developed a misconception: since you can fit more content, just stuff everything in.
This is like replacing your desk with a ten-meter-long table. A bigger surface doesn’t make you more efficient — it just gives your expired PRDs, last week’s error logs, half-empty bubble tea, and a stack of printouts more room to spread out.
An Agent’s context is the same. What it needs isn’t “everything that ever happened.” It needs “information that is necessary, trustworthy, and properly permissioned to complete this current task.”
If you blindly append the full history every round, costs compound and attention gets diluted by noise. Worse still, the model won’t solemnly warn you when the context is nearly full: “From this point on, I will only half-heartedly follow your instructions.” It just starts behaving like a polite colleague who hasn’t really read the requirements.
Lesson 1: Context isn’t a chat log — it’s working memory that can expire, get contaminated, and needs to be handed off.
1. Replace “Memory” with Five Operations
The paper decomposes this problem into five primitives: architecting, ingesting, scoping, anticipating, and compacting & consolidation. Translated into engineering language, they’re not mysticism — they’re basically five actions you encounter every day.
1. Architecting: First Decide What Qualifies as a Source of Truth
Many Agents’ memory has no boundaries from the start: things said in chat, webpage summaries, tool outputs, user-uploaded files — they all look like “knowledge.”
A more stable approach is to establish a source hierarchy first:
| Information Type | Where It Belongs | Trust Rules |
|---|---|---|
| Project conventions, interface contracts | Versioned documentation in the repo | Current committed version is authoritative |
| Runtime config, key state | Permission-protected config layer | Must not enter ordinary conversation context |
| Task progress, decision rationale | Structured task records | Must include timestamp and responsible party |
| Tool outputs, webpage results | Temporary evidence layer | Has an expiration; cannot auto-promote to fact |
If step one isn’t done, all subsequent “intelligent retrieval” becomes searching for a needle in a pot of soup of unknown origin.
2. Ingesting: Not Storing Full Text — Extracting Reusable Facts
Dumping a 5,000-token log into a vector database isn’t completing ingestion — at best it’s bagging the trash.
Information truly worth writing into the long-term layer should be able to answer these questions: what is it, where did it come from, which project is it valid for, when does it expire, who can see it.
For example, after a failed deployment, what lives on long-term isn’t the entire terminal output, but:
{
"kind": "deployment_constraint",
"fact": "Production environment is missing the image processor binary",
"scope": "project:rex-hugo / production",
"source": "deploy log #1842",
"valid_from": "2026-07-27",
"review_required": true
}
Next time the Agent needs to process images, it can retrieve genuinely useful constraints instead of doing archaeology through thousands of lines of npm output.
3. Scoping: The Same Sentence Means Different Things at Different Levels
“Don’t modify the payment logic” — is that a project-wide rule, or a temporary restriction for one bugfix task? “This customer is on the Enterprise plan” — user-level info, or org-level info?
Memory without scope easily cross-contaminates. One customer’s exception config becomes another customer’s default behavior. Last task’s workaround becomes the entire repo’s “convention.”
At minimum, distinguish four levels:
Organization-level: security, compliance, shared infrastructure
Project-level: code conventions, build commands, architectural constraints
Task-level: current objective, acceptance criteria, no-touch zones
Session-level: temporary reasoning, tool outputs, unverified assumptions
Reading order should also be fixed: first grab organizational and project hard constraints, then the current task, and only then allow session content to fill in details. Read them in reverse, and temporary noise easily drowns out long-term rules.
4. Anticipating: Prepare Before You Need It, Not Patch After the Fact
Good context management doesn’t only ask “what do I need to read now” — it also asks “what might I be missing next.”
For example, if the Agent is modifying the login flow, the next step will likely need test account policies, session expiry rules, and regression commands. Rather than discovering there are no test conditions after the change is done, list these as a context checklist at the start of the task.
This isn’t asking the Agent to predict the future — it’s explicitly surfacing dependency relationships that the engineer already knows.
5. Compacting: Before Compressing, Define What Cannot Be Lost
“Summarize the history” is one of the most dangerous — and most common — instructions. Ordinary summaries tend to strip out boundary conditions, failed attempts, and source links, leaving a few fluent but unverifiable sentences.
A usable compact should produce not just a natural-language summary, but also a verification table:
| Must-Preserve Field | Why It Can’t Be Lost |
|---|---|
| Current task objective | Prevents the session from drifting to another problem |
| Verified constraints | Prevents re-stepping into known pitfalls |
| Unverified assumptions | Prevents guesses from masquerading as facts |
| Evidence links / file locations | Lets the next round trace back |
| Next-step verification commands | Lets the task continue in a closed loop |
Compaction isn’t about making content shorter — it’s about making “what must the next executor know” clearer.
Lesson 2: Good context compaction isn’t a summary — it’s an evidence-backed handoff.
Figure: Long-term layer, task working set, and traceable evidence should be stored separately; compacted records must not be disconnected from their sources.
2. The Three Most Common Anti-Patterns
Anti-Pattern 1: Blind Full-Append
Symptom: Every prompt round includes the complete history, complete tool outputs, complete PRD.
Cost: Tokens burn like an all-you-can-eat buffet, while the model has to find the current task in a landfill. It might still work for short tasks, but for long tasks it inevitably gets slower, more expensive, and more erratic.
Alternative: Only keep the current task’s working set; load everything else on-demand through retrievable references.
Anti-Pattern 2: One Summary Covers Everything
Symptom: When the session gets too long, tell the model to “summarize and continue,” then throw away the original records.
Cost: If the summary is wrong, all subsequent reasoning is built on a wrong foundation — and you don’t even know which sentence the model fabricated.
Alternative: Summary should only serve as an index; original evidence must be kept in a traceable location. Critical constraints need structured fields, not just prose.
Anti-Pattern 3: Vector Database Without Permissions or Expiry
Symptom: All historical material goes into the same database; anyone who asks can retrieve anything.
Cost: Knowledge leakage, zombie policies coming back to life, different customers’ contexts cross-contaminating each other. This isn’t just an effectiveness problem — it’s a security problem.
Alternative: Apply scope and permission filtering before retrieval; give every long-term record an expiration policy or review flag.
3. A Context Lifecycle That Even a Small Team Can Use
You don’t need to buy an “Agent Memory Platform” first. You can start with one table, one directory, and a few fixed fields.
Step 1: Create a Context Card for Every Task
Figure: This card is the minimum unit for task handoff; more controllable than shoving the entire history into the next prompt round.
# Task: Fix login timeout
Objective: After session expiry, the user should be able to log in again.
Hard constraints: Do not modify token format; do not touch payment module.
Evidence: tests/auth/session.spec.ts; production error log #1842.
Unknowns: Whether the mobile refresh token shares the same endpoint.
Verification: pnpm test auth; manual verification of re-login after expiry.
The Agent reads this card at the start of every session — no need to replay last week’s entire chat history.
Step 2: Separate Tool Outputs into “Evidence” and “Noise”
Test failure messages, API responses, benchmark results — worth saving. Install progress, repetitive logs, irrelevant web navigation — not worth entering the long-term layer.
This step seems tedious, but it directly reduces retrieval pollution downstream. Don’t make future Agents pay for today’s terminal scrolling.
Step 3: Do a Handoff When the Task Ends
The handoff content isn’t “completed” — it’s: what was changed, what was verified, what risks remain, where to continue from next time. This way, even if the model, the person, or the session changes, the project won’t reset to square one.
Using This Approach in China
When accessing Tongyi Qianwen, Zhipu GLM-5, Wenxin Yiyan, or local Ollama models domestically, the Context Lifecycle is more worth settling on first than the model provider.
- Layer sensitive data first: Customer data, source code, and public documentation must use different storage and retrieval strategies.
- Treat the model as a replaceable executor: Context card, permission judgments, evidence links, and verification commands should sit outside the model layer, so switching models doesn’t mean losing engineering discipline.
- Local models also need a lifecycle: Local deployment solves the data-boundary problem, but does not automatically solve stale information, erroneous summaries, or task cross-contamination.
The truly portable capability isn’t “how many pages a model can remember” — it’s whether you know which content should enter, when it should exit, and where to replay when something goes wrong.
References
- Gaurav Dadhich, Agentic Context Management: Solving Agent Memory and Cost by Treating Them as Lifecycle and Architecture Problems , 2026-07-23.
- Hugging Face Daily Papers, Paper page and community discussion .
- The Context Card, source hierarchy, scope classification, and handoff workflow in this article are engineering practice recommendations synthesized from the paper’s ideas; the experimental metrics reported in the paper have not been independently verified on this site.
Follow 「全栈之巅-梦兽编程」 official account for weekly updates on Rust, AI programming, and Agent engineering practices.
Also welcome to explore 梦兽编程 AI Programming Assistant Service to integrate auditable, handoff-ready AI workflows into your daily development.