The Code-Only Agent

Summary

The Code-Only Agent When Code Execution Really is All You Need If you're building an agent, you're probably overwhelmed. Tools. MCP. Subagents. Skills. The ecosystem pushes you toward complexity, toward "the right way" to do things. You should know: Concepts like "Skills" and "MCP" are actually outcomes of an ongoing learning process of humans figuring stuff out. The space is wide open for exploration. With this mindset I wanted to try something different. Simplify the assumptions. What if the agent only had one tool? Not just any tool, but the most powerful one. The Turing-complete one: execute code. Truly one tool means: no `bash`, no `ls`, no `grep`. Only execute_code. And you enforce it. When you watch an agent run, you might think: "I wonder what tools it'll use to figure this out. Oh look, it ran `ls`. That makes sense. Next, `grep`. Cool." The simpler Code-Only paradigm makes that question irrelevant. The question shifts from "what tools?" to "what code will it produce?" And that's when things get interesting. execute_code: One Tool to Rule Them All Traditional prompting works like this: > Agent, do thing > Agent responds with thing Contrast with: > Agent, do thing > Agent creates and runs code to do thing It does this every time. No, really, every time. Pick a runtime for our Code-Only agent, say Python. It needs to find a file? It writes Python code to find the file and executes the code. Maybe it runs rglob. Maybe it does os.walk. It needs to create a script that crawls a website? It doesn't write the script to your filesystem (reminder: there's no create_file tool to do that!). It writes code to output a script that crawls a website.1 We make it so that there is literally no way for the agent to do anything productive without writing code. So what? Why do this? You're probably thinking, how is this useful? Just give it `bash` tool already man. Let's think a bit more deeply what's happening. Traditional agents respond with something. Tell it to find some D...