The One Thing Every AI Agent Framework Agrees On with Mislav Ivanda, Daytona

The choice of AI agent execution boundary (local vs. embedded runtime vs. isolated sandbox/VM) is the critical, hard-to-reverse architectural decision that s

The One Thing Every AI Agent Framework Agrees On: Execution Boundaries as the Hard-to-Reverse Architectural Decision

Abstract

This synthesis examines a convergence pattern observed across competing AI agent frameworks: despite fundamental disagreements on agent abstraction, implementation language, and control-flow philosophy, these frameworks consistently converge on the same three-step sandboxing primitive - create, run, delete. Drawing on integration evidence across frameworks such as LangGraph, CrewAI, OpenAI Agents SDK, Claude Agent SDK, Mastra, and AG2, this analysis argues that the execution boundary - where agent code and tool calls actually run - constitutes the critical architectural decision, while framework selection is comparatively reversible. A taxonomy of three isolation tiers is presented, alongside documented 2026 migration patterns away from local execution. Findings indicate that only fully isolated virtual machines contain tool-call side effects, and that teams building tools assuming local execution face costly, sometimes catastrophic, retrofitting. The practical implication is that isolation architecture should precede framework commitment.

1. Introduction

Agent frameworks are libraries that structure control flow around one or more Large Language Model (LLM) calls and the tools those calls invoke. The dominant question practitioners ask when building agentic systems is "which framework should I pick?" This analysis contends that this framing is misdirected, because it elevates a reversible decision above an irreversible one.

The execution boundary is the perimeter separating agent-generated computation from an application's real filesystem, network, and infrastructure. Unlike framework choice - which can be refactored later, often by a coding agent operating within the same language - the execution boundary determines how every tool a team writes is designed. Tools authored under an assumption of local host access carry fundamentally different signatures and trust assumptions than tools authored for an isolated, API-controlled environment. Reversing this assumption after the fact requires rewriting the tooling layer itself, not merely swapping a library.

This synthesis is motivated by a cross-framework observation: Daytona, a sandbox provider, is integrated into a wide range of agent frameworks, harnesses, and developer products, through different mechanisms, yet the underlying operations performed are always identical - sandbox creation, task execution inside it, and sandbox deletion. When frameworks that disagree about nearly everything else agree on this pattern, the convergence signals necessity rather than fashion. The analysis proceeds in four parts: it establishes the conceptual disagreement landscape among frameworks, presents a taxonomy of isolation tiers, documents a 2026 trend of frameworks removing local-execution paths, and traces the evolution of sandbox usage from short-lived task runners to infrastructure for reinforcement learning (RL) and parallel sub-agent execution.

2. Background and Related Work

Agent frameworks do not share a common definition of "agent." LangGraph models an agent as a traversable graph of nodes and edges. CrewAI models agents as autonomous, role-playing entities acting toward delegated goals. The OpenAI Agents SDK treats an agent as a loop wrapped around an LLM call. The Claude Agent SDK, by contrast, ships a largely finished product with minimal customization surface. These differences extend to implementation language, with the ecosystem split predominantly between Python and TypeScript, and to locus of control: Mastra and LangGraph favor explicit, author-defined workflows, while CrewAI favors autonomous model decision-making.

Prior isolation mechanisms from adjacent domains inform current framework design choices. Process-level confinement tools such as bubblewrap, and embedded script engines such as V8 and QuickJS, were originally designed to contain narrower classes of untrusted code - browser scripts or sandboxed subprocesses - rather than autonomous agents capable of invoking arbitrary tool calls. Understanding the original containment scope of these mechanisms is necessary to evaluate their adequacy for agentic workloads, where the risk surface includes not just code execution but the side effects of tool invocations themselves.

3. Core Analysis

3.1 Convergent Integration as Evidence of Necessity

Despite disagreement on agent abstraction, language, and control-flow philosophy, the mechanisms by which frameworks integrate sandbox providers are strikingly uniform. Integration methods vary - exposed as a tool, an external plugin, an extended Sandbox client class, or an internal framework API - but the underlying operations are consistent: create a sandbox, run code or a task inside it, then delete the sandbox. This pattern recurs regardless of how differently each framework conceptualizes the agent itself, suggesting that execution isolation is a structural requirement rather than a stylistic preference tied to any one framework's design philosophy.

3.2 A Taxonomy of Execution Isolation

Three tiers of execution isolation are identifiable across current practice. The first, local isolation, relies on command allow-lists, approval prompts, and interception hooks. Its central flaw is that it defines what a model should use rather than what it can use - granting python -c access, for instance, permits a model to open arbitrary sockets, modify the filesystem, or execute code well beyond the intended scope, regardless of allow-list intent.

The second tier, embedded engine runtimes such as V8 or QuickJS, provides genuine network and filesystem isolation - but only for generated glue code. Tool calls invoked by the agent, such as querying a database or sending an email, execute outside the sandboxed runtime, directly on the host device or infrastructure. This tier isolates the code that orchestrates tool calls, not the consequences of the calls themselves.

