Not a fancy custom tool. Not a beautifully typed function-calling schema. Just... a terminal.
That's not a limitation. That's the trick.
The problem with "give the model some tools"
When people first started building coding agents, the obvious approach was: define a tool for each thing the model needs to do. A read_file tool. A run_tests tool. A search_code tool. Neat, safe, predictable.
It also doesn't scale.
Think about everything a human engineer actually does at a terminal in a normal day: git diff, curl an API to sanity-check a response, grep through logs, pipe the output of one command into three others, kill a runaway process, check disk space, spin up a Docker container. Nobody pre-designs a tool for each of these. They're all just... already there, because bash gives you access to the entire ecosystem of software ever written for the command line.
If you try to wrap every one of those as a custom "tool" with a schema, you'll be writing tool definitions forever, and you'll still miss the one combination the model actually needed at 2am.
Bash sidesteps the whole problem
Give a model a shell instead of a fixed toolbox, and suddenly git, jq, ffmpeg, psql, every package manager, every compiler — all of it — becomes usable the moment it's installed. Zero marginal integration cost. You're not building tools anymore, you're just... standing next to a terminal the model can type into.
This is the real reason most serious coding agents quietly converge on "bash as the default tool" rather than shipping fifty bespoke integrations.
It also happens to be the model's native language
Here's a detail people underrate: LLMs have seen a lot more shell commands during training than they've seen structured function-calling JSON. READMEs, Stack Overflow answers, Dockerfiles, CI configs, blog posts — bash is everywhere in the corpus. Function-calling schemas, by comparison, are a comparatively thin, recent slice of the training data.
So when a code LLM reaches for find . -name "*.py" | xargs grep -l "TODO", it isn't doing something exotic — it's doing the thing it has seen ten thousand times before. You're playing to the model's actual strengths instead of asking it to operate in an unfamiliar, artificially constrained format.
Composability is the actual superpower
This is the part that's easy to miss if you only think of bash as "a way to call functions."
A fixed set of structured tools is combinatorially closed — the model can only do what you predefined, in the shapes you predefined. Pipes blow that ceiling off. The model can invent a novel chain of five commands it has never seen combined in exactly that way, and it just works, because that's literally what pipes are for.
No one wired this chain up in advance. The model composed it on the fly, the same way a human engineer would. That's not something you can get from a menu of pre-approved tools, no matter how big the menu is.
The real magic: closing the loop
Agentic behavior isn't really about "the model can call a tool." It's about the model being able to see what happened and adjust. That loop — act, observe, correct — is the whole game.
Bash gives you a feedback channel that's structured enough to be useful (exit codes, stderr vs stdout) but flexible enough to describe almost anything that could possibly go wrong. That's a hard needle to thread with a rigid tool schema — you'd need to predict every failure mode in advance and give it its own field.
So is structured tool-calling (MCP, function-calling) pointless?
No — and this is the nuance worth sitting with. Structured tools solve a different problem: safety and guarantees. If you want type-checked outputs, scoped permissions, or a capability you deliberately don't want exposed as "whatever the model can type into a shell," a typed tool is the right call. You wouldn't want your coding agent's only path to your production database to be "run arbitrary SQL via bash."
The pattern that keeps showing up in the field is basically:
Bash as the default, wide-open actuator. Structured tools as the exception, reserved for the places where you specifically want guardrails. Most of the "wow, this agent is smart" moments come from the bash side. Most of the "okay, but I trust this in production" moments come from the structured side.
The takeaway
Bash isn't a stopgap that agentic coding tools will eventually "graduate" away from. It's closer to the opposite: it's the connective tissue that turns a reasoning model into something that can actually operate a computer the way an engineer does — composing tools nobody predefined, reading the results, and adjusting on the fly. Structured tool-calling still earns its place wherever you need real guarantees. But the raw shell is what turns "good at writing code" into "good at getting things done."
If you're designing a coding agent and you find yourself building a fifth custom tool this week, it might be worth asking: could a shell command have just done this already?