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

Mislav Ivanda puts a small piece of code on the screen and asks the audience to guess which agent framework it belongs to. LangChain? LangGraph? Google ADK? He accepts the guesses. In one framework, he would register the code as a tool. In another, he would ship it as a plugin. A third might ask him to extend its sandbox client. Remove that surrounding code and he has trouble telling his own integrations apart.

Ivanda spent a year at Daytona bringing its sandboxes to agent frameworks, coding tools and workflow systems. The common part fit into three operations. Create an environment. Run some work in it and get a result. Delete it. The striking thing about those lines is how little else their callers agree on.

For LangGraph, the designer can lay out a graph of steps. CrewAI lets a group of agents divide up roles and decide how to reach a goal. A model repeatedly choosing the next tool is a different starting point again. Those choices change the code a developer writes. Sooner or later, each design encounters a request that needs a working computer. A model can propose a command or generate a program. Something has to execute it.

An engineer building a prototype usually has a machine ready to hand. It already holds the project, runs the language tools and knows how to reach the development database. A command allowlist or an approval dialog makes it easy to start an agent there and watch what it does. The danger is that the machine’s permissions are much broader than the request displayed in the dialog.

Ivanda uses a language interpreter to explain the mismatch. The name of the tool is short enough to approve. The range of programs it can execute is broad. A permission system that answers “may this agent call the interpreter?” has left a more consequential question unanswered. Which files, services and credentials should this particular task be able to reach?

An embedded runtime such as V8 or QuickJS gives the generated program a more limited environment. The application still supplies the tools. Consider the difference between composing an email in an isolated script and asking the application to send it. Delivery happens with the mail account the host application supplied. The same distinction applies to a database query. The code that receives the callback determines the real scope of the action.

Ivanda prefers to give the agent a separate machine, reached through an API. The application can choose what goes into the workspace, run the task, retrieve its result and discard the machine. An individual step can then fail without losing the process responsible for the rest of the application. Provisioning a separate machine also makes the team decide which tools and data that machine actually needs.

He points to changes he had seen in the frameworks themselves. CrewAI removed a local code interpreter and directed users toward dedicated sandbox services. AG2 replaced older local execution choices with a tool that asks the developer to specify an environment. The OpenAI Agents SDK offered sandbox integrations alongside other execution options. A process with constrained access, a container and a remote machine give the caller different boundaries. A setting called “sandbox” still leaves a developer with a question about what it isolates.

The use of the machine changed as agents improved. Early integrations borrowed one to answer a single tool call. Later, the agent could move in for an entire coding session, using the same files over many steps. Thousands of separate environments could also run a benchmark, explore different solutions or produce independent training runs. The person scheduling that work needs to know which state belongs to each attempt and what to keep when it finishes.

Back to the familiar question of which framework to pick. Replacing one Python framework with another costs engineering time. Changing models can also mean rewriting a prompt and running regression tests. Ivanda puts both into the category of changes a team can plan. Tracing, evaluation and memory can often be added through libraries or integrations. Even sandbox vendors expose recognizable versions of create, run and delete.

Durable execution deserves separate consideration. After a process dies, which step resumes? Which result has already been saved? Those decisions change how the application records work. Ivanda calls this out as a feature he would take seriously up front, even if another feature on the comparison chart looks easy to add later.

The expensive migration begins with a harmless assumption in a tool: the file it needs is on the application server. The next tool reads a host environment variable. A third shares a database connection with the web application. By the time the prototype is in production, moving execution elsewhere means finding those assumptions in every tool and supplying an explicit replacement for each one.

Ivanda’s closing advice is to design an execution interface the application owns. A caller should be able to identify the workspace, supply what a task needs and retrieve an outcome without relying on whichever machine happened to start it. A team can then choose the agent framework that best fits its work today. If that choice changes, its next integration has a familiar job: create the environment, do the work and clean up.