Pack Light, CarryOn: Oriented Context for Long-Horizon Agents

Yuchen Lu, Julian McAuley, Lei Zhang

CarryOn organizes long-horizon agent context around reusable task objects to replace redundant interaction histories.

How can long-horizon agents maintain progress without redundantly re-processing the entire interaction history?

Long-horizon agents repeatedly process massive interaction histories to track progress, wasting compute on re-deriving facts already captured in the environment or task state. CarryOn replaces this redundant history with an object-oriented runtime that maintains "continuation carriers"—reusable task objects like files or findings—alongside an execution context for pending goals. On OSWorld 2.0, this approach improves task performance by 5.8% while reducing total token usage by 51.9% compared to baseline agents.

Paper Primer

The core mechanism is a "fold" operation that periodically retires interaction history by distilling it into three components: continuation carriers (reusable objects), execution context (active constraints and goals), and a live tail (recent interactions). The system uses a Tracker to identify reusable progress and a Compiler to jointly update these components, ensuring the agent builds on established state rather than re-processing the history that created it.

CarryOn significantly improves task success rates on long-horizon benchmarks.

Performance on OSWorld 2.0 increased from 43.9% to 49.7% (partial score), and BrowseComp-Plus accuracy rose from 49% to 56%.

The method drastically reduces the computational overhead of long-horizon execution.

Total token usage dropped by 51.9% on OSWorld 2.0 and 22.9% on BrowseComp-Plus. Over 50% reduction in token consumption on complex computer-use tasks.

Why is this approach more effective than simply summarizing the interaction history?

Summarization methods often create a "selective account" that can drift from the actual task state. CarryOn instead uses reusable task objects (like files or findings) as the primary unit of continuation, allowing the agent to inspect and modify the environment directly rather than relying on a potentially stale textual summary.

What is the role of the "execution context" if the carriers already store progress?

The execution context preserves information that isn't materialized into a reusable object, such as active goals, unresolved constraints, and pending work. It acts as a necessary complement to the carriers, ensuring the agent doesn't lose its "to-do list" when the interaction history is retired.

For long-horizon agent design, this paper shifts the paradigm from "compressing history" to "externalizing state," suggesting that agents should treat task progress as a persistent, object-oriented workspace rather than a linear stream of events.

The Long-Horizon Context Bottleneck

We expose the inefficiency of re‑processing histories and propose object‑oriented context.

Long‑horizon agents accumulate progress in persistent task state while also retaining full interaction histories that describe how that progress was achieved. Re‑processing these histories at every step wastes compute and inflates the context window, especially as tasks grow longer.

Agents spend unnecessary resources repeatedly parsing the same past interactions; the core problem is that the context window is dominated by redundant accounts of already‑available task results.

**Figure 1.** Context folding with reusable task objects in long-horizon OSWorld2.0 (Yuan et al., 2026). *Top*: In a slide-editing task, the working presentation and exported images carry completed editing progress, while remaining constraints and save verification stay explicit, reducing active context from 42.4K to 14.4K tokens (66.0%). *Bottom*: In a lab-report task, the working document carries completed edits, while unresolved calculations remain explicit, reducing active context from 58.4K to 23.5K tokens (59.7%).

The shift from interaction‑based to object‑based context eliminates redundant processing and dramatically shrinks the active prompt.

The CarryOn Framework

CarryOn reorganizes long‑horizon reasoning by folding reusable progress into compact carriers.

Long‑horizon agents repeatedly re‑process the same interaction history, wasting compute and context window. CarryOn replaces that waste with a runtime that folds reusable progress into compact objects, letting the agent continue from established state instead of rebuilding it.

The framework keeps a three‑part view of the agent’s active context—continuation carriers, execution context, and a live tail—so that only new interactions need processing after each fold.

Form the view $V_t = (A_k, E_k, L_t)$.

Compile updates: a new carrier is added for a completed sub‑task, producing $\Delta A_t$.

Execution context is revised to $E_{k+1}$, removing the “need data X” constraint because it is satisfied in $h_{6}$.

