Terminal Agent Team @ Sea AI Lab
LLM systems today are gravitating toward structured “tool protocols”. The most prominent of these, MCP, defines tools through JSON schemas that describe how models can interact with a computer. But here’s the quiet irony: models already know. They’ve seen countless examples of people running commands, inspecting logs, and fixing errors — all through a single interface that’s existed for half a century: the terminal.
Modern tool frameworks like MCP describe every action in meticulous JSON. They are explicit, structured and heavy. To use them, an endless catalog of tool descriptions need to be maintained and explained in the system prompt.
In contrast, a terminal requires no introduction. You don’t need to describe the protocol to use the commands; model just knows how to invoke them from its pretraining data. The model already knows what cat, ls do. It already knows how to navigate, inspect, and manipulate files, and it knows to use--help for showing usage manual.
Why invent and teach the model a new protocol when it already knows one?
It is easy to confuse terminal with the bash tool that is already integrated in many workflows. But when we talk about terminal in this post, it is in many ways different from the bash tool. A real terminal session has states. You can export a variable, define a function, open another interpreter and stay there as long as you like until you quit it. The workspace is continuously evolved instead of starting from zero each time. Most real-world tasks human do in the terminal depend on this progressive interaction.
One simple example is to ask Claude Code / OpenAI Codex to export an environment variable, and in the followup round task it to echo that variable. It is expected to fail because bash tool only performs stateless execution of shell scripts.
Claude Code and OpenAI Codex cannot retrieve the environment variable they previously set using the Bash tool.
A true terminal interface is universal, there is no need to separately implement bash tool, python tool, lua tool, node tool and you name it. LLMs should just open the interpreter of these languages in the terminal like the humans do. In our use case, we can even use the pdb debugger without any extra development. It would have taken quite some nontrivial work if you were to support all the pdb interactive subcommands in the MCP way.
Besides the universality, terminal also handles control sequences, screen redraws, progress bars etc, which makes the output shorter and much more readable than the raw stdout of a subprocess call.
The universal protocol used in the terminal is the read-eval-print-loop (REPL), which is all we expect from a text based environment.
It is a natural protocol that human is used to. LLM can use it as well, except for one obstacle, there is no clear indicating signal that the terminal has finished printing and waiting the next round of interaction. This information is only known within the foreground process currently running.