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

AI summary

Overview

Research area: Long-horizon agent context management / LLM agent runtimes (AI systems, computer-use and web-browsing agents).

Technical level: Intermediate. The core idea is intuitive (organize context around reusable task objects instead of history), but the runtime architecture — carriers, grounder checks, folds, validation — requires familiarity with agent loops and context compression literature.

Scope: The paper proposes CarryOn, a context runtime that replaces covered interaction history with an object-oriented context view made of continuation carriers, execution context, and a live tail, and evaluates it on OSWorld 2.0 and a 100-question subset of BrowseComp-Plus.

What This Paper Is About

Long-horizon agents store progress in two places at once: the actual task state (files, documents, application state) and the interaction history describing how that state was produced. Agents keep re-reading the history even though the state already contains the result. The paper asks whether context can instead be organized around reusable progress rather than the record of how it was achieved, and introduces CarryOn to do so — building a context view from reusable "continuation carriers," complementary execution context, and a short live tail of recent interactions, replacing history through periodic "folds."

Key Contributions

1. An object-oriented framing of long-horizon context. The paper argues that continuation should be anchored on reusable task objects — work products, source-grounded findings, and application states — rather than compressed histories or reconstructed accounts of progress.

2. The CarryOn runtime with a three-part context view. Context is split into continuation carriers (reusable content or object references bound to conditions of use), execution context (active goals, constraints, unresolved issues), and a live tail (interactions since the most recent fold).

3. A fold mechanism that revises rather than reconstructs. A Tracker identifies candidate reusable progress, a Grounder performs read-only environment checks, and a Compiler jointly proposes carrier edits and a revised execution context; validated updates are committed atomically and retire the covered interactions, while unaffected carrier records are carried forward as versioned successors.

4. Empirical evidence that organizing beats compressing. Beyond raw gains, the paper isolates the organizing principle via CarryOn-Guided Summary (CGS) — the same principles applied inside a plain text summary — and shows the full runtime still does better.

Main Findings

• OSWorld 2.0 gains with lower cost: Partial score rises from 43.9% to 49.7% (+5.8%) and binary score from 15.7% to 19.4% (+3.7%) over the same Claude Opus 4.7 (max) host agent, while total token usage drops 51.9% (40.10M to 19.30M total tokens per task) and total cost drops 35.9% ($36.83 to $23.62 per task).

• BrowseComp-Plus gains: On a randomly sampled 100-question subset, accuracy rises from 49% to 56% (+7%), with total token usage down 22.9% (1.56M to 1.20M) and total cost down 7.1% ($1.89 to $1.76).

• Competitive with frontier models: On OSWorld 2.0, CarryOn's 49.7% partial and 19.4% binary exceed reported results for GPT-5.5 (xhigh) (49.5 / 13.0), Claude Opus 4.8 (max) (49.3 / 18.5), Claude Sonnet 4.6 (max) (41.5 / 8.3), Claude Sonnet 4.6 (medium) (33.9 / 9.3), MiniMax M3 (22.3 / 4.6), Kimi 2.6 (22.1 / 4.6), and Qwen 3.7-Plus (21.5 / 2.8). On the BrowseComp-Plus subset it reaches 56.00% versus GPT-5 (52.00), o3 (50.00), and GPT-OSS-120B (41.00) with BM25.

• Context stays flat instead of growing: On OSWorld 2.0, baseline input context grows past 200K tokens, while CarryOn's mean input context stabilizes at roughly 65K tokens. Cumulative cost curves cross before turn 200, and by turn 500 CarryOn reduces cumulative cost by 34.1%, including context-management overhead.

• Compression alone hurts; organizing helps: On a shared 40-task OSWorld 2.0 subset, Sliding Window (12.08k characters retained) and Generic Summary (17.60k characters) fall to 37.41% and 44.94% partial versus a 50.32% baseline. CarryOn-Guided Summary recovers to 50.93%, and full CarryOn reaches 55.93% — 5.00% higher than CGS with about 10% shorter post-fold text (21.54k vs 23.94k characters).

• Carriers and execution context are complementary: Hiding execution context drops partial score from 55.93% to 44.00% and binary from 22.50% to 17.50% with little change in agent calls. Hiding continuation carriers drops partial score to 44.62%, while increasing agent calls by 23.8% and cost by 22.3%.

• Progress is maintained, not rebuilt: Across committed folds, 80% of carrier records are retained or updated rather than newly added, supporting the claim that the runtime evolves an existing representation instead of regenerating it each time.

• Per-task context reductions illustrated: In a slide-editing task, active context falls from 42.4K to 14.4K tokens (66.0%); in a lab-report task, from 58.4K to 23.5K tokens (59.7%).

Methodology in Plain English

CarryOn runs alongside the agent rather than inside its prompt. As the agent interacts with the environment, a Tracker watches for progress that might be reusable later — a file that now contains completed edits, a finding assembled from several sources, or an application state that can be returned to. It registers these as candidates and waits until a candidate is ready, then requests compilation.

