Context Compaction in TrueForge, Explained: What the Agent Forgets—and What the Session Retains

Compaction lets a long-running agent continue by replacing older working history with a structured summary. That is useful precisely because it is lossy—and dangerous if treated as archival truth.

Compaction changes the agent’s working memory, not the session’s historical record

Long conversations accumulate user messages, assistant messages, tool calls, tool results, and subagent outputs. Eventually, carrying every item forward becomes expensive or impossible. TrueForge context compaction addresses that runtime problem by summarizing older history and using the summary in place of the original messages for subsequent model steps.

The crucial distinction is between two views. The persisted session retains its event history. The model’s active context after compaction contains a structured, lossy representation of earlier work. Those views answer different questions. The event log supports reconstruction of what was recorded; the compacted context supports continued reasoning within a finite token budget.

Compaction is therefore not deletion, archival, or proof. It is a state transition in the agent’s working representation. A detail can remain present in persisted events while no longer being salient—or even present—in the summary the model uses.

The diagram separates the durable session record from the representation used for subsequent inference. Debugging requires both because presence in the event log does not mean salience in the compacted working context.

The documented trigger model

TrueForge documents compaction as enabled by default. It runs when input context reaches 80% of the model’s context length. If that length is not available, the harness uses a 50,000-input-token fallback. An agent can also configure an explicit input-token threshold.

These are trigger semantics, not quality guarantees. A threshold determines when summarization runs; it does not prove that the resulting summary preserves every fact needed later. Teams should choose explicit thresholds when model metadata is uncertain, tasks have unusually large reserved-output needs, or tool schemas and attachments make the effective budget smaller than the nominal model window.

Leave headroom for the next model response, tool arguments, approval payloads, and any system material injected by the harness. Triggering at the last possible token is operationally brittle because the compaction request itself and the next reasoning step also consume context.

The trigger is shown as a resource decision with reserved headroom. The documented defaults determine timing; teams still own workload-specific thresholds and quality validation.

What the summary is expected to preserve

TrueForge describes a structured summary covering original intent, key decisions, files and artifacts, errors and fixes, and next steps. That structure is valuable because it asks the compactor to preserve task state rather than produce a generic conversation synopsis.

Production agents should make critical state easy to summarize. Stable identifiers, typed status fields, explicit decision records, and artifact digests survive compaction better than facts buried in conversational prose. If an irreversible action depends on a value, store that value in an authoritative system or typed checkpoint rather than trusting it to remain verbatim in a generated summary.

InformationGood working representationAuthoritative sourceUser objectiveConcise intent and current scope.Original request and subsequent user decisions.DecisionChosen option plus rationale and constraints.Decision event or application record.ArtifactPath, digest, classification, and status.Artifact store and provenance record.External actionProposed, attempted, committed, or uncertain.System of record under an operation ID.Next stepNamed action with prerequisites.Workflow state when the step is consequential.

Lossiness is a feature with an error budget

A useful summary deliberately removes detail. If it preserved everything, it would not solve the context problem. The engineering task is to decide which losses are acceptable. Repeated phrasing, raw tool payloads, and abandoned exploration are usually cheap to discard. Approval scope, numerical thresholds, security constraints, and unresolved uncertainty are not.

Compaction can introduce omission, compression, or reinterpretation. A number may lose its unit; a tentative observation may become a decision; two similarly named files may be collapsed; an unresolved error may disappear behind the final workaround. These are not claims about a specific defect in TrueForge. They are failure modes of lossy, model-generated summaries and should shape testing.

Treat every compaction boundary as a checkpoint that can be evaluated. The application can compare the generated summary with typed invariants: active objective, required approvals, open operations, artifact digests, security constraints, and the next allowed transition. If an invariant is missing or contradicted, do not continue silently.

The compaction boundary becomes testable when critical state is expressed as invariants. A missing invariant can stop continuation before a lossy summary becomes an unsafe action.

Compaction and retrieval are different tools

Compaction creates a compact working narrative. Retrieval selects relevant source material at the moment it is needed. Long-running systems often need both. A summary can say that a migration plan exists and name its digest; retrieval can load the exact plan before execution. The agent should not carry a 20-page artifact in every turn, but it also should not execute from a paraphrase when exact content matters.

This pattern reduces the pressure on the summary to be a perfect archive. It needs to preserve pointers, state, and decision boundaries. Exact evidence stays in files, databases, or session events and is reloaded for high-stakes steps.

Compaction and persisted events support different debugging questions

