Most discussion about long-context agents focuses on token limits, retrieval tricks, vector stores, and memory persistence. Those topics matter. But in practice, the hardest part of context compaction is usually not losing facts.
It is losing intent.
An agent can retain the latest files touched, the last few decisions made, and a clean list of next steps — and still fail badly after compaction. The reason is simple: what often disappears is the thing that actually keeps the session aligned.
That missing layer usually includes:
- the original goal
- the user’s hard constraints
- the behavioral rules that shaped the work
- the reason the current subtask exists at all
This is the core failure mode of naive compaction. It preserves activity, but not alignment.
The real problem
When a session gets long, the default move is to summarize what happened.
That sounds sensible, but it hides a structural mistake: not all context is the same kind of memory.
Some context is persistent operating policy. Some context is session-specific working memory. Some context is temporary tactical noise.
If all of that gets flattened into one summary, the next session inherits an unstable mixture of durable rules, temporary instructions, and stale details. That is how agents resume in a subtly misaligned state: they remember the surface of the work, but not the governing frame.
The result is familiar:
- the agent continues the latest subtask but forgets the original objective
- a session-only user instruction disappears
- standing repo rules get duplicated into the compacted summary and later drift out of sync
- temporary tactics get preserved as if they were permanent constraints
This is not just a compression problem.
It is a memory architecture problem.
A better model: separate policy from session state
The practical strategy is simple:
- keep persistent cross-session rules in a stable source such as
AGENTS.md - use context compaction only for session-scoped state and constraints
In that model, AGENTS.md acts as the durable operating contract. It holds rules that should continue to apply across sessions:
- startup and read order
- repo conventions
- workflow expectations
- standing guardrails
Those rules are infrastructure. They should be referenced, not recopied into every compacted handoff.
The compacted context serves a different purpose. It is session memory. Its job is to preserve only what the next session needs in order to resume this exact thread correctly:
- the original objective
- the current focus
- why focus shifted, if it shifted
- active user constraints introduced in this session
- final decisions
- open tasks
- blockers
- resume order
This separation matters because persistent rules and session memory have different lifetimes. Mixing them is what creates drift.
The key insight: preserve deltas, not the whole world
A compacted context window should not try to restate everything.
It should preserve the delta that emerged during the session.
That means the compactor should ask five questions:
- What rules already live in persistent docs?
- What new constraints were introduced in this session?
- Which of those are still active?
- Which were temporary and are now expired?
- Has the session drifted from its original objective?
This is why the most important addition to a compaction strategy is not better summarization.
It is instruction classification.
Classify by lifetime
A robust compaction system should classify important instructions into four buckets.
1. Persistent
These belong in durable docs like AGENTS.md, not in the compacted session snapshot.
Examples:
- repo startup order
- standard documentation workflow
- standing safety rules
These should usually be referenced, not duplicated.
2. Session-scoped
These were introduced in the current session and must survive compaction.
Examples:
- “For this session, ask before editing docs”
- “Use the repo docs as source of truth”
- “Do not broaden scope beyond Task 7”
These belong in the compacted state because they are part of the active alignment contract.
3. Task-scoped
These are narrower still. They matter only for the current objective or subtask.
Examples:
- “Verify
README.mdanddegit.jsononly” - “Do not commit from this task”
These should be preserved only if they are still active when work resumes.
4. Expired or superseded
These were once relevant but no longer apply.
Examples:
- an earlier plan replaced by a later one
- a temporary exploration path that was ruled out
These should not remain mixed with active instructions. If they still matter for clarity, they should be carried forward explicitly as expired, not left behind to contaminate the active state.
A useful way to think about it is this:
| Bucket | Lifetime | Where it should live | Resume behavior |
|---|---|---|---|
| Persistent | Cross-session | Stable docs like AGENTS.md | Reference it |
| Session-scoped | Current thread | Compacted session state | Preserve it |
| Task-scoped | Current objective only | Compacted state, if still active | Preserve selectively |
| Expired or superseded | No longer active | Exclude or mark as expired | Do not treat as binding |
What a good compacted state should contain
A useful compacted session is not a transcript summary.
It is a resume artifact.
At minimum, it should preserve five things.
Objective continuity
This is the most commonly missing piece.
A strong compacted state should make the next session able to answer:
- What was the original objective?
- What is the current focus?
- If those differ, why did focus shift?
Without that continuity, the resumed session usually optimizes for the latest visible subtask and quietly forgets why that subtask existed.
Active session constraints
Session-specific instructions should survive in a structured form, not as vague prose.
A minimal ledger might track:
- instruction
- source
- scope
- status
That is enough to preserve the user’s hard rules without dragging the entire conversation forward.
Final decisions
The next session usually needs the final state, not the full argument that produced it.
Decision history can matter, but only when it changes what is now true. Otherwise, full debate logs are just expensive noise.
Open tasks and blockers
Do not preserve every completed step. Preserve what continuation depends on.
That means:
- unfinished tasks
- blocked items
- the next recommended order of work
File and artifact references
Whenever possible, preserve references instead of inlining content.
A file path, issue link, or artifact pointer is often more durable than a copied chunk of text that may immediately go stale.
Common failure modes
Weak compaction strategies usually fail in one of five ways.
1. They duplicate persistent rules
If AGENTS.md gets copied into every compacted summary, the system creates multiple versions of the same policy. Over time, those copies drift.
2. They lose session-only constraints
The handoff remembers the work, but not the user’s behavioral instructions.
3. They preserve stale tactics as active rules
A temporary instruction survives far beyond its useful life and quietly becomes part of the next session’s behavior.
4. They forget the original objective
The resumed session optimizes for local continuity instead of global intent.
5. They summarize history instead of reconstructing alignment
This is the deepest mistake.
A good handoff is not a story about what happened. It is a state description of what must still be true.
The design principle
If I had to reduce the whole strategy to one rule, it would be this:
Persistent rules should live in persistent memory.
Compacted context should preserve only session-specific alignment state.
Or shorter:
Reference the base. Preserve the delta.
That is the difference between a summary and a durable continuation mechanism.
Why this matters
As agents become more capable, the bottleneck shifts.
The question is no longer only whether a model can reason across a large context window. It is whether the system can reconstruct the right working state after context is compressed, switched, or handed off.
That means context compaction should be designed less like note-taking and more like state recovery.
A good compacted state should help the next session recover:
- what the job is
- what rules currently bind the job
- what changed during the session
- what is no longer true
- what to do next
In other words, compaction should not merely preserve history.
It should preserve alignment under continuation.
If your compaction strategy does that, you are no longer just summarizing context.
You are designing memory.