Context Compaction Is a Governance Boundary: Pinning Policies in Long-Running Agents

Context compaction is usually described as a performance feature: summarize old turns, evict tokens, and keep the agent under its context limit.

For production agents, that description is incomplete. Compaction is also a governance decision. It decides which instructions, policies, approvals, tool results, and memories remain visible when the agent acts next.

If the compactor preserves task continuity but drops a standing policy, the model may behave correctly before compaction and violate the same policy afterward. The model did not change. The user did not change. The visible control plane changed.

The failure mode: memory survives, policy disappears

Consider an internal operations agent with a standing rule: never send a customer export outside the company domain. The agent handles several tasks, reads tool output, and accumulates a long history. The runtime compacts the conversation. The summary keeps the task state—“prepare the customer export”—but omits the old organizational rule. A later tool call sends the file to an external address.

This is not solved by adding more retrieval. Retrieval asks, “What seems relevant to the current query?” Governance asks, “What must remain in force even when it is not relevant to the current subtask?”

• Working context: The precise, recent material required for the next decision.
• Operational memory: Durable facts, commitments, outcomes, and reusable patterns.
• Governance state: Policies, approval boundaries, identity, risk tier, and non-negotiable constraints.
• Authoritative state: The external system of record that decides what actually happened.

The last two layers should not be treated as ordinary chat history.

What the current research says

The 2026 paper Governance Decay introduces the ConstraintRot benchmark for measuring whether in-context governance constraints survive compaction. Across seven models and 1,323 episodes, the paper reports that compaction increased policy violations from 0% to 30%, reaching as high as 59% in some settings. When the constraint survived the summary, violation stayed at 0%; when it was dropped, violation rose to 38%.

The result is especially important for enterprise policies. Hard safety norms may already be strongly represented in a model’s training and refusal behavior. Soft organizational policies—such as “only deploy to this region,” “keep spend under this threshold,” or “send reports to this channel”—are much more likely to disappear because they are local rules carried in context.

The same paper describes a compaction-eviction attack: an adversary does not need to edit the policy. It can inject enough content into the context to bias the lossy summary toward deleting it.

A separate 2026 paper, LiveMem, explores a model-level recurrent memory state that continues across context turnover while a bounded attention window handles recent detail. Its architecture is not a drop-in application pattern for every team, but it clarifies an important distinction: long-term continuity is not the same as retrieving a document after the fact. A system needs an explicit state lifecycle and a definition of what information must survive eviction.

The architecture: compact the task, pin the control plane

A practical production design separates the agent state into independent envelopes:

run:
id: run_01JX...
tenant: acme
actor: agent:billing-ops
risk_tier: high
policy_bundle_hash: sha256:...
approval_state: required

working_context:
system_instructions: preserved
recent_messages: bounded_fifo
active_tool_results: last_20
current_plan: versioned

governance:
constraints:
- id: no_external_customer_exports
source: policy://data-handling/v4
priority: critical
enforcement: deterministic_preflight
- id: purchases_over_100_require_approval
source: policy://finance/v8
priority: high
enforcement: approval_gate
identity:
subject: agent:billing-ops
groups: [finance-read]
integrity:
bundle_sha256: "pin-and-verify"

memory:
episodic_candidates: append_only
semantic_facts: provenance_required
procedural_patterns: outcome_scored
retention: policy_defined

checkpoint:
sequence: 42
last_committed_effect: invoice_lookup
pending_effects: []
replay_cursor: tool_call_41

The compactor may summarize working_context, rank memory candidates, and discard low-value history. It must not silently rewrite governance or checkpoint state.

1. Pin governance constraints

Constraint pinning means that a small, versioned policy bundle is re-injected or verified at every decision boundary. Do not rely on a summary to remember it.

A pin should contain:

• Policy identifier: Where the rule came from.
• Version: Which policy revision is active.
• Scope: Tenant, user, agent, tool, region, or workflow.
• Effect: Allow, deny, require approval, or escalate.
• Expiry: When the rule must be refreshed.
• Integrity hash: Whether the bundle changed unexpectedly.

interface Constraint {
id: string;
version: string;
scope: string[];
effect: "allow" | "deny" | "require_approval" | "escalate";
source: string;
expiresAt?: string;
}

interface PolicyPin {
runId: string;
sequence: number;
constraints: Constraint[];
sha256: string;
}

function verifyPin(pin: PolicyPin, expectedHash: string) {
if (pin.sha256 !== expectedHash) {
throw new Error("policy pin integrity failure; stop before tool execution");
}
if (pin.constraints.some((c) => c.expiresAt && Date.now() > Date.parse(c.expiresAt))) {
throw new Error("policy pin expired; refresh governance state");
}
}

A prompt-level reminder is useful, but it is not enough for high-impact actions. Pair the pin with deterministic preflight checks at the tool boundary. If the agent tries to send an external email, execute a purchase, delete a record, or deploy outside an approved region, the gateway should enforce the rule independently of the model’s visible context.

2. Make memory provenance-aware

A memory record without provenance is an attractive hallucination cache. Every durable memory should answer:

• Who or what created it?
• When was it observed?
• Which source supports it?
• What scope does it apply to?
• What would invalidate it?
• Has a human or system approved it?

{
"memory_id": "mem_0182",
"kind": "procedural",
"statement": "Refunds above 500 require finance approval",
"source": {
"type": "policy",
"uri": "policy://finance/refunds/v8",
"observed_at": "2026-10-08T08:00:00Z"
},
"scope": ["tenant:acme", "workflow:refunds"],
"confidence": 1.0,
"status": "active",
"supersedes": "mem_0110",
"review_after": "2026-11-08"
}

