Long-Context Agent Tasks: Compaction, Persistence, and Reliable Continuation

1. The Real Bottleneck of Long Context: From “Fitting It In” to “Finishing the Run”

Mainstream large models now offer context windows in the hundreds of thousands of tokens, so “can it hold an entire code repository” is no longer the main problem. But anyone who has actually run long-horizon agent tasks—say, having a model autonomously complete a large-scale refactor over several hours, or run an entire data processing pipeline—knows that a bigger window does not prevent mid-task breakdowns. The model starts forgetting early constraints, repeating completed steps, or drifting away from the goal.

The root cause is that context consumption in long-horizon tasks is continuous and irreversible. Every step an agent takes—reasoning, calling a tool, reading an observation—appends content to the context, while window capacity is finite. For any genuinely long-horizon task, context compaction is therefore inevitable. If a task finishes without ever triggering compaction, it simply was not long-horizon enough. Rather than debating whether the window is large enough, the engineering focus should go to two things: whether the task can correctly resume after compaction, and whether critical state has already been externalized outside the context.

2. Compaction Is Inevitable: A Simple Calculation

A rough estimate makes the inevitability of compaction clear. Suppose an agent consumes an average of 3k–5k tokens per step (including model reasoning, tool call parameters, and returned observations). A 200k window theoretically supports only forty to fifty interaction steps. A serious long-horizon task—for example, “migrate the entire project’s unit tests from the old framework to the new one”—easily runs into the hundreds of steps and involves reading and writing dozens of files. That gap can only be bridged by compaction.

This means compaction is not an exceptional path but a routine event on the main path. The direct cause of many failed long tasks is precisely that compaction was treated as a low-probability anomaly, with no formal process designed for it.

3. The Core Responsibility of the Harness: Continue Correctly After Compaction

In agent engineering, the harness is the layer of code that drives the model loop: it assembles context, calls the model, executes tools, and writes results back into the context. For long-horizon tasks, the harness’s most important responsibility is not “calling the model” but guaranteeing lossless task state after compaction occurs.

A robust harness must do at least four things:

1. Actively manage trigger timing. Do not wait until the context is completely full and then truncate passively. Trigger compaction proactively when a threshold is reached (for example, 70%–80% of the window) to reserve room for the rebuild phase.
2. Persist to disk before compacting. Compaction usually means history is summarized or discarded, so any critical information not yet persisted may be lost. Before the compaction action, task goals, completed items, key decisions, and environment constraints must be written to files.
3. Rebuild the context after compaction. The new working context should not be just “a summary.” It should be reassembled from fixed elements: the original task goal, the current plan, the progress checklist, and important conclusions and constraints. A summary can only supplement these—it cannot be the sole carrier.
4. Self-check after rebuild. Have the model (or the program) verify: Is the goal still present? Does progress match the process files? Is the next step clear? Continuing only after the self-check passes intercepts the vast majority of state loss caused by compaction.

An illustrative main loop looks roughly like this:

while not task.finished():
    if ctx.token_count > COMPACT_THRESHOLD:
        persist_state_to_files(ctx)         # before compaction: persist critical state
        ctx = rebuild_context(goal, files)  # after compaction: rebuild from goal + files
        assert_context_integrity(ctx)       # self-check: goal, progress, constraints intact?
    step_result = agent.step(ctx)
    append_progress_file(step_result)       # update process file at every step
    ctx.append(step_result)

4. Process File Writes: Externalize Memory to the File System

A conclusion repeatedly validated in practice is this: as long as process files are written well enough, context length itself is not a major problem. The reason is simple—context is volatile and subject to compaction, while files are persistent and can be re-read at any time. Moving “memory” from the context into the file system is equivalent to equipping the task with recoverable checkpoints.

It is recommended to maintain several categories of process files:

