Imagine you're moving apartments. You could haul every receipt, packing list, and scribbled note from the last move — or you could just bring the labeled boxes whose contents you already verified. CarryOn argues that long-horizon LLM agents have been doing the receipt-hauling version: stuffing compressed interaction histories into context windows, then re-reading the story of how progress was made instead of just carrying the progress itself. The paper's fix is an object-oriented context runtime that replaces chat-log replay with structured "continuation carriers" — named task objects that persist across context folds. The core claim is concrete: you can organize an agent's working memory around reusable task objects (what was accomplished) rather than compressed histories (how it was accomplished), and this both improves task completion and slashes token costs. On OSWorld 2.0, CarryOn improves success rate by 5.8% absolute while cutting total token usage by 51.9%. On BrowseComp-Plus, the gains are 7.0% accuracy with 22.9% fewer tokens. These are not trivial benchmarks — OSWorld 2.0 involves real desktop environments with multi-step workflows, and BrowseComp-Plus tests information retrieval across extended browsing sessions. Architecturally, CarryOn sits in the "context management for agentic LLMs" family, alongside approaches like SWE-agent's compressed history, MemGPT's tiered memory, and various summarization-based context windowing schemes. The key structural choice is the decomposition of context into three components: carrier records (the reusable task objects), complementary execution context (environment metadata, constraints, tool state), and a live tail of recent interactions. When a context fold occurs — when the agent needs to compress its working memory — CarryOn doesn't reconstruct the full representation from scratch. Instead, it revises only the carrier records affected by new evidence, carries forward unaffected records, and jointly updates the execution context. This incremental update mechanism is the load-bearing architectural novelty. The validation is honest but bounded. Both OSWorld 2.0 and BrowseComp-Plus are community benchmarks with real task complexity, not toy environments. The paper compares against relevant baselines: raw history replay, summarization-based compression, and hybrid approaches. The gains are consistent across both benchmarks, which reduces the chance of benchmark-specific overfitting. However, the evaluation is the authors' own — no independent replication exists yet. The paper does not appear to be pre-registered, and while results are reported across multiple benchmarks, the benchmark selection could reflect post-hoc choices. The deeper contribution is the framing shift itself. The field has been fighting about how to compress history (better summarization, smarter truncation, hierarchical memory) when the question might be what to carry forward. CarryOn says: carry the objects, not the narrative. This is a design pattern, not just a method — and design patterns have longer half-lives than benchmark numbers. The object-oriented framing maps naturally to software engineering intuitions about state management, which makes it immediately legible to practitioners building agent systems. The obvious next experiment is scaling this to truly long horizons — hundreds or thousands of steps where carrier records themselves accumulate and need garbage collection or prioritization. The paper demonstrates the pattern on tasks with enough steps to require context folds, but the regime where carrier record management itself becomes a bottleneck remains untested. My read: this is partly a compute/infrastructure constraint (running massive-horizon evaluations is expensive and slow) and partly being saved for the next paper, since the framework clearly anticipates this extension. For practitioners building agent systems today, the actionable insight is immediate: if your agent replays compressed logs at each step, you're paying a tax in both tokens and accuracy. Restructuring context around persistent task objects — even a rough approximation of CarryOn's full runtime — is likely to yield gains. The 51.9% token reduction on OSWorld 2.0 alone makes this worth prototyping.
