A Reddit post from a former Manus backend lead hit a nerve because it described a failure mode many AI teams already recognize: function calling looks clean in demos, then starts to wobble when an agent has to juggle too many tools, too much state, and too many small decisions. The interesting claim was not that schemas are bad. It was that the next reliability gains may come from a smaller action surface, not a bigger one.
Reddit surfaced a product bottleneck that the market can no longer ignore
The trigger for this article was a recent r/LocalLLaMA thread from a former Manus backend lead. The post drew more than 1,600 upvotes and hundreds of comments because it said something blunt that many builders have been circling around for months: after years of building agents, the author no longer wanted a giant catalog of typed tools as the default interface. He preferred a single run(command="...") surface backed by Unix-style commands, pipes, help text, and predictable errors.
That is easy to misread as one more anti-API manifesto. It is not. The more useful reading is architectural. Typed interfaces still matter, especially where permissions, audit trails, or strict parameter validation are non-negotiable. The complaint is narrower than that. Once an agent has to choose between twenty, forty, or eighty overlapping tools, the very act of choosing becomes part of the failure surface. The model spends attention budget on interface selection instead of task completion.
That distinction matters because tool sprawl is now one of the least glamorous and most expensive problems in agent design. Teams keep shipping new capabilities as separate tools: one to search docs, one to read logs, one to inspect a ticket, one to summarize a page, one to open a browser session, one to write a file, one to post a result. Each tool looks reasonable on its own. The system becomes unreasonable in aggregate.
We have seen a parallel pattern in CloudAI’s recent coverage of portfolio model strategy and the growing importance of tool-use performance over generic benchmark theater. The same lesson keeps resurfacing: production reliability is often decided less by raw model IQ than by the shape of the system around it.
Why large tool catalogs quietly make agents worse
Function calling was a real advance. It gave developers structure, explicit schemas, parameter validation, and better logging. For bounded workflows, it is still the adult choice. If an agent only needs a tight set of actions to create a support ticket, fetch an invoice, or update a CRM record, typed tools are hard to beat.
The trouble begins when a narrow toolset turns into a sprawling action menu. Prompt space is finite. Every new tool definition costs tokens, examples, edge cases, and ambiguity. Names that look distinct to a human can blur together for a model under context pressure: search_docs, query_kb, find_page, search_slack, search_confluence. The system designer may know the difference. The model still has to guess in real time.
Anthropic makes this point in a more diplomatic way in its essay on building effective agents. Its advice is almost unfashionably simple: start with the simplest workable pattern, add complexity only when needed, and design toolsets with clear interfaces and readable documentation. That sounds obvious until you look at how many agent products are still trying to win by adding more layers, more abstractions, and more tool wrappers.
In practice, oversized catalogs create three problems at once. First, they raise selection overhead: the model has to decide which interface to use before it can even start the real task. Second, they fragment workflows into brittle handoffs: read something here, transform it there, store it somewhere else, then go back and recover state. Third, they age badly. Tools accumulate faster than they are merged, renamed, or retired.
Humans work around this with tribal knowledge. Good operators learn which commands are aliases, which internal tools are half-broken, which endpoint returns cleaner data, and which workflow is only safe if you do it in a particular order. An agent does not have that kind of office folklore unless you explicitly build it into the interface. That is why a system can look powerful in a product demo and still feel clumsy in week six of real usage.
Why the command line is suddenly back in fashion
The command-line argument is not that shell syntax is magical. It is that a command surface gives the model a compact language for composition. One instruction can read, filter, compare, retry, and continue. The task no longer has to be decomposed into a parade of unrelated schemas if the underlying work is really one flow.
This is also why terminal-style agents are no longer a niche open-source obsession. OpenAI’s launch materials for Codex describe an agent that runs commands, executes tests, works inside isolated environments, and returns terminal logs and evidence the user can inspect. That is the important signal. The market is converging on agents that operate against files, commands, outputs, and verifiable traces, not just chat bubbles with abstract tool names hidden underneath.
There is a deeper reason this fits language models so well. LLMs are trained on enormous volumes of command snippets, README instructions, CI pipelines, stack traces, and troubleshooting threads. They do not “understand” shells the way an experienced operator does, but they are fluent in the grammar: verbs, flags, pipelines, errors, retries, and help text. A compact command layer lets the model work inside a pattern it has already seen millions of times.
That familiarity matters because real work is compositional. Research assistants have to fetch, extract, compare, and summarize. Coding agents have to inspect files, run tests, fix failures, and verify outputs. Operations agents have to read logs, isolate signals, gather artifacts, and hand over a recommendation. These are not neat single-tool moments. They are chains of actions with feedback at every step.
The terminal is good at exactly that kind of work. It is terse. It is inspectable. It produces evidence. It also forces a discipline that many agent products badly need: every useful action should have a name, predictable output, and a recoverable error mode. That is a better operating environment than a chaotic zoo of tool definitions that all look slightly different.
What this architecture gets right about the hard part of agent work
The most important advantage of a smaller action surface is not elegance. It is recovery. Agents fail constantly in small ways. A file is missing. A result is too large. A page times out. A command needs different arguments. In a fragile system, every one of those moments becomes a derailment. In a better one, the error points to the next move.
The Reddit post emphasized help text and error messages, and that point deserves more attention than it got in the original debate. For human users, documentation can live somewhere else. For agents, the interface is the documentation. If a command returns a clean usage example, a short explanation, and a useful next step, the model can often self-correct without burning another turn on confusion.
This lines up with a second lesson from Anthropic’s agent guidance: open-ended agents only become useful when they can get ground truth from the environment as they go. Not guesses. Not summaries of summaries. Real outputs. Terminal-style systems are unusually good at that because they expose raw evidence by default: test results, log lines, diffs, exit codes, file contents. The model does not have to imagine whether it succeeded. It can inspect the trace.
That is one reason coding agents have become the clearest proving ground for this design. They live in an environment where the world talks back. A build passes or fails. A test breaks or it does not. A file changes or it does not. Once you have that feedback loop, the agent can behave less like a one-shot assistant and more like an operator working through a checklist.
There is a wider lesson here for enterprises chasing “AI agents” as a category. Many organizations are still buying the idea at the level of surface features: can it open apps, call tools, route tickets, or navigate a browser? The more important question is whether the system has a compact action grammar and a reliable evidence loop. Without those, autonomy is mostly theater.
Where command layers can go wrong, fast
There is no reason to romanticize this pattern. A command surface can be dramatically more dangerous than typed tools if it is implemented carelessly. Strings are loose. Side effects are easier to hide. Permissions can get fuzzy fast. A shell-like abstraction is not a safety model.
That is why the smartest version of this architecture is not “replace every tool with a shell.” It is “compress exploration, keep hard boundaries for commitment.” Let the agent read, search, compare, transform, and draft inside a smaller, more ergonomic action space. Then require explicit typed interfaces, approvals, or policy checks when it is time to move money, change permissions, delete records, rotate credentials, or touch production systems.
That hybrid pattern feels much more believable than either extreme. It avoids the fantasy that JSON schemas alone solve long-horizon reliability, and it avoids the equally reckless idea that unconstrained command execution is a production strategy. Mature systems will almost certainly mix both approaches: compact command layers for messy work, typed guardrails for risky work.
A practical checklist for teams designing agents in 2026
- Start from workflows, not tools. Map the end-to-end jobs your agent must finish. If three tools nearly always appear together, that is a hint they may belong behind one higher-level command family.
- Collapse synonyms early. Do not let five near-identical search or retrieval tools survive because different teams own them. Merged interfaces are often worth more than one more capability.
- Treat help text as product design. Commands should explain themselves, show examples, and make the next step obvious when something fails.
- Return decision-ready outputs. The model usually needs the next clue, not the whole database dump. Short, structured, inspectable results beat walls of text.
- Keep raw evidence visible. Logs, diffs, exit codes, file paths, and tests should be easy for the agent and the human reviewer to inspect.
- Separate exploration from commitment. Use smaller command surfaces for open-ended work, but keep typed approvals and permissions at irreversible edges.
- Measure recovery, not just success. Track retries, dead ends, tool count per finished task, and how often the agent can self-correct without a human rescue.
This is less glamorous than another benchmark chart, but it is where serious product gains are going to come from. The teams that win with agents this year are unlikely to be the ones with the largest tool registry. They will be the ones with the cleanest operational grammar.
The editorial verdict
The Reddit thread matters because it captured a real shift before many vendors were willing to say it out loud. The next step for agents is not unlimited tool choice. It is better interface design. In practice, that means fewer verbs, clearer outputs, stronger recovery paths, and evidence the model can inspect as it works.
If you are building agents in 2026, the question is no longer whether your model can call tools. Almost all of them can. The better question is whether your system gives the model a sane way to operate when the task stops being neat. That is where command layers, terminal-style runtimes, and stricter typed boundaries are starting to look less like a hacker preference and more like the adult architecture.
FAQ
Is function calling going away?
No. It remains the best option for many bounded and sensitive workflows. The shift is about what should be the default interface for messy, multi-step work.
Why are terminal-style agents gaining traction now?
Because they match the shape of real work: files, logs, tests, commands, retries, and evidence. They also let models operate inside a compact action grammar instead of a long tool menu.
What is the biggest mistake teams make here?
They mistake more tools for more capability. In practice, oversized tool catalogs often make agents slower, more brittle, and harder to debug.
