ModelRefs / Code-Execution Agent — Agent Pattern
Code-Execution Agent — Agent Pattern
Agent generates and runs code in a sandbox, reading stdout/stderr back into its context.
Overview
The model writes Python (or shell) code, a sandbox executes it, and the agent reads results back. Used for data analysis, file work, and ad-hoc computation that exceeds the LLM's arithmetic reliability.
When to use it: You need an agent that handles open-ended data manipulation or computation.
Pattern details
| Pattern class | tool-use |
|---|---|
| Difficulty | advanced |
| Autonomy | autonomous |
| Also known as | code interpreter, python tool |
| Last reviewed | 2026-06-07 |
Known failure modes
- Sandbox escape — Code accesses host resources. Mitigation: Use a real sandbox (E2B, Modal, gVisor); never exec on the host.
- Infinite execution — Code spins forever. Mitigation: Per-cell timeout (e.g. 30s) and memory cap.
When not to use it
- Running model-written code on the host without isolation.
Continue your research
Use these connected ModelRefs sections to compare alternatives, inspect implementation paths, and review the evidence and governance boundaries relevant to Code-Execution Agent — Agent Pattern.
Frequently asked questions
When should I use the Code-Execution Agent agent pattern?
You need an agent that handles open-ended data manipulation or computation.
What are common failure modes of Code-Execution Agent?
Sandbox escape • Infinite execution
Is Code-Execution Agent production-ready?
Yes when paired with the safety controls and observability hooks documented on the pattern page.