A landscape of generative AI has fast shifted from static code generation to autonomous execution. Modern developers are no longer just asking Large Language Models (LLMs) to write a function; they're building systems where the LLM acts as the autonomous agent that writes code, executes it, inspects the output, and iterates on the results, and
this transition from fixed workflows to adaptable, self-reflecting agents opens up massive possibilities for data analysis, system administration, and software engineering. Based on foundational agentic design principles, this post explores the underlying architecture, execution environments. Practical implementation details required to build reliable code-executing agents.
A Triad of Code-Executing Agents
To build the agent capable of running its own code, developers must integrate three distinct components, as explored in recent frameworks for the OpenAI Agents SDK.
- A Model: The brain of the operation, and models must be evaluated on benchmarks like a Berkeley Function Calling Leaderboard or HumanEval. The LLM figure out what files are available, decides an analytical approach, and generates a necessary code.
- The Workspace: A controlled staging area. This is where input files (like CSVs or PDFs) are mounted and where an agent saves its output artifacts.
- An Execution Environment: Since the LLM itself merely generates text, a system requires a secure runtime to execute a code.
Securing an Execution Environment
Executing AI-generated code directly on the host machine is a massive security risk. Traditionally, developers have relied on Docker to package a runtime and isolate the execution. A standard approach involves building a custom Docker image pre-loaded with a necessary data science libraries.
Here is an example Dockerfile that provisions a basic Python environment for data analysis tasks:
FROM python:3.12-slim
ENV MPLBACKEND=Agg
RUN pip install --no-cache-dir numpy scipy pandas matplotlib
WORKDIR /workspace
Notice an inclusion of MPLBACKEND=Agg, and this is a critical configuration for headless agentic environments, as it instructs matplotlib to save figures directly to disk without attempting to render them via a GUI display.
While managing Docker images and local daemons is a common starting point, scaling this architecture in production can be burdensome; for teams looking to bypass the overhead of orchestrating local containers, our Embedenv Compilers & Sandboxes provide a secure, low-latency, Docker-based code execution environment. By offloading execution to Embedenv, developers can instantly run agent-generated code via WebSockets or APIs with enterprise-grade isolation, entirely abstracting away the host-machine management layer.
Case Study: Automating Data Analysis with OpenAI Agents SDK
To grasp the practical implementation of these concepts, consider the scenario where an agent is tasked with time-series anomaly detection on a building energy dataset. The goal is to ingest an hourly dataset (building_energy.csv), compute normal baseline behavior, and output three artifacts: an anomalies dataset, the visualization, and a markdown report, and
using the OpenAI Agents SDK, we can construct the SandboxAgent that connects the LLM to an execution environment.
First, we define a Manifest to map a local dataset into an agent's workspace, and then configure the agent itself:
from pathlib import Path
from agents.sandbox import LocalFile, Manifest
from agents.sandbox import SandboxAgent
manifest = Manifest(
entries={
"input/building_energy.csv": LocalFile(src=Path("data/building_energy.csv")),
},
)
INSTRUCTIONS = """
You are a practical data analyst. Use the sandbox workspace to inspect files,
write and run code when useful, and save clear artifacts. Keep conclusions
grounded in computed evidence. The sandbox has Python with numpy, scipy,
pandas, and matplotlib available.
"""
agent = SandboxAgent(
name="Energy anomaly analyst",
instructions=INSTRUCTIONS.strip(),
model="gpt-4o",
default_manifest=manifest,
)
With an agent configured, a next step is establishing the execution session, and the agent will read the CSV, check data types and row counts, compute robust z-scores for anomaly detection, and save the plot (energy_anomalies.png).
Once an analysis is complete, a sandbox workspace is persisted as a .tar archive, allowing a developer to extract the generated files back to a host system.
Orchestration and the ReAct Pattern
Under a hood, code-executing agents typically follow the ReAct (Reason-then-Act) pattern, a methodology well-documented in guides upon general-purpose AI agent architecture.
A ReAct pattern forces a model into the loop: it reasons about the user's query, selects an action (e.g., executing a Python script), observes an output of that action, and then decides whether to run more code or formulate a final answer, and
building a custom orchestration loop requires parsing the model's output and executing tools dynamically. Below is a robust Python example demonstrating how to orchestrate tool execution based on a LLM's output. Notice how the tool's execution result is fed back in a LLM as working memory:
def orchestrator(llm_agent, llm_output, tools, user_query):
"""
Orchestrates the response based on LLM output and iterates if necessary.
"""
while True:
action = llm_output.get("action")
if action == "tool_call":
tool_name = llm_output.get("tool_name")
tool_params = llm_output.get("tool_params", {})
if tool_name in tools:
try:
# Execute the tool
tool_result = tools[tool_name](**tool_params)
# Send tool output back to the LLM agent for further processing
llm_output = llm_agent({"tool_output": tool_result})
except Exception as e:
return f"Error executing tool '{tool_name}': {str(e)}"
else:
return f"Error: Tool '{tool_name}' not found."
elif action == "return_answer":
# Return the final answer to the user
return llm_output.get("answer", "No answer provided.")
else:
return "Error: Unrecognized action type from LLM output."
Navigating Agentic Limitations
While powerful, these architectures come with significant trade-offs, and code-executing agents are notoriously token-hungry. A single debugging loop can consume tens of thousands of tokens. Also, single-agent architectures are prone to information overload; providing the agent with too much context or too a lot of tools a lot of times degrades its reasoning capabilities.
If your agent requires complex, multi-step debugging across massive codebases, single-agent orchestration will hit the ceiling, and splitting workflows into multi-agent systems—where one agent writes the code, the second reviews it, and the third executes it—regularly yields higher reliability.
Going Local: Privacy-First Code Execution
Cloud-hosted models are convenient. Sending proprietary code to third-party APIs can violate strict data privacy protocols. To address this, developers are increasingly turning to local, open-weights setups, and
as demonstrated in recent explorations of building local AI coding agents, you can construct a completely offline stack using Ollama (a runtime for serving local models), Google's Gemma 4. Opencode (a terminal UI agent runtime).
For workstation use, a gemma4:e4b variant is the excellent choice. Weighing in at 9.6 GB and utilizing 4-bit quantization (GGUF format), it can be run upon modern laptops equipped with at least 8 GB of VRAM. More importantly, it boasts an expansive 128K context window.
To configure OpenCode to interface with a local Gemma 4 model via Ollama's OpenAI-compatible endpoint, you create an opencode.json configuration file in your project root:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (local)",
"options": {
"baseURL": "http://localhost:11434/v1"
},
"models": {
"gemma4:e4b-128k": {
"name": "Gemma 4 E4B 128K"
}
}
}
},
"model": "ollama/gemma4:e4b-128k"
}
Connecting External Tools securely
Whether your agent is powered by the local instance of Gemma 4 or a cloud model, extending its capabilities beyond basic python scripts requires external tools. Modern agents achieve this via Model Context Protocol (MCP) servers, which allow the agent to interact with internal APIs, databases, or file systems.
Hosting these tool servers securely is critical. Embedenv MCP Sandboxes act as isolated runtime environments specifically engineered to host MCP servers, and they empower your LLM agents to safely interact with external tools and sensitive files without exposing your core infrastructure to rogue AI actions, and
also, as teams scale these agentic workflows, debugging an exact steps the agent took becomes the collaborative effort. An Embedenv Collaborative IDE Workspace provides a fully interactive, Replit-like environment where multiple developers can pair-program, monitor an agent's shell output. Trace the execution logic in real-time, drastically reducing the friction of managing autonomous systems.
Key Takeaways
Building the LLM agent that can reliably write and execute code transforms the model from a passive generator into an active problem solver, and to architect these systems successfully:
- Define Clear Constraints: Use structured generation and specific system prompts to enforce communication standards (like a ReAct pattern).
- Isolate Execution: Never run agent code on a host machine, and make use of secure Docker configurations or managed solutions like Embedenv to sandbox the execution environment.
- Control the Workspace: Be explicit about the files being staged in the workspace and a specific artifacts an agent is expected to extract back out.
- Balance Performance and Privacy: For prototyping or working with sensitive intellectual property, leveraging local setups with models like Gemma 4 and OpenCode offers a cost-effective, highly secure alternative to cloud APIs.
By mastering an orchestration of models, workspaces. Isolated runtimes, developers can build robust autonomous agents capable of handling complex, real-world engineering tasks.