Context Compaction vs.
Agent Handover for Long Coding Tasks

Every LLM-based coding agent eventually hits its context-window ceiling. The prompt fills up with tool calls, file contents, test outputs, and intermediate reasoning. When there is no room left for the next operation, the agent must decide what to do.

Two main strategies have emerged. Context compaction asks the LLM to summarise the conversation and replaces the raw history with a compressed version. Structured handover captures the session state in a predefined JSON schema and transfers it to a fresh agent session.

This article is a head-to-head comparison of both approaches across five dimensions: continuity, token cost, correctness, failure modes, and implementation complexity. The goal is not to crown a winner but to give you a framework for deciding which approach fits your use case.

We will also cover when compaction is the right choice (it is not always the wrong one), when handover justifies its overhead, and what the research and implementation experience tells us about each strategy.

What Is Context Compaction?

Context compaction is the simplest approach to managing context-window limits. When the prompt approaches its token budget, the agent asks the LLM to summarise the conversation history so far and replaces the raw messages with the summary.

The typical flow looks like this:

1. The agent detects that the context window is nearly full.
2. It sends the conversation history to the LLM with a prompt like "Summarise the above conversation, preserving all important details."
3. It replaces the raw history with the summary, freeing up tokens.
4. Execution continues from the same session, now with a compressed history.

This approach is the default in many agent frameworks because it is straightforward to implement. It requires no new infrastructure, no schema design, no session-management logic. Just a single additional LLM call at compaction time.

The appeal is obvious: low upfront complexity, no architectural changes, and a familiar pattern borrowed from chat applications where conversation summarisation works reasonably well.

What Is Structured Handover?

Structured handover takes a different approach. Instead of compressing the conversation, it captures the task state into a predefined JSON schema and transfers that document to a newly spawned agent session. The old session is discarded; the new session starts fresh with the handover document as its context.

The typical flow looks like this:

1. The agent detects that the context window is nearly full.
2. It generates a structured handover document with fields like original_goal, decisions_made, changes_applied, test_results, errors_and_failed_attempts, user_constraints, things_not_to_repeat, and exact_next_step.
3. The handover document is serialised and stored.
4. A fresh agent session starts, loading the handover into its system prompt.
5. The new agent reads the handover and continues execution from the exact_next_step.

Unlike compaction, handover does not try to preserve the conversation. It deliberately discards the raw transcript and keeps only the structured fields. The assumption is that the raw transcript contains a lot of noise (intermediate reasoning, redundant tool calls, failed attempts that were immediately corrected) and that the handover fields capture everything the next agent actually needs.

RaggieCode's handover schema defines exactly 12 fields. Each field plugs a specific leak in the compaction approach. The full specification is documented in the Agent Handover documentation, and a deeper narrative about why compaction fails for coding tasks is in the earlier blog post on context handover.

Comparison: Compaction vs Handover

The table below compares both approaches across five dimensions that matter for coding agents. Each dimension includes an honest assessment of tradeoffs, not just surface-level wins.

When to Use Context Compaction

Context compaction is not always the wrong choice. For many scenarios, it is perfectly adequate and more efficient than handover.

Good candidates for compaction

• Read-only exploration: If the agent is only reading code and answering questions, compaction preserves enough context to carry the conversation. No state is being modified, so the risk of inconsistent edits is zero.
• Single-edit tasks: A one-line fix in one file, followed by a test run, requires very little context. Compaction will not lose anything important because there is nothing important to lose.
• Short sessions: If a task fits in 2–3 context windows, and each window captures a self-contained sub-task, compaction works fine. Problems arise when a single logical task spans many windows.
• Small context windows (8K–16K): On models with very small windows, the overhead of a handover document (2K–5K tokens) is a significant fraction of the available space. Compaction's smaller footprint may be preferable, even with the quality loss.
• Prototyping: When you are experimenting with an agent setup and do not yet know what your task profile looks like, compaction is the fastest path to a working system.

When to Use Structured Handover

Handover becomes the right choice when the cost of losing context outweighs the overhead of generating and loading the handover document.

Good candidates for handover

• Multi-file refactoring: When an agent touches multiple files with interdependent changes, the handover's changes_applied field preserves exactly what was modified where. Compaction would produce "modified several files" and leave the next agent guessing.
• Test debugging workflows: When a session involves running tests, seeing failures, fixing them, and re-running, the handover's test_results and errors_and_failed_attempts fields prevent the next agent from re-running the same tests or repeating the same failed fixes.
• Tasks with user constraints: If the user said "do not touch the database layer" in the first turn, compaction may drop that constraint by turn 20. Handover's user_constraints field preserves it across all sessions.
• Tasks involving design decisions: Architecture decisions matter for the entire task, not just the current session. The decisions_made field ensures the next agent understands why choices were made, not just what was chosen.
• Any session that will require multiple context windows: If the task is large enough that you know it will exceed one window, start with handover from the first handover boundary. The cost of the structured approach compounds less than the cost of repeated compactions.

A Deeper Look at Continuity

Continuity .; the ability of an agent to maintain coherent progress across a context window boundary .; is the most important dimension for long coding tasks. Let us examine how compaction and handover handle the three most common continuity failures.

Failure 1: Forgetting what the user originally asked

In compaction, the original goal is just another part of the conversation history. It gets summarised when compaction triggers. The summary of the original goal is further summarised on the next compaction. After three compactions, "Add input validation to the login endpoint and update all callers" may become "Add validation" or even just "Fix auth." The agent may complete the task but implement something different from what was asked.

