Bash Outperforms Typed Tools for Enterprise AI Agents
Something unexpected happened on the way to the AI-powered enterprise. The most capable digital workers are not the ones wrapped in polished, purpose-built toolchains. They are the ones handed a shell prompt — the same blinking cursor that has greeted programmers for four decades — and told to get on with it.
That is the finding of a study posted to arXiv by researchers at collaborating institutions. The paper, titled “Is Bash All You Need? An Empirical Study of Tool Interfaces for Enterprise Digital Worker Agents,” puts five different interface designs through their paces on two enterprise benchmarks: TheAgentCompany and APEX-Agents. The results are not marginal. They are the kind of gap that forces a rethink of what “tool use” in AI actually means. The work appears in arXiv.
The Gap Nobody Budgeted For
Enterprise AI deployments have largely assumed that agents need structured, typed interfaces — carefully defined function calls with named parameters and validated outputs. The logic is intuitive: give the model a clean API, and it will use it cleanly. Give it a messy shell, and it will make a mess.
The measurements say otherwise. Bash alone outperformed typed tools on both benchmarks by margins of 21.8 to 24.5 percentage points on TheAgentCompany and 4.8 to 7.4 points on APEX-Agents That is not a rounding error. It is the difference between an agent that can complete a task and one that cannot.
And it did so while consuming 19 to 72 percent fewer tokens The 72 percent figure is the upper bound of that range — the case where bash was not just more capable but dramatically cheaper to run. Fewer tokens means lower cost, faster responses, and less context window pressure. The efficiency gain compounds: a cheaper agent can attempt more tasks, retry more failures, and operate at a scale that typed-tool architectures cannot match within the same budget.
The Contradiction Between Design and Performance
Here is where the story turns strange. Adding typed tools on top of bash produced no detectable pooled score gain. Neither did giving the agent the ability to synthesize its own persistent tools — writing small programs that survive across sessions Both approaches, which represent significant engineering investment and architectural sophistication, failed to move the needle once bash was already in the picture.
Programmatic tool calling, or PTC, offered a middle path. It runs programs whose actions are restricted to a typed tool catalog — essentially a sandboxed shell with guardrails. PTC used fewer tokens than direct typed calls and performed broadly similarly on task quality. But it generally underperformed bash alone in both quality and cost efficiency.
The contradiction is sharp. The more structure researchers added, the less the agent achieved. The interface that imposed the fewest constraints on how the agent could act produced the best results. This is not a story about bash being a better programming language than a Python SDK. It is a story about what happens when you let a capable model decide how to decompose a problem rather than forcing it through a predetermined decomposition.
Why a Shell Beats a Catalog
The explanation is not mysterious, though it is counterintuitive to anyone who has designed APIs for human developers. Typed tools encode assumptions about what tasks look like. A “send email” function assumes the task is sending an email. A “query database” function assumes the task is querying a database. But enterprise work is rarely that clean. It involves moving between applications, coordinating with coworkers, performing professional analysis — the paper’s own framing of what distinguishes enterprise tasks from coding tasks.
A shell does not encode those assumptions. It offers primitives — read, write, execute, pipe — and lets the agent compose them. When a task requires checking a spreadsheet, extracting a value, cross-referencing it against an email thread, and drafting a response, the agent can build that pipeline on the fly. With typed tools, it would need a pre-built function for each step, and a pre-built function for the composition itself. The catalog becomes a bottleneck, not a convenience.
The token savings follow from the same logic. A typed tool call requires the model to emit a structured object with named fields. A bash command is often a single line. The model spends fewer tokens describing what it wants to do and more tokens actually doing it. Across hundreds of steps in a long-horizon task, that difference accumulates.
The Measurement Problem
There is a deeper issue the study surfaces without fully resolving. Benchmarks like TheAgentCompany and APEX-Agents measure task completion. They do not measure whether the agent’s process was auditable, whether it respected compliance boundaries, or whether a human supervisor could reconstruct what happened after the fact. Bash’s advantage in completion rate and token efficiency says nothing about those dimensions.
This is where the paper’s practical recommendation becomes nuanced. For enterprise practitioners, the authors favor bash alone when arbitrary execution can be isolated — meaning the agent runs in an environment where its shell commands cannot escape into production systems or sensitive data. When security or compliance policies require a fixed tool catalog, PTC becomes the better choice despite its lower performance. The recommendation is not “always use bash.” It is “use bash when arbitrary execution can be safely isolated.”
That conditional matters. A shell is powerful precisely because it can do anything the underlying system allows. In a container with no network access and a read-only filesystem, that power is bounded. In an environment with credentials and network reach, it is a liability. The study’s finding that bash wins on performance does not settle the question of whether bash is safe to deploy. It sharpens the trade-off.
What This
Means for the Tool-Building Industry
A significant portion of enterprise AI infrastructure investment has gone into building tool catalogs — connectors, integrations, function definitions, schema registries. The premise is that agents need these to be useful. The study suggests that premise may be wrong, or at least overstated.
If a general shell outperforms a curated catalog, then the value of the catalog shifts. It is no longer the primary interface. It becomes a security boundary, a compliance mechanism, a way to constrain what the agent can do rather than a way to enable what it can do. That is a fundamentally different product category. It is also a smaller one.
The researchers found no pooled score gain from persistent agent-synthesized tools — the agent writing its own tools and reusing them. This is perhaps the most surprising null result. Intuitively, an agent that learns to build reusable abstractions should improve over time. The data says it does not, at least not on these benchmarks. The reason may be that bash already provides the abstractions. The agent does not need to synthesize a “parse CSV” tool when `awk` and `cut` exist. The shell is the persistent tool library.
The Open Question
What the study cannot tell us is whether bash’s advantage holds as models change. The experiments used two of the most capable models available at the time of the study A less capable model might benefit from the scaffolding that typed tools provide. A more capable model might benefit even more from the freedom that bash offers. The direction of the effect as capability increases is unknown.
Nor can the study tell us whether the benchmarks themselves are the right measure. TheAgentCompany and APEX-Agents are designed to simulate enterprise work, but they are simulations. A real enterprise environment includes interruptions, ambiguous instructions, and consequences for failure that no benchmark captures. Bash might perform differently when the cost of a bad command is not a lower score but a corrupted database.
What the study does establish is that the assumption — typed tools are better for agents — is not supported by the evidence. The measured reality is the opposite. And the explanation is not that bash is magic. It is that bash imposes fewer assumptions on the agent, and capable agents do better when they can choose their own decomposition.
That is a finding with consequences that extend beyond interface design. It suggests that the best way to make AI useful in complex environments is not to build more structure around it, but to build better boundaries and then get out of the way. The shell, forty years old and counting, turns out to be a surprisingly good boundary. The question is whether the industry is willing to accept that the tool it spent years building may be the thing standing in the way.
Sources
2. APEX-Agents