Mislav Ivanda: Choose an execution boundary before an agent framework

Mislav Ivanda introduces his work integrating Daytona sandboxes into agent frameworks, coding-agent harnesses and developer tools. Across these integrations he noticed a repeated pattern, despite substantial differences between the frameworks.

He shows a code sample and asks the audience to guess the framework. Several answers are plausible, he says, because the sandbox-related contributions look very similar even when one framework uses a tool, another a plugin and another a client class.

Under those different interfaces, the same operations recur: create a sandbox, run code or a task within it, and delete it. Ivanda finds that agreement striking because competing frameworks disagree on many other fundamentals.

He contrasts frameworks that describe agents as graphs, collections of role-playing agents, model loops or more complete products. They differ in languages and in whether developers explicitly specify workflows or agents decide their own steps.

Ivanda argues that useful agent workflows eventually need some form of code execution or shell access. The next architectural question is where that code should run and what capabilities it should have.

The first approach is local execution with command allowlists, approval prompts and hooks. Those checks can constrain interactions, but approving a general-purpose interpreter can still let the invoked code access files, open network connections or execute additional code.

The distinction, he says, is between specifying which command the model should use and controlling what the resulting process can actually do. If the process has broad host permissions, a compromised step can exploit those permissions.

The second approach runs generated code in an embedded runtime such as V8 or QuickJS. That can provide filesystem and network isolation for the code running inside the runtime.

Ivanda warns that isolation of generated code is not automatically isolation of every tool it calls. An email or database tool may execute outside the embedded runtime, with its own permissions; a harmful action can therefore cross the boundary through an exposed tool.

His recommended alternative is a separate sandboxed computer or virtual machine managed through an API. The execution environment can be created, used and discarded without deliberately sharing all the application’s host resources.

Ivanda presents this as a way to contain a compromised execution step instead of exposing the entire application. In practice that protection depends on the sandbox’s configuration, network access, credentials and the capabilities of any connected tools.

He gives examples of agent frameworks changing their code execution support, including CrewAI, AG2 and OpenAI’s Agents SDK. His point is that isolation has moved from an optional add-on toward a central execution choice.

Ivanda describes an evolution in sandbox use. Early agents often created a short-lived environment for one task and deleted it; more capable agents can instead run their broader workflow inside an isolated environment.

Running many environments concurrently can also support reinforcement learning, fine-tuning, benchmarks and parallel subagents. These workloads use the same basic ability to provision isolated execution at scale.

This history makes him reconsider the usual question, “Which agent framework should I pick?” He argues that many factors developers compare can be changed later, while the execution boundary is often more fundamental.

Frameworks written in the same language can be migrated through refactoring, he says, and models and prompts can also be changed with tuning and regression tests. Missing features can sometimes be implemented or supplied by external tools.

Ivanda singles out durable execution as a more difficult feature to reproduce quickly because it affects architecture. He regards evaluation, tracing and memory integrations as examples teams can often add separately.

Sandbox providers can also share a basic create-run-delete interface, though they differ in capabilities and performance. He contrasts that with the harder decision of executing locally versus in an external environment.

A local-first prototype may build tools around the host filesystem and application process. If those assumptions persist into production, moving execution behind a separate boundary can require changes across the system.

Ivanda closes with his central advice: choose an execution boundary before choosing a framework. Frameworks express changeable design preferences; execution boundaries become commitments embedded in the architecture.