The open-source memory ecosystem is moving in this direction. The Awesome Memory for Agents catalog lists systems that add decay, contradiction inspection, provenance, typed memory, outcome scoring, multi-tenant policy controls, and token-bounded context compilation. Those are stronger primitives than “store every conversation chunk in a vector database.”

Use retrieval for useful history; use policy state for constraints. A retrieved memory can suggest. A policy pin must be enforceable.

3. Compact with a contract, not a single summary prompt

A safe compaction pipeline has separate passes:

1. Extract: Identify facts, commitments, open tasks, approvals, tool outcomes, and policy references.
2. Classify: Assign each item to working context, memory candidate, governance, or discard.
3. Validate: Check that required fields, policy IDs, and active approvals are present.
4. Summarize: Compress only the working-context and memory sections.
5. Rehydrate: Build the next context bundle from the validated policy pin, checkpoint, recent task state, and selected memories.
6. Audit: Record what was evicted, retained, transformed, or newly promoted.

def compact(state, token_budget):
extracted = extract_items(state.history)
governance = [x for x in extracted if x.kind == "governance"]
checkpoint = state.checkpoint
candidates = [x for x in extracted if x.kind in {"fact", "event", "plan"}]

validate_governance(governance)
compacted_task = summarize_to_budget(candidates, token_budget)

return ContextBundle(
policy_pin=rehash_and_pin(governance, state.policy_hash),
checkpoint=checkpoint,
task_context=compacted_task,
recent_tail=state.history[-20:],
audit=diff_context(state.history, compacted_task),
)

The important property is not the exact summarizer. It is the type boundary: governance is never just another paragraph in a lossy summary.

4. Checkpoint side effects separately from reasoning

Long-running agents fail in two different ways: they lose what they were thinking, or they repeat what they already did. The second problem is usually more expensive.

Before every side-effecting tool call, write an intent record. After the external system confirms success, write a committed-effect record. On restart, reconcile the checkpoint against the authoritative system of record before retrying.

PREPARE effect_id=pay_042 amount=480.00 idempotency_key=run_01JX:pay_042
CALL payment_api
COMMIT effect_id=pay_042 provider_receipt=rcpt_8831

Never infer “the payment probably failed” from a crashed process. Query the payment provider using the idempotency key. The same pattern applies to email, ticket creation, deployment, database writes, and social publishing.

5. Test compaction as a security and reliability event

Add compaction scenarios to your evaluation suite:

• A standing policy is introduced, then buried under benign tool output.
• A malicious tool result attempts to make the policy disappear.
• A summary preserves the task but drops the approval state.
• A restart occurs between prepare and commit.
• A policy is updated while a run is paused.
• A memory item contradicts a newer policy revision.

Grade the tool call, not the assistant’s explanation. A fluent refusal followed by an unauthorized API call is a failure. Track:

• Constraint survival rate: Fraction of active constraints present after compaction.
• Violation rate after compaction: Prohibited effects divided by triggered episodes.
• Policy freshness: Time between a policy revision and agent rehydration.
• Replay fidelity: Whether a checkpoint can reconstruct the same safe decision.
• Memory precision: Fraction of retrieved memories that are both relevant and still valid.

What practitioners are noticing

A LocalLLaMA discussion about long-lived agents asks the operational questions that demos often skip: what is the source of truth after a restart, how do you avoid repeating side effects, and how much should you trust the agent’s own memory? The thread’s core concern is continuity and reconstructability, not prompt quality.

A Hacker News discussion on context engineering makes the opposite but complementary point: simple filesystem memory can be surprisingly effective. A structured .agent/ directory with plans, findings, and status markers is inspectable, diffable, and easy to roll back. You do not need a complex memory backend before you establish good state semantics.

Temporal’s production context-engineering walkthrough similarly emphasizes managing context, focusing agents with tools, and separating durable workflow state from the conversation. The right architecture may be a filesystem, Postgres, Redis, a graph, or a durable workflow engine. The invariant is that the state is typed, inspectable, and recoverable.

References & Community Insights

• Chen, Governance Decay: How Context Compaction Silently Erases Safety Constraints in Long-Horizon LLM Agents, arXiv: https://arxiv.org/html/2606.22528v2
• LiveMem: Maintaining Memory State Continuity in Long-Running Language Model Inference, arXiv: https://arxiv.org/html/2608.02515
• Redis, State of Context Engineering 2026: https://redis.io/resources/state-of-context-engineering-2026/
• TsinghuaC3I, Awesome Memory for Agents: https://github.com/TsinghuaC3I/Awesome-Memory-for-Agents
• Reddit r/LocalLLaMA, Are people actually running long-lived agents yet?: https://www.reddit.com/r/LocalLLaMA/comments/1t5gx4d/are_people_actually_running_longlived_agents_yet/
• Hacker News, Context Engineering for AI Agents: Lessons: https://news.ycombinator.com/item?id=45352901

Final checklist

Before shipping a long-running agent, verify:

1. Are governance constraints stored separately from lossy conversation history?
2. Does every policy pin have scope, version, provenance, expiry, and an integrity hash?
3. Can tool boundaries enforce high-impact rules without asking the model to self-police?

4. Does compaction produce an audit diff of retained and evicted information?

5. Can a restart reconcile side effects against the authoritative system of record?
6. Do regression tests deliberately bury, contradict, and attack active policies?

7. Can an operator inspect and roll back memory changes?

Context compaction is necessary for long-running agents. Treating it as a neutral summarization step is the mistake. It is a state transition across the agent’s control plane—and it deserves the same versioning, integrity checks, audit trail, and replay discipline as any other production boundary.