Run the Sweep on Daytona. Keep the tapes.

I like how quickly I can spin up a sandbox in Daytona, give agents work, and tear it down when they’re done. A large rewrite or a cleanup across documentation or tests can touch dozens of files. With Sweeper, I can divide that work across agents and run the changes in parallel. But I don’t want the sessions’ history to disappear when I delete the sandbox.

I’ve already paid for that work. The agent read code, tried an approach, hit errors, and either produced a fix or got stuck. Even if I keep the patch, I still need to know what happened along the way. Otherwise, the next worker can spend another round of tokens discovering the same problem. Running more sessions makes that waste add up faster.

That’s why I want tapes around these Daytona sessions. It records the model exchanges so I can go back and inspect an attempt after the sandbox is gone. Keep those records alongside the resulting files and validation output, and the next sweep has something to learn from. I can give a worker the error a previous attempt hit, or change the shared instructions when several workers make the same mistake.

The sweep already works

This is the pattern I’ve been building with Sweeper, my open source tool for running agent tasks in parallel. In March, I wrote about 842 lint errors, five parallel agents, and 54 minutes. Workers handled individual files, results came back, and stalled files got a different approach in the next round. Then I used the same pattern to update 15 documentation pages.

Sweeper now supports Daytona, so I can run those sessions beyond my laptop. The work can be lint fixes, documentation updates, or a batch of changes across a codebase. The requirement stays the same: a worker needs a bounded task, a way to check its work, and somewhere to save what happened.

I learned the value of that last part through the Pokémon experiments I’ve been writing about here. Recording failures let me inspect why an agent got stuck and use that evidence in later attempts. I want the same continuity when I’m running sessions against real engineering problems.

Keep more than the final patch

The first Sweeper run cleared the lint errors but caused 61 downstream TypeScript errors. Replacing any with specific types fixed individual files while breaking compatibility elsewhere. The final lint count missed that part of the result.

For the next sweep, I want the patches, the sessions, and the validation results together. Which change broke a caller? What did the worker check before it finished? Did another worker already find a fix for the same pattern?

A patch shows what changed. A saved session shows the recorded steps that led there. The validation output tells me whether the change held up. Together, they let me review the work and give the next worker useful context.

At scale, even a small repeated mistake gets expensive. If several workers hit the same dependency problem, I want to fix the shared setup or update their instructions. I need their records to see that pattern.

Save the session before removing the sandbox

By the time a sweep finishes, I’ve paid for more than the files it changed. I’ve paid for the attempts that went nowhere, the errors that sent an agent back to the code, and the checks it ran before calling the task done. I want to be able to come back to that work.

That means saving the data outside the sandbox. tapes keeps the recorded model exchanges; I want the files and check results saved alongside them so I can follow an attempt from the original request through to its outcome.

That’s the collection workflow I’m building toward: I can remove the sandbox and still inspect what happened in every session, including the ones that failed. Spinning up the next batch shouldn’t mean throwing away what I learned from the last one.

Use the data in the next sweep

Sweeper already uses per-file history to change its approach when progress stalls. Its telemetry and sweeper observe help me compare strategies and spend. Keeping the full sessions gives me a way to investigate the results behind those counts.

Before retrying a task, I can pull the failed attempt and include the relevant error. Before changing models, I can inspect whether the failure came from the model, missing context, or a broken environment. When an approach succeeds across several tasks, I can turn it into an instruction and test it on the next batch.

That takes selection and review. Saving everything doesn’t mean putting every transcript into the next prompt. It means the evidence is there when I need to choose what the next worker should know.

One option I’m interested in is running tapes inside the sandbox, then draining the session records into an archive outside it before cleanup. That would need a Daytona integration that confirms the records are saved before deleting the sandbox.

I use Daytona because I want to run more work at once. I want to keep the tapes because that work is valuable after it finishes. The next sweep should start with what the previous one taught me.