CarryOn organizes long-horizon agent context around task objects, not histories
The paper starts from an observation about long-horizon agents: they accumulate progress in persistent task state, yet keep re-processing the interaction histories that describe how that progress was achieved. The authors ask whether long-horizon context can instead be organized around reusable progress rather than the history that produced it.
Their answer is CarryOn, which they call an object-oriented context runtime. It 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 three parts: continuation carriers, complementary execution context, and a live tail of recent interactions.
The stated core challenge is keeping this reusable basis valid after the surrounding history has been retired. In other words, how can the system update the basis without rebuilding the full representation at every fold? CarryOn maintains carrier records across folds. It revises the affected records against bound evidence and applicable environment checks, carries forward the records that are unaffected, and updates the execution context jointly.
For results, the abstract says experiments on OSWorld 2.0 and BrowseComp-Plus show improved gains of 5.8% and 7.0%, while total token usage falls by 51.9% and 22.9%, respectively. The first figure in each pair refers to OSWorld 2.0 and the second to BrowseComp-Plus. The abstract does not say what metric the gains are measured on, whether they are absolute points or relative improvements, or what baselines are used. A project page is linked at https://ethannju.github.io/carryon.
Key facts
- CarryOn is an object-oriented context runtime that organizes agent continuation around reusable task objects instead of compressed interaction histories.
- Its context view combines continuation carriers, complementary execution context, and a live tail of recent interactions.
- Carrier records are revised against bound evidence and environment checks across folds, while unaffected records are carried forward, so the full representation is not rebuilt each time.
- Reported gains are 5.8% on OSWorld 2.0 and 7.0% on BrowseComp-Plus.
- Total token usage drops by 51.9% on OSWorld 2.0 and 22.9% on BrowseComp-Plus.
Why it matters
Long-horizon agents pay a recurring cost: each step re-reads histories that describe how progress was made, even though the progress itself already sits in persistent task state. CarryOn proposes to carry the progress forward as reusable objects and let the history be retired. If that holds up, agents could run longer tasks with fewer tokens. The abstract reports token reductions of 51.9% on OSWorld 2.0 and 22.9% on BrowseComp-Plus alongside the accuracy gains.
Who it affects
The work is aimed at people building long-horizon agents, especially those working on computer-use and web-browsing tasks, since the two benchmarks named are OSWorld 2.0 and BrowseComp-Plus. Teams that pay for tokens on long agent runs are the most obvious audience for the reported savings.
How to use it
The abstract points to a project page at https://ethannju.github.io/carryon and names no released code or models. Conceptually, the approach asks an agent builder to keep task progress as reusable carrier records, rebuild the context view from those records plus execution context and a short live tail of recent interactions, and revise only the records affected by new evidence or environment checks.
How solid is it
This is a paper abstract, and the figures come from the authors' own experiments. The 5.8% and 7.0% gains are given without a named metric, baseline, or indication of whether they are absolute or relative. The token reductions of 51.9% and 22.9% also come without a named baseline. No models, agent backbones, absolute token counts, costs or latency figures are given.
Risks and caveats
The abstract names the central difficulty itself: keeping the reusable basis valid once its surrounding history is retired. Whether CarryOn solves this well in practice cannot be judged from the abstract, which describes no limitations, failure cases or ablations. The headline numbers should be read as reported claims until the metrics and baselines are checked in the full paper.