The third tier, a separate computer or virtual machine (VM) accessed via API, controls the full lifecycle of the execution environment and never touches local infrastructure, network, or filesystem. Its defining property is articulated in the phrase "compromise the app is not a compromise app": a compromised sandbox can be discarded and respun without compromising the host application. Only this tier contains tool-call side effects, not merely glue-code execution.

3.3 Documented Migration Away from Local Execution (2026)

Observable framework evolution in 2026 corroborates the necessity argument. In April 2026, CrewAI removed its local code interpreter tool entirely, redirecting users to dedicated sandbox services. AG2 retired its legacy local coding executors in favor of a Sandbox Code Tool class that requires explicit environment definition. The Claude Agent SDK defaults to sandboxing, though only at the process level (comparable to bubblewrap on Linux) - a narrower guarantee than full VM isolation. The OpenAI Agents SDK ships a Sandbox Agent with native support for sandbox providers and Docker, yet still transparently permits local code execution with documented flaws; Mastra exhibits a comparable pattern. The consistent direction of change - frameworks removing local-execution alternatives rather than merely adding sandbox options alongside them - indicates that sandboxing is becoming a baseline expectation rather than an optional enhancement.

3.4 Evolution of Sandbox Usage Patterns

Sandbox usage has progressed through three identifiable phases. In the first phase, sandboxes were short-lived machines spun up on demand to execute a single task, then shut down. In the second phase, as model capability increased, practitioners began running the entire agent inside the sandbox as its execution runtime, granting it direct filesystem and network access within the isolated environment. In the most recent phase, thousands of sandboxes are run concurrently, enabling reinforcement learning, fine-tuning, post-training, benchmarking, and the parallel spawning of sub-agents to solve problems simultaneously. This progression indicates that sandbox infrastructure has shifted from a safety mechanism into core computational infrastructure for agent training and orchestration.

4. Technical Insights

Several technical considerations follow directly from the isolation taxonomy. First, the local-execution tier's core limitation is a mismatch between intended and actual capability: defining allow-lists specifies developer intent, not enforceable constraint, and tools such as python -c provide escape hatches regardless of intent. Second, embedded runtimes such as V8 and QuickJS should not be mistaken for full isolation; they secure the orchestration layer while leaving tool-call execution - database deletions, email sends - exposed on the real host. Teams relying on embedded runtimes for security guarantees should audit which operations occur inside versus outside the runtime boundary. Third, of all framework properties, durable execution is unusually difficult to retrofit, because it is woven into core architecture rather than being a swappable feature; this distinguishes it from models, prompts, missing features, or even sandbox providers, which largely speak a common create/run/delete protocol and can be substituted with performance-level rather than architectural consequences. Fourth, process-level sandboxing (e.g., bubblewrap-based approaches in the Claude Agent SDK) occupies a middle ground - stronger than allow-lists, weaker than full VM isolation - and should be evaluated against the specific threat model of tool-call side effects rather than code execution alone.

5. Discussion

The convergence evidence and migration data together suggest that execution isolation has moved from an optional hardening measure to a default architectural requirement, independent of which framework a team selects. This has implications beyond individual project risk: as sandbox infrastructure increasingly underpins RL, fine-tuning, and benchmarking at scale, the isolation decision also affects a team's capacity to adopt training and evaluation workflows that depend on massively parallel, disposable execution environments. Teams that defer this decision are therefore not only accepting security risk but also constraining their future options for model improvement workflows.

A notable gap in current practice is the tendency to build tools during proof-of-concept phases under an assumption of local execution, then never revisit that assumption. Because tool signatures and trust boundaries are authored around the execution environment available at the time, this initial choice calcifies into the system's architecture. By the time isolation becomes necessary - often triggered by a security incident or scaling requirement - the cost of retrofitting can be severe enough to threaten the viability of the product itself. Future investigation might usefully quantify the actual engineering cost of migrating tool layers from local-assumption to isolation-assumption designs, as current evidence is primarily qualitative and anecdotal (e.g., CrewAI's and AG2's 2026 removals of local executors).

6. Conclusion

This analysis establishes that execution isolation, not framework selection, is the architectural decision that most durably shapes agentic systems. Evidence from convergent sandbox integration patterns, a three-tier isolation taxonomy, and documented 2026 framework migrations away from local execution collectively support the conclusion that only full VM-level isolation reliably contains the side effects of agent tool calls. The practical takeaway for engineering teams is to sequence decisions deliberately: resolve the execution boundary question before committing to a framework, since frameworks, models, prompts, and missing features are comparatively swappable, while tooling built on an unexamined execution-boundary assumption is not.

Sources

• The One Thing Every AI Agent Framework Agrees On - Mislav Ivanda, Daytona - Original Creator (YouTube)
• Analysis and summary by Sean Weldon using AI-assisted research tools

About the Author

Sean Weldon is an AI engineer and systems architect specializing in autonomous systems, agentic workflows, and applied machine learning. He builds production AI systems that automate complex business operations.

LinkedIn | Website | GitHub

At 22Atlas, the studio I run, we set Claude up for teams like this one: here is the Claude work we do.