Picture the task of dropping an image onto a single slide. The AI agent — an AI that works through a task across many steps on its own — has already saved the presentation file with the image in place. But when it starts the next task, it doesn't reopen that file. Instead, it rereads the back-and-forth transcript of how the image got added.
The longer the job runs, the more this record snowballs. It gets slower, more expensive, and starts to remember yesterday's settled decisions a little differently each time — even though the result is sitting right there in the file.
CarryOn's idea is simple. Leave the finished artifact in the environment as-is, and hand the AI only where it is and under what conditions it can be reused.
Existing methods do shrink the context — the full set of information the AI consults at once — but they drift away from the artifact. They fall into two camps. One manages the record: it summarizes, trims the old stuff (a sliding window: keeping only the most recent few and discarding older entries), or retrieves just the parts it needs. The other externalizes state: it copies progress out into a separate note or structure.
Both share the same weakness. Whether it's a summary or a copied-out state, it's ultimately "a compressed description of the original." It slips, bit by bit, away from the artifact the AI actually opens and edits. That slippage is what we call drift.
CarryOn doesn't carry a compressed description around. It leaves the finished product in the environment and hands off only its location and reuse conditions. The effect is visible. In the slide-editing example in Figure 1 of the paper, the amount of information consulted at once balloons to 42,400 tokens — and drops to 14,400 tokens once CarryOn is applied (a 66.0% reduction). On a report task, it falls from 58,400 to 23,500 (59.7%). Here, a token is the unit for counting that quantity of information.
Freeze the work at any given moment and you're holding three things: the presentation file that already has the image in it; the remaining requirements and rules like "cover logo pending replacement" and "keep body font at 11pt"; and the raw, just-exchanged conversation you haven't tidied up yet. CarryOn treats these three like a handover note passed to the next person on the job.
The finished file itself stays put in the environment; only this handover note moves forward.
What a carrier points to — the "output" — isn't necessarily a file. It comes in three forms: a file you can reopen (an external object), a finding that leaves no file behind (an information product), and a screen state valid only within a particular app or session (a situated state).
| Form | What it is | Example | What the carrier records |
|---|---|---|---|
| External Objects | Work that persists independently in the environment and can be reopened and edited | Code files, documents, spreadsheets | The object's location, the progress it holds, reuse conditions |
| Information Products | A finding obtained through interaction that leaves no file behind | Synthesized information, a problem-solving conclusion | The finding and its supporting source, reuse conditions |
| Situated State | Progress valid only within a particular app or session | The state of an open screen | The screen or environment to return to, the established state, scope of validity |
This is where CarryOn gets sharp. What you count as an artifact is exactly what determines when you can throw away the record.
Start with how it works. Once the live tail reaches a certain volume, CarryOn folds it — this tidy-up process is called a fold — moving it into carriers and execution context, and clears the original logs for the folded span. It doesn't rewrite everything from scratch each time. It edits only the records that changed, commits them all at once if verification passes, and leaves the existing records untouched if it fails.
One rule is baked into the fold: a successful tidy-up must change at least one carrier. You can't clear the original logs by touching only the execution context. To see how this seemingly trivial rule plays out in practice, let's follow a case where an approved mock-up gets replaced, all the way through.
Color mock-up A is approved on the grounds that it "reads better on mobile." The carrier records: current decision = mock-up v1, reuse condition = option A, mobile readability. The order and position in which the images were inserted can be discarded, since the file alone suffices. But why option A — the approval condition — can't be recovered from the file alone, so it stays in the carrier. The next day, the designer updates the mock-up to v2. Now that the file version has been replaced, the approval attached to v1 is no longer valid.
Here's where things diverge. If the carrier's "decision = option A" tag isn't updated in step with the file replacement, the agent believes a now-void approval is still good and carries v2 forward as if it were the confirmed version. So the carrier's reuse condition has to capture both which file version the approval was for and that the approval is void if that version changes. But the earlier "change at least one carrier" rule does not guarantee this update happens. A fold is satisfied just by changing some other carrier, and it may touch only other candidates while skipping an unverified one. Making sure the version and approval tags are updated in time with the file replacement isn't something the rule enforces — it's the tidy-up module's responsibility, which is exactly why the "risk of recording the wrong conditions" we'll see later remains.
In the end, where you draw the boundary of the artifact decides when you can discard the log. Draw it too narrow and undiscardable logs pile up; draw it too wide and you have to cram even subtle information like approval rationale into the artifact. Where to draw it is, ultimately, the designer's call.
OSWorld 2.0 is a collection of tasks that directly operate a computer. The same model, with and without CarryOn, is compared on how far it got through the tasks and on the tokens and cost spent per task. There are two kinds of scores: the binary score is the fraction of tasks completed end to end, and the partial score is how far it got partway.
| Metric (OSWorld 2.0 overall) | Baseline | CarryOn |
|---|---|---|
| Partial score | 43.9% | 49.7% (+5.8pp) |
| Binary score | 15.7% | 19.4% (+3.7pp) |
| Total tokens per task | 40.1M | 19.3M (51.9% reduction) |
| Cost per task | $36.8 | $23.6 (35.9% reduction) |
"Total tokens per task" is not the amount read at once but the sum of everything read and written across the whole job. CarryOn's $23.6 is the $20.51 the agent spent on the actual work plus the $3.11 spent tidying up the context, and of the 19.3M total tokens, the tidy-up share is 690,000. Even after adding the management cost, tokens dropped by half and cost by more than a third.
Setup note: Claude Opus 4.7 was used for both the main agent and CarryOn's tidy-up modules (Tracker and Compiler). Up to 500 steps per task were allowed, and scores are reported as both partial and binary, per the official method. Efficiency counts not just what the agent spent but what the tidy-up calls spent on top of it.
Accuracy rises while tokens and cost fall on search tasks too. On BrowseComp-Plus (100 random questions, graded officially by the Qwen3-32B model), accuracy climbed from 49.0% to 56.0% (+7pp), total tokens fell 22.9%, and total cost fell 7.1%. The proportional cost savings come out smaller than on OSWorld — but not because tidy-up takes up a larger share of a smaller job. By the paper's Table 2 the management cost share is actually lower on BrowseComp-Plus (about 8.0%, $0.14 of $1.76) than on OSWorld (about 13.2%, $3.11 of $23.62), and the management token share is lower too (about 2.5% versus 3.6%). Why the proportional savings differ, these numbers don't settle.
The savings compound as the job gets longer. In Figure 3 of the paper, the baseline's context grows throughout the job and crosses 200,000 tokens, while CarryOn's average input context stalls at around 65,000. The cost curve runs higher at first because of the tidy-up calls, but soon crosses the baseline, and by turn 500 it cuts cumulative cost — tidy-up cost included — by 34.1%.
Putting the same artifact-centered principle only inside a summary, versus maintaining it throughout the job, gives different results. Five methods were pitted against each other on a shared set of 40 tasks.
| Method | Post-fold text length (k chars) | Binary (%) | Partial (%) |
|---|---|---|---|
| Baseline | – | 22.50 | 50.32 |
| Sliding window | 12.08 | 15.00 | 37.41 |
| Generic summary (GS) | 17.60 | 15.00 | 44.94 |
| CarryOn-guided summary (CGS) | 23.94 | 20.00 | 50.93 |
| CarryOn | 21.54 | 22.50 | 55.93 |
"Post-fold text length" is the amount left right after a single tidy-up, a different figure from the earlier "total tokens" (everything read and written across the whole job). The baseline score on this set also shouldn't be compared directly with the main results above, since the population differs from the full benchmark.
The observed results are these. The sliding window and the generic summary, which compress the record aggressively, keep the context shortest — but they discard essential information along with it, dropping below the baseline. CGS, which applies the artifact-centered principle only to the summary text, pushed the partial score to 50.93%. Yet the full CarryOn, which maintains that structure throughout the job, scored higher at 55.93% — and the amount left right after tidy-up was actually shorter (21.54k chars versus 23.94k).
The design difference shows up here. CGS rewrites the whole summary from scratch and swaps it in at every fold. CarryOn maintains the record of the same artifact across many folds, editing only the parts that changed. In practice, 80% of carrier records are kept intact or updated across a verified, committed tidy-up.
Interpret this with care. The higher score may be because it reduced the information loss of rewriting from scratch every time, but this design doesn't measure drift directly. The claim that artifact-centered slips less than summarization is only indirectly supported by task scores. To be sure, you'd have to separately count how often the agent rummages back through earlier results or drops a constraint.
The carrier and the execution context can't substitute for each other. Turn off one at a time and it shows. Hide the execution context and the binary score falls from 22.50% to 17.50%, the partial score from 55.93% to 44.00%. The number of agent calls stays nearly the same. The finished artifact is still visible, but with goals, constraints, and remaining requirements gone, the work can't be brought to a close.
Hide the carrier and it moves the other way. The partial score drops to 44.62%, while calls rise 23.8% and cost rises 22.3%. Unable to reach the progress already made, the agent appears to be recovering or rebuilding earlier results. Whether it's "recovering" or "rebuilding" can't be told from these numbers alone.
A single fold turns in four steps.
ONTLE is an AI PM dispatch service that lightens the repetitive work of small businesses and solo founders. When an AI PM takes on a multi-day task like "build a new-product landing page in three days," the slide problem above replays verbatim: it never reopens the file of confirmed copy and only rereads the dragged-out past conversation. In CarryOn terms, the confirmed copy, the deployed mock-up, and the approved color settings each become a carrier that gets handed off, while the editing process folds away.
Whether to adopt it comes down to two gauges (these are assumptions, ahead of any actual rollout).
First, does the approval condition get updated when the file is replaced? The mock-up swap seen above happens exactly this way in real work. If an old approval gets wrongly attached to a new file, the savings eat into quality.
Second, do rework and total cost actually go down? A PM redoing something already finished, or dropping a constraint it should have kept, has to decrease before and after adoption — and the total cost, tidy-up cost included, has to come down.
The questions a reviewer should ask themselves narrow to three. Does my work leave behind outputs I can reopen, or does all of it live only inside the conversation? Is under what conditions that output is valid recorded in the carrier too? And is this job long enough to earn back the cost of folding?
In the current implementation, a successful fold covers the entire recent record at once. A strategy for folding only part of it is outside the scope of this paper.
No. This verification is only a safeguard against the tidy-up process being polluted by contradictory or unsupported content; it doesn't check whether the task itself is correct. Task-level verification has to be handled separately.
You record the finding, its supporting source, and the reuse conditions in an information-product carrier. During tidy-up, there's a step that confirms what was recorded matches the original source.