Before compiling, the runtime gathers evidence: the candidate's supporting sources, the current version of any carrier it would update, and the results of read-only environment checks performed by a Grounder. In the OSWorld 2.0 integration these checks include whether a file exists at its bound path, whether its content hash differs from an initial snapshot, whether it is empty, whether a docx/pptx/xlsx container is structurally valid, whether document text units changed, and whether instruction text was copied verbatim.

A Compiler then does two things at once: it proposes edits to the affected continuation carriers, and it rewrites the execution context using the whole live tail so that goals, constraints, and unfinished work not captured by any carrier stay explicit. Proposed edits are only made for the selected candidates and must be grounded in authorized evidence.

Finally, validation: the runtime checks that edits still match current candidate and carrier versions, that sources are authorized, that identity and reference constraints hold, and that at least one carrier actually changed (an execution-context revision alone cannot retire history). Pass, and the update is committed atomically, with affected carriers getting successor versions and a new fold boundary covering the entire live tail; fail, and nothing changes. The underlying interaction log is append-only, so retired history is not destroyed, just removed from active context.

Evaluation uses Claude Opus 4.7 for the agent, Tracker, and Compiler with no additional training. OSWorld 2.0 (release v2026.08.08) is run on the full evaluation set with a 500-step budget; BrowseComp-Plus uses 100 sampled questions, BM25 retrieval with up to five 512-token snippets per call, and a 60-turn budget. BrowseComp-Plus answers are graded by Qwen3-32B with the benchmark's official prompt. Efficiency is measured as per-task token usage and cost, counting both agent and context-management calls.

Why This Matters

Impact on research. The paper reframes context management: instead of asking how much history to keep, it asks what the history should be replaced by. The CGS comparison is the sharpest piece of evidence — the organizing principle helps even inside a plain text summary, and the full runtime helps more, suggesting the structure itself (not just shorter text) carries value. The ablations also give a clean decomposition: carriers supply progress, execution context supplies purpose, and removing either costs accuracy in different ways.

Real-world applications:

• Software and office automation agents that edit files, spreadsheets, and slide decks across hundreds of steps, where the artifact itself already records the work.
• Deep-research and browsing agents that accumulate retrieved evidence over many search rounds and need prior findings without replaying every snippet.
• Enterprise workflow automation where long multi-application processes must stay under cost and latency budgets while preserving constraints and approvals.
• Assistive and accessibility tooling running extended sessions on a user's behalf, where a bounded working context is a practical requirement.

Industry relevance. The economics are direct: on OSWorld 2.0 the approach cuts cost per task from $36.83 to $23.62 and holds context near 65K tokens instead of letting it exceed 200K, which translates into longer feasible trajectories under fixed budgets. The runtime overhead is explicit and measured ($3.11 of runtime cost on OSWorld 2.0; $0.14 on BrowseComp-Plus), so the trade-off is auditable rather than hidden.

Future Directions

• Correctness vs. consistency of checks. The paper explicitly notes that the validation checks guard against inconsistent or unsupported updates but "do not verify task correctness." Extending checks toward semantic or outcome verification is a natural next step.

• Richer grounding across environments. The Grounder's checks are described for the OSWorld 2.0 integration (file existence, hashes, document structure, instruction-text matching). Generalizing read-only verification to other application surfaces is open.

• Fold granularity. The current implementation commits a fold over the entire live tail when validation succeeds. Whether partial or finer-grained folds improve behavior is not evaluated.

• Beyond the evaluated settings. All results use Claude Opus 4.7 as agent, Tracker, and Compiler, with a 500-step OSWorld 2.0 budget and 100 BrowseComp-Plus questions (out of 830). Whether the gains transfer to other host models, weaker/cheaper models, or the full BrowseComp-Plus set is not reported in this paper.

Target Audience

Researchers and engineers building LLM agents that run for hundreds of steps — particularly those working on context management, memory, and cost reduction for computer-use and deep-research agents. It is also useful for practitioners who need a concrete architectural pattern (carriers, execution context, live tail, folds) rather than a prompt-level summarization trick, and for readers evaluating whether structured state beats compression. Beginners can follow the problem framing and results, but the method sections assume comfort with agent loops, tool-call protocols, and retrieval pipelines.

Authors’ abstract

Long-horizon agents accumulate progress in persistent task state, yet repeatedly process interaction histories describing how that progress was achieved. This raises a natural question: can long-horizon context instead be organized around reusable progress rather than the history that produced it? In this paper, we introduce CarryOn, an object-oriented context runtime that organizes continuation around reusable task objects. Rather than treating compressed histories or reconstructed accounts of progress as the primary basis for continuation, CarryOn builds a context view from continuation carriers, complementary execution context, and a live tail of recent interactions. A core challenge is keeping this reusable basis valid after its surrounding history is retired: how can CarryOn update the basis without reconstructing the full representation at every fold? CarryOn maintains carrier records across folds, revising affected records against bound evidence and applicable environment checks while carrying forward unaffected records and jointly updating execution context. Experiments on OSWorld 2.0 and BrowseComp-Plus show improved gains of 5.8% and 7.0% while reducing total token usage by 51.9% and 22.9%, respectively. Project page: https://ethannju.github.io/carryon