When Nalin Semwal co-founded Capy, he knew that building an IDE for parallel software development required more than traditional architecture. To fulfill developer requests, Capy deploys a Captain orchestrator agent that breaks them down into concurrent subtasks handled by individual Build AI agents. This design made sandbox infrastructure non-negotiable.

From feature requests to bug fixes, every request requires Capy’s Build agents to write files, install dependencies, and trigger test suites. These operations are executed autonomously, and their scope varies by task. Each agent requires an isolated, disposable environment that purges sensitive code and credentials after use.

With execution happening fully inside these sandboxes, they had to hold up under the demands of real engineering work. Developers routinely hand off long-running tasks to their agents, pause them mid-flight, and resume work days later after reviewing the output. Sandboxes had to persist for the duration of agent execution and restore from a precise checkpoint to avoid wasted compute, lost progress, and broken builds.

And those demands had to be met at scale. Capy is built to handle high-level workstreams by design, so even simple developer requests need several sandboxes running simultaneously. Multiplied across users, this workload required sandbox infrastructure that supported significant scale and concurrency without compromising uptime or execution consistency. Critically, sandboxes had to start fast to avoid latency that could undermine the gains of parallel execution.

Nalin knew that in-house sandbox infrastructure required dedicated engineering resources to maintain, so he began evaluating specialized providers. However, most solutions introduced unexpected downtime and limited support, putting agent state and in-progress tasks at risk.

That’s when he found Daytona. Their agent-native runtime platform and flexible sandbox lifecycle management aligned precisely with Capy’s needs.