When we started building nonbios, we made a few architectural decisions that went against the grain. No tools. No MCP. No GUI automation. Everything runs through a Linux shell.

At the time, the industry was moving in the opposite direction. Agent frameworks were competing on how many tools they could integrate. MCP was being positioned as the standard for agent-tool communication. Web agents were learning to click buttons and fill forms. The assumption was that agents needed rich, purpose-built interfaces to be useful.

We disagreed.

A new paper from ServiceNow, "Terminal Agents Suffice for Enterprise Automation," now makes the case with data. Their finding is straightforward: a coding agent equipped with nothing but a terminal and a filesystem can match or outperform more complex agent architectures across diverse real-world enterprise systems. The overhead of tool abstractions and GUI automation isn't just unnecessary. It can actually hurt performance.

Why the shell?

nonbios doesn't just use the command line. It operates through a shell, which is an interface to the command line. This distinction matters.

Every major large language model has been trained on enormous amounts of Linux shell content. Man pages, Stack Overflow answers, GitHub repositories, sysadmin guides, READMEs, blog posts, tutorials. The shell is arguably the single most well-represented human-computer interface in LLM training data. When you give a model a shell, you're not asking it to learn a new abstraction. You're meeting it exactly where it already knows how to operate.

This is why nonbios maps everything to the shell. File reads, file writes, file edits, API calls, deployments. There is no secondary layer of tools sitting between the model and the work. The model writes a command, the shell executes it, the model reads the output. That loop is simple, fast, and robust.

Why no tools?

Tools sound helpful in theory. You define a schema, the model calls the tool, the tool returns a result. But every tool you add is an abstraction that the model has to learn to use correctly. It's another interface to maintain, another failure mode to debug, another thing that can drift out of sync with the underlying system.

The shell doesn't have this problem. It's the lowest common denominator. Every API can be called with curl. Every file can be read with cat. Every transformation can be done with standard Unix utilities or a quick script. The model doesn't need a custom tool to interact with Jira or Salesforce or AWS. It just needs the API documentation and a shell.

Why no MCP?

MCP (Model Context Protocol) is being adopted across the industry as a standard way for agents to discover and use tools. When we decided not to support it, that was a conscious bet.

Our reasoning was simple. If your agent operates through a shell, it already has access to everything MCP would give it, and more. MCP is a layer of indirection that makes sense if your agent can't write code. But if your agent can write code and execute it in a shell, MCP is overhead without added capability.

The ServiceNow paper supports this. Their terminal agents matched or outperformed MCP-augmented architectures. The additional complexity didn't translate into better results.

Intelligence is finite. Don't waste it on tools.

The intelligence of an agent is fundamentally dependent on its training. Everything the agent has to learn that isn't already in the training set takes away from the intelligence it can deploy to actually solve the problem at hand.

This is the hidden cost of tool-heavy architectures. When you bundle an agent's working memory and context with dozens of tool definitions, schemas, usage instructions, and response formats, you have fundamentally handicapped it. The agent is now spending cognitive capacity on figuring out which tool to call, how to call it, and how to interpret the result, instead of spending that capacity on the actual task.

Think of it like driving while making a phone call. You can technically do both, but you're unable to bring your full intelligence to bear on driving. The result, eventually, is an accident.

The shell sidesteps this entirely. All of the Linux shell usage, every command, every pattern, every idiom, is already deeply embedded in the training data. The model doesn't need to be taught how to use it. It already knows. We don't need to pollute the working memory of the agent with tool definitions to deploy this intelligence. It's already there, baked into the weights.

This is what keeps nonbios sharp. The context stays minimal. The agent stays unencumbered. All of its intelligence goes toward solving the problem, not toward figuring out how to wield a toolbox.

Agents are the new consumers of software

There's a broader shift happening here that goes beyond agent architecture.

Web interfaces were built for humans. Making agents navigate them is like holding your ear the other way around. It works, technically, but it's deeply inefficient and fragile.

Agents will very soon be the biggest consumers of all web-based software. When that happens, every piece of software will either have an API or be left behind. The companies that understand this early will build API-first. The ones that don't will find themselves locked out of the agentic economy.

This is another reason the shell-first approach works. APIs are how software talks to software. The shell is how you call APIs. The two fit together naturally, without the awkward middle layer of browser automation or tool abstractions.

Simplicity as a feature

The terminal has been the backbone of computing for 50 years. It didn't need reinventing. It just needed a smarter operator.

When we built nonbios, we bet that a strong enough model with a shell would outperform a weaker model with a hundred tools. That bet is looking right. Not because we were prescient, but because the fundamentals pointed in this direction all along. The training data was there. The universality of the shell was there. The composability of Unix pipelines was there.

Sometimes the right architecture is the one that's been sitting in front of us the whole time.

Paper: "Terminal Agents Suffice for Enterprise Automation" by Patrice Bechard, Sai Rajeswar, and the ServiceNow AI team.

‍