Code Execution Tool

There is a class of problem a language model should never answer from intuition: summing a column of four thousand numbers, reshaping a CSV, checking whether a pattern really matches. A code execution tool lets the agent stop guessing and compute — it writes a short program, hands it to a real interpreter, and reads back whatever the program produced.

How it works in the loop
The tool’s schema is unusually simple — typically one string argument holding source code — which makes it the most open-ended entry in an agent’s action space. The runtime executes it in a sandbox: a container with a time limit, a memory cap, usually no network, and a scratch directory that can persist between calls, so state built in one step survives into the next. Standard output, errors and any files produced come back as the observation, and a traceback is a genuinely useful one — the agent reads the exception and rewrites the snippet.

What it changes, and what it risks
One open-ended tool shifts the balance of the whole toolset:

• Arithmetic, data wrangling and file conversion become reliable instead of plausible.
• One tool stands in for dozens: rather than registering a tool per operation, the agent composes operations in code — the pattern behind data-analysis agents.
• It is also the widest blast radius available. Code that reads credentials, deletes files or calls out to the network is exactly as runnable as code that adds a column, so sandboxing and permission scoping have to do the work a narrow schema would otherwise do.