After validation, the live tail $L_t$ is folded, yielding a new live tail $L_{t'}=\emptyset$ and updated view $V_{t'}$.

The three components together let the system retain only what is still needed, discarding everything that has already been captured in carriers.

How does CarryOn differ from a simple cache of past outputs?

Unlike a cache that merely stores raw outputs, CarryOn stores structured task objects (carriers) together with execution context and a live tail, enabling the agent to resume execution with full awareness of pending constraints.

Carriers are stable identifiers that point to reusable progress—think of them as bookmarks to completed sub‑tasks that the agent can revisit.

Initial carrier records: $\text{obj}= \{\text{path}=\text{"utils.py"},\ \text{version}=2\}$.

The agent edits the file, creating version 3; the carrier is revised to $\text{obj}'$ with version 3 while retaining the same identity.

Later, a new fold reuses $\text{obj}'$ without needing to re‑read the file, because the carrier already points to the latest version.

Carriers let the system treat evolving artifacts as immutable references, avoiding repeated I/O.

Why aren’t continuation carriers just a list of cached results?

Carriers encode not only the result but also its provenance, versioning, and reuse conditions, which a plain cache cannot represent.

The execution context holds everything the agent still needs to know to keep working—current focus, unresolved constraints, and pending work that isn’t yet captured by carriers.

What kind of information lives in the execution context that isn’t in carriers?

Things like “the agent still needs to fetch data Y” or “the current sub‑task is awaiting confirmation” are kept here until they can be turned into carriers.

The live tail is the raw sequence of interactions that have happened since the last fold; it remains accessible until it is folded into carriers.

Why keep the recent interactions at all if carriers already store reusable progress?

Because not every interaction immediately yields a reusable carrier; the live tail preserves those raw steps until they become useful.

Tracking Candidates – the Tracker scans the live tail for progress that could become a carrier.

Preparing Evidence – for each selected candidate, CarryOn gathers the supporting material (environment objects, source excerpts, or condition checks).

Joint Compilation – the Compiler proposes carrier edits $\Delta A_t$ and a revised execution context $E_{k+1}$ based on the prepared evidence and the full live tail projection $\Pi(L_t)$.

Validation and Commitment – the system verifies that edits are consistent with current versions and then atomically applies them, folding the covered interactions.

How does this four‑stage pipeline avoid the cost of re‑processing the whole interaction history?

Only the live tail is examined; carriers and execution context are updated incrementally, so the system never recomputes already‑folded interactions.

**Figure 2.** Overview of the CarryOn framework. CarryOn maintains an object-oriented context view comprising continuation carriers, execution context, and a live tail. When invoked, it tracks reusable progress, binds supporting evidence, checks relevant environment conditions, and jointly compiles carrier and execution-context updates. A successful fold commits validated updates and retires covered live-tail interactions from active context, while interaction log remains append-only.

CarryOn reduces total token usage on OSWorld 2.0 by 51.9 % compared with the baseline.

Table 2 shows the baseline total tokens of 40.10 M versus 19.30 M after applying CarryOn.

CarryOn cuts total cost per task on OSWorld 2.0 by 35.9 %.

Table 2 reports baseline cost $44.6 versus \$23.62 after CarryOn.

On BrowseComp‑Plus, CarryOn lowers total token usage by 22.9 %.

Table 2 lists baseline total tokens 1.56 M versus 1.20 M after CarryOn.

CarryOn reduces total cost per task on BrowseComp‑Plus by 7.1 %.

Baseline cost $1.86 versus \$1.76 after CarryOn, as shown in Table 2.

CarryOn improves binary task scores on OSWorld 2.0 by +3.7 %.

Table 1 reports a binary score increase from the baseline to 3.7 % higher with CarryOn.

CarryOn improves partial task scores on OSWorld 2.0 by +5.8 %.

Table 1 shows a partial score increase of 5.8 % when using CarryOn.

Performance and Resource Analysis

CarryOn slashes token use and cost while keeping or boosting task performance.