In handover, the original_goal field is immutable by design. It is written once when the handover is generated and never changes across successive handovers. Every new session reads the exact same goal statement. Goal drift is structurally impossible.

Failure 2: Repeating failed approaches

Compaction loses failed attempts because summaries are biased toward outcomes. A compacted session tells the story of what worked, not what did not. The next agent is condemned to repeat the same dead ends. I have observed this empirically: an agent tried three approaches to fix a test, all failed, and after compaction it started with approach one again.

Handover captures failed attempts in errors_and_failed_attempts. The next agent reads "tried X, failed because Y" and skips straight to the next viable approach. The things_not_to_repeat field doubles down on this by explicitly listing actions to avoid.

Failure 3: Inconsistent edits across the boundary

The most expensive failure mode: an agent edits file A, compacts, then edits file B in a way that is inconsistent with the changes to file A because the summary did not capture the exact interface contract established in file A.

Handover's changes_applied field records every file modification with enough detail for the next agent to understand what changed. Combined with important_files_and_symbols, the new agent can re-load the modified files and verify consistency before making further changes.

Cost Analysis: When Does Each Approach Win on Tokens?

Token cost is not as simple as "compaction is cheaper." The upfront cost of handover is higher, but compaction's hidden costs can add up.

Consider a task that requires four context windows to complete:

• Compaction: You run compaction three times (between each window transition). Each compaction costs one short LLM call. However, after each compaction, the agent may re-read files it already read, re-run tests it already ran, or repeat failed fixes it does not remember attempting. These hidden costs can easily exceed the handover overhead.
• Handover: You run handover three times. Each handover costs one LLM call to generate the document (slightly more expensive than a compaction prompt, since the schema must be populated). The new session starts with the handover in its prompt (2K–5K tokens). However, the new agent does not re-discover files, re-run passing tests, or repeat failed approaches. The hidden costs are near zero.

In practice, for simple tasks (1–2 windows), compaction wins on token cost. For complex tasks (3+ windows), handover breaks even or wins because it eliminates the compounding inefficiency of repeated discovery and repeated failure.

For tasks involving test suites, the calculus tilts even more toward handover. A single test run can consume 2K+ tokens of output. If compaction causes the agent to re-run a suite of 50 tests just to check which ones pass, the cost of that single re-run can exceed the cost of a handover.

Can You Combine Both?

A pragmatic observation: compaction and handover are not mutually exclusive. A hybrid approach can pick the right tool for each transition.

One hybrid strategy is to start with compaction and escalate to handover. The first compaction is cheap and adequate for minor context management. If the session continues to grow and a second transition is needed, switch to handover. This avoids handover overhead for short sessions while providing structured continuity for sessions that prove to be long.

Another hybrid strategy is task-dependent scheduling: use compaction for read-only or exploratory phases, and handover for phases involving file edits. Since the agent can detect whether it has modified any files, it can choose the appropriate transition strategy dynamically.

Neither hybrid strategy is implemented in RaggieCode today (the current implementation uses handover exclusively for coding tasks), but the architecture supports adding this kind of dynamic decision-making. The handover check happens before each LLM call, so the condition could easily be extended to consider task type, number of modified files, or user preference.

Decision Framework: Which One Should You Use?

Based on the analysis above, here is a practical decision framework:

def choose_transition_strategy(session):
    modified_files = session.get_modified_files()
    test_results = session.get_test_results()
    has_constraints = session.has_user_constraints()
    has_failed_attempts = session.has_failed_attempts()
    estimated_remaining_windows = session.estimate_remaining_windows()

    # Simple tasks: compaction is adequate
    if len(modified_files) == 0 and estimated_remaining_windows <= 2:
        return "compact"

    # Complex tasks: handover is worth the overhead
    if len(modified_files) > 2 or len(test_results.failures) > 0:
        return "handover"

    if has_constraints or has_failed_attempts:
        return "handover"

    if estimated_remaining_windows > 3:
        return "handover"

    # Default: compact for short/cheap, handover for long/expensive
    return "compact"

The key insight is that the decision should be context-dependent. There is no universally superior approach. The choice depends on the task profile, the model's context window size, the number of expected transitions, and the cost of losing specific types of information.

Putting It All Together

Context compaction and structured handover represent two fundamentally different philosophies for managing the context-window constraint in coding agents.

Compaction treats the problem as a conversation-management issue. It compresses the past to make room for the future. It is simple, cheap, and adequate for tasks where the cost of forgetting is low.

Handover treats the problem as a task-state-management issue. It transfers the essential task state to a fresh session, discarding the noisy transcript. It is more complex, more expensive up front, but more reliable for tasks where the cost of forgetting is high.

If you are building a coding agent or choosing between agent frameworks, here is my honest advice:

• Start with compaction if you are prototyping or your tasks are predominantly read-only or single-file edits. It will get you 80% of the way there with 10% of the engineering effort.
• Invest in handover when your tasks involve multi-file changes, test debugging, user constraints, or any scenario where losing context means breaking code. The engineering cost is real, but the alternative is an agent that unpredictably breaks things when the context window fills up.
• Consider a hybrid approach if you have diverse task profiles. Let the agent decide which strategy to use based on the current session state.

RaggieCode's handover implementation is open source and documented in detail. The Agent Handover documentation describes the 12-field schema and how each field is populated. The earlier blog post on context handover provides a narrative walkthrough of why handover was chosen over compaction for RaggieCode's coding tasks. The full source code, including the handover generation and consumption logic, is available on GitHub.

Neither approach is perfect. Both have failure modes. But understanding the tradeoffs between them is the first step to building an agent that does not forget what it was doing halfway through the job.