What you need to know
- Choose the state an interrupted job needs before selecting its execution environment.
- Track independent snapshots and volumes alongside the working sandbox.
- Evaluate recovery, cleanup and connectivity using a bounded trial and the actual account configuration.
Capital supports the environment around the agent
Daytona has disclosed a $60 million Series B led by FirstMark Growth at a $1 billion valuation. The company describes its agent cloud as the execution environment around a model: computers, browsers and storage where work happens. That is a company description of the product’s role, rather than an independent assessment of its performance.
The purchasing decision becomes clearer when attached to a particular job. An agent revising a document may finish quickly; an agent investigating a software issue may leave files and intermediate results behind while waiting for a person. Our editorial view is that a useful infrastructure review should follow that unfinished work, including the resources that remain after active computation stops.
Decide which state the next attempt needs
Daytona’s persistence documentation distinguishes files from running memory. Container sandboxes retain their filesystem across stop and start but lose memory; Linux VM and Windows sandboxes can preserve both through pause and resume. GPU sandboxes are ephemeral on stop, with volumes available for keeping results. The required behavior therefore depends on the environment selected.
Consider a hypothetical code-investigation job that produces a small set of findings before awaiting review. The team could decide that saved findings and the exact input version are sufficient for a later attempt. A different job may need to resume a running application. Write down that choice before choosing the environment, then check whether recovery delivers the expected starting point.
Include retained resources in the completion decision
The same documentation says snapshots and volumes can persist independently of a sandbox. Deleting the working environment therefore does not necessarily remove every retained copy or result. Teams should account for the resources they deliberately create during a workflow.
A practical pilot could keep a resource record for each job: what was created, what remains useful and who owns its eventual removal. Close a job only after its outputs have an agreed destination and its remaining resources have an explicit purpose. This is a proposed operating practice, not a claim that the platform performs that review automatically.
A recovery exercise could deliberately interrupt a disposable trial before completion. Check whether the person reviewing it can identify the latest accepted result, resume from the intended point and distinguish old outputs from new ones. Record the outcome rather than treating the ability to create another environment as proof that recovery worked.
Check the connections a resumed job will use
Daytona’s network documentation says outbound access depends on the organization’s tier and sandbox policy. Lower tiers retain organization-level restrictions; higher tiers permit custom sandbox rules. An evaluation should use the actual account configuration rather than assume every environment has the same connectivity.
When a trial resumes, verify that the destinations needed for its intended task remain reachable and that the resulting work can be reviewed. Keep that check alongside the retention decision. An agent cloud becomes easier to evaluate when the buyer can explain what survives an interruption, how the job continues and what remains when it is finally complete.