OSWorld 2.0 is a simulated environment that strings together dozens of interdependent actions, forcing an agent to keep track of a long interaction history.

BrowseComp‑Plus tests an agent’s ability to perform multi‑step web searches, aggregating information from many retrieved documents before answering a question.

CarryOn cuts total token usage by 51.9 % on OSWorld 2.0 while raising the partial score from 43.9 % to 49.7 % and the binary score from 15.7 % to 19.4 %.

Token‑usage reduction measured over 500‑step trajectories; partial and binary scores follow the official OSWorld evaluation protocol.

CarryOn reduces per‑task cost by 35.9 % on OSWorld 2.0, achieving the same performance gains.

Cost includes both model inference and context‑management calls, summed over the full trajectory.

**Figure 3.** **Context and cost dynamics on OSWorld 2.0.** (a) Mean input context size and (b) mean cumulative model cost over agent turns. CarryOn keeps input context near 65K tokens while the baseline continues to grow, and its cost advantage widens with trajectory length, reaching a 34.1% reduction by turn 500. Gray bars indicate the fraction of baseline trajectories remaining active; costs include context-management overhead.

**Table 3.** Task performance on the 100-question subset of BrowseComp-Plus. CarryOn improves the accuracy over the same Claude Opus 4.7 by 7%.

CarryOn significantly reduces token usage and cost while maintaining or improving accuracy.

Ablation and Dynamics Analysis

Assessing how Continuation Carriers affect agent efficiency and reuse.

A Continuation Carrier is a reusable task object that stores progress across folds, enabling the agent to pick up where it left off. We evaluate the importance of this mechanism by measuring its persistence and by comparing runs with and without carrier records.

Across 494 committed and installed folds, roughly 80 % of carrier records are retained or updated, showing that the Continuation Carrier largely persists through folding.

Retained = 278, Updated = 372, Added = 163; retained‑or‑updated proportion = 650/813 ≈ 80 %.

**Figure 4.** Carrier persistence and continuation after folding. (a) Across committed folds on OSWorld 2.0, 80% of carrier observations are retained or updated rather than newly added. (b) Representative trajectories show the agent continuing directly from reusable task state after earlier interactions have been folded, without repeating the work that produced it.

**Table 9.** Continuing from a populated form (Task 009). Selected steps from a main-experiment CarryOn trajectory. Green highlights continuation from the existing form. Entries are condensed from the recorded trajectory; the submission confirmation is also visible in the saved screenshot.

**Table 10.** Continuing a plan versus reacquiring its inputs (Task 013). Selected steps from the full CarryOn and carrier-masking runs. Green marks continuation of the retained prize plan; red marks renewed uncertainty and repeated acquisition of the price mapping. Quoted spans are exact excerpts from recorded agent reasoning summaries; other descriptions are condensed.

Qualitative Trajectory Analysis

Appendix D details the compiler logic that turns live‑tail evidence into a minimal carrier and residual execution context.

When the live tail shows that a pending obligation has been fulfilled, the compiler records a one‑clause reason and the exact steps that demonstrate the fulfillment, then marks the obligation as resolved.

Step 1 and 2 together demonstrate the email satisfies the format constraint.

Step 3 provides the system‑recorded evidence that the validation succeeded.

The compiler creates a resolution entry: O‑42 → “email verified” with evidence steps [1, 2, 3].

Only when the live tail explicitly shows the validation can the compiler safely retire the obligation; otherwise the task must remain pending.

The compiler treats typed environment carriers and residual‑EC fragments as compact representations that replace the full public live tail.

Information products are the compiled outputs—carrier claims, continuation contracts, and fold summaries—that the compiler emits for downstream consumption.

The compiler’s objective is to emit the smallest possible carrier together with a residual execution context that still lets the next host agent continue after the live tail is deleted.

Reconstruct the current working state from canonical carrier bases, old EC, authorized evidence, and the public live tail.

Emit reusable results as carrier claims, each stating a fact with the narrowest supported scope.