When a post-compaction answer is wrong, investigators need both the pre-compaction record and the compacted representation. The event history can show what information existed. The summary can show what information the model actually carried forward. Comparing them identifies whether the failure arose before compaction, during summarization, or after the summary was consumed.

Record the compaction trigger, model and configuration used, input event range, summary event, token counts before and after, and validation result. Version any application-level compaction prompt or invariant checker. Without that provenance, a summary is difficult to reproduce and regressions are difficult to attribute.

Repeated compaction can compound loss

A long session may compact more than once. If a later summary is produced from an earlier summary rather than the full relevant record, omissions can become permanent in the working context. A small ambiguity may be compressed into a confident statement, then carried forward as if it were original evidence.

Track compaction generations and the event range each summary represents. At important milestones, construct the next working state from durable typed checkpoints plus selected source events instead of summarizing only the previous summary. This is especially useful after approvals, external mutations, incident handoffs, or a material change in user intent.

Set a maximum session age or compaction count for workflows where accumulated interpretation risk matters. Starting a new session is not failure; it can be a deliberate reset that imports only verified state. The handoff should name the prior session, approved artifacts, unresolved operations, and the reason for the reset.

Compaction is not a retention or privacy control

Removing detail from the model’s working context does not mean the underlying event history has been deleted. TrueForge explicitly distinguishes the compacted context from persisted session events. Data-retention, deletion, legal hold, access, and export policies must therefore operate on the persisted stores and attached artifacts—not on whether the model currently sees the content.

The reverse matters too. A compacted summary can preserve sensitive information even when the original detail is no longer needed for the task. Apply data minimization to the summary itself, control who can read session state, and avoid copying secrets or raw personal data into durable narrative fields. Redaction and retention should be designed across every copy: model input, summary, event record, file, trace, and downstream system.

Human corrections must survive the boundary

If a user corrects an earlier fact, the compacted state should preserve the correction and retire the superseded value. Represent corrections as explicit state transitions instead of relying on “later text wins.” Test that the summary keeps the current value, records material provenance where necessary, and does not revive the old value after another compaction.

For contested or regulated decisions, keep the original statement, correction, decision owner, and effective time in an authoritative record. The working summary can carry the current instruction, while the durable record preserves the history needed for audit and appeal.

Do not infer exactly-once or deterministic continuation

Persisted state and a compacted summary help an agent continue. They do not make external side effects deterministic. If a tool call timed out around a database mutation, the summary may accurately say “status unknown,” but the application must still query the authoritative system before retrying. Compaction should preserve the operation identifier and ambiguity; reconciliation resolves it.

Likewise, a summary should not silently carry an old authorization decision into a new state. Approval and business authorization may expire or become stale after a resource changes. Re-evaluate them at execution time.

How to test compaction

• Place critical facts early in a long session and verify they remain explicit after compaction.
• Include similar filenames, units, and identifiers; test for accidental merging.
• Compact while an approval, external operation, or error remains unresolved.
• Verify abandoned hypotheses are not promoted into decisions.
• Compare post-compaction actions with a control run that retains the full history.
• Replay representative sessions after model or compaction-configuration changes.
• Confirm the persisted event history remains available even though the working context is shorter.

An operating model for long sessions

Use the working context for current intent, decisions, pointers, and next steps. Use session events for the ordered runtime record. Use files and registries for versioned artifacts. Use systems of record for committed business state. Then compaction can reduce conversational bulk without becoming the only place the application remembers important facts.

Monitor compaction frequency, compression ratio, post-compaction error rate, invariant failures, reopened questions, and repeated tool calls. A session that compacts repeatedly may need better tool-result offloading, narrower task scope, or a deliberate new session rather than ever denser summaries.

The operational rule

TrueForge context compaction extends the useful life of an agent session by exchanging historical detail for a structured working summary. The safe mental model is “lossy continuation over a durable record,” not “perfect memory.”

Preserve stable pointers and typed invariants, reload exact evidence when it matters, reconcile external effects against authoritative systems, and test the boundary explicitly. Compaction becomes reliable when the system knows which facts a summary may compress—and which facts it must never be allowed to invent or forget.

References

1. TrueForge — Harness Capabilities.
2. TrueForge — SDK Concepts.
3. TrueForge — Use an Agent.

Editorial disclosure. This article reflects TrueFoundry’s engineering interpretation of the cited public materials as of September 19, 2026. Product capabilities are scoped to linked documentation. Examples and operating defaults are illustrative; they are not legal advice, an audit opinion, an independent benchmark, or a guarantee of security, safety, or compliance.

‍