• Plan and progress files: record the overall goal, task breakdown, and completed / in-progress / todo lists, updated after every completed step. This is the primary data source for rebuilding context after compaction.
• Conclusion and decision files: record key conclusions reached along the way, pitfalls encountered, and irreversible constraints (for example, “the test environment port is 5433, do not use the default configuration”). Once such information is lost, the model will repeat its mistakes.
• Intermediate artifact files: generated code, analysis reports, data snapshots, and so on are written directly to disk, with only the path and a one-line summary kept in the context, to be read on demand when needed.

A progress file can be organized like this:

# PROGRESS.md
## Goal
- Complete the data pipeline refactor, all 47 test cases passing
## Completed
- [x] Map module dependencies (conclusions in deps.md)
- [x] Extract the shared serialization layer
## In Progress
- [ ] Migrate batch_loader, 3 call sites remaining
## Constraints and Risks
- Test environment database port is 5433, do not use the default configuration
- Full regression required before removing the compatibility layer

This mechanism also brings two additional benefits. First, tasks can resume seamlessly after a session interruption, a process restart, or even across days, because state lives in files rather than in the context. Second, the process is auditable: a human can inspect the progress file at any time to understand how the task is advancing and intervene to correct course when necessary. In cloud environments, these process files can be stored on local disk or managed centrally in object storage, paired with a logging service to retain key events for retrospective analysis and troubleshooting.

5. Empirical Boundaries: Context Scale and the “Degradation” Phenomenon

Regarding the relationship between context length and model capability, the practitioner community has a fairly consistent empirical line: when the working set stays within the 100k–200k token range, models generally do not show obvious “degradation”—instruction following, code quality, and reasoning depth remain relatively stable. But when the context continually approaches the window limit and large amounts of irrelevant history accumulate, attention is diluted, the model tends to ignore early constraints, and output quality drops noticeably.

From this, a simple engineering principle follows: do not treat the context as a database. The context should contain only the “current working set”—the current task goal, the file being worked on, and the most recent key conclusions. Everything else belongs in the file system or a retrieval layer, injected on demand. This both conserves window capacity and, more importantly, protects model output quality.

It is worth noting that practice has already observed cases where a single task accumulated token consumption on the order of hundreds of millions while still progressing reliably—precisely because of the two conditions above: a dependable compaction workflow and complete process files. Window size determines “how much can be held at once,” while engineering mechanisms determine “how far the task can ultimately run.”

6. Session Duration Limits: Decoupling Lifecycle from Quota

Many platforms impose duration or quota caps on a single session (on the order of several hours is common). The impact on long tasks depends on whether the task lifecycle is bound to the session: if all state lives only in session memory, the session ends and the task dies; if state has already been externalized through process files, a session interruption is merely a pause, and a new session can continue by reading the progress file. Practice has even produced cases where a task started before the quota window began and was unaffected throughout. This essentially demonstrates the same point: quota limits are not frightening; what is frightening is failing to design for continuation. Treat sessions as stateless compute resources and files as the stateful source of truth, and duration limits degrade from a risk to an ordinary operational parameter.

7. Implementation Checklist

Condensing the above into an actionable checklist:

1. Task decomposition: break the large goal into small, independently verifiable steps, each with a clear completion marker.
2. Process files: establish progress and conclusion files, with an agreed rule that every step must update them.
3. Compaction strategy: set a proactive trigger threshold; persist before compaction, rebuild after compaction, self-check after rebuild.
4. Working set control: keep only the current working set in context; route history and artifacts through the file system.
5. Resume from breakpoints: ensure that if the process is killed at any moment, the scene can be recovered from process files.
6. Human checkpoints: set confirmation points before key irreversible operations (deletion, release, data changes).

8. Conclusion

The value of long-context capability is not in cramming more text into a single request, but in supporting longer chains of autonomous tasks. Window capacity is decided by the model side, but whether a task can run to completion reliably is something developers build themselves: a dependable compaction-and-continuation mechanism, externalized process memory, and restrained working set management. With all three in place, long-horizon tasks shift from “a matter of luck” to “a matter of confidence.”