Place the unabsorbed present boundary into the residual EC: current focus, in‑flight state, active constraints, and the next atomic continuation.

Reconcile semantic slots, updating or retracting stale claims while preserving any corrected information.

Simulate deletion of the live tail; retain the compact result only if it honestly replaces the future‑relevant part of the disappearing tail.

Claims, focus, and continuation must reflect only what the source evidence supports; the compiler must not infer success where only an attempt is observed.

The compiler may emit new obligations only when a required duty cannot be satisfied by the current carrier and residual EC.

The compiler atomically commits a transaction that contains frozen information units (carrier claims) and the residual execution context needed for the next step.

Visualizing the carrier + residual EC makes it clear how CarryOn preserves state across complex form‑filling tasks without re‑processing the entire interaction history.

Conclusion and Summary

Conclusion restates CarryOn’s gains and highlights its object‑oriented context management.

CarryOn replaces repeated re‑processing of interaction histories with a runtime that groups context around reusable task objects, updating continuation carriers and execution context as the task evolves.

On OSWorld 2.0, CarryOn lifts the partial score to 49.7 % (up from 43.9 %), cuts token usage by 51.9 % and reduces nominal model cost by 35.9 % despite the added runtime overhead.

On BrowseComp‑Plus, accuracy climbs to 56 % from 49 %, again with lower token consumption and cost, confirming that object‑oriented context management benefits diverse long‑horizon tasks.

**Table 6.** Read-only environment checks in the OSWorld 2.0 integration.

**Table 7.** Agent and CarryOn settings. Output limits are measured in tokens per model call.

Experimental Setup Details

Experimental benchmarks, prior results, and resource accounting details.

OSWorld 2.0 is a long‑horizon benchmark covering seven professional domains and 21 subcategories; each workflow spans multiple desktop and web applications, requiring state tracking and cross‑source reasoning.

For the main evaluation we run the full OSWorld 2.0 set with both the baseline agent and CarryOn, while all ablations use a shared subset of 40 explicitly listed task IDs.

BrowseComp‑Plus provides 830 challenging questions over a fixed 100 195‑document corpus; we evaluate both baseline and CarryOn on a 100‑question subset with BM25 retrieval.

Table 8 lists the nominal token prices (e.g., uncached input $5.00$/M tokens, cache read $0.50$/M) used for all subsequent cost calculations.

Previously reported OSWorld 2.0 results (500‑step) are retained, with Claude models using their native computer‑use interface and other models issuing PyAutoGUI actions; GPT‑5.5 runs actions in batches.

For BrowseComp‑Plus we compute external reference scores using the benchmark authors’ BM25 runs for GPT‑5 and o3, and the BM25 configuration from Robertson et al. 1994 for GPT‑OSS‑120B.

Resource accounting reports per‑task averages, separating agent usage from auxiliary context‑management calls (Tracker, Compiler, or summarizer) and aggregating them into a total.

Token usage is cumulative: any input processed again, even from cache, is counted anew, ensuring the total reflects all tokens the system actually processes.

Cost is derived by multiplying each token category count by its price from Table 8; the sum across all calls yields the per‑task monetary estimate, applied uniformly to both the agent and CarryOn’s auxiliary models.

All averages use unrounded values; rounding is applied only when the final numbers are displayed.

Implementation and Prompting

Implementation prompts for the Tracker and Compiler components.

The meta appendix details the concrete system prompts that drive the Tracker and Compiler runtimes. Terminology is normalized to “continuation carriers” (carriers for short), the host agent, and the runtime scheduler. These prompts encode the duties and input contracts described in the paper.

Tracker system prompt (excerpt)

The Tracker receives the current task, committed records, the live tail, and a state block with candidates and runtime feedback; the Compiler additionally receives authorized compilation requests and their source bindings. Both components output a replacement summary as plain text, preserving message roles, tool actions, observations, and any returned reasoning.

Example of summary‑input payload for GS/CGS

Read the original paper

Open the simplified reader on Paperglide

Browse all simplified papers