1. History

GUI was the right answer for the last era

Early command-line systems were efficient, but they assumed a trained operator. Personal computing changed the user base. Computers were no longer built only for engineers, operators, and specialists; they were being opened to office workers, students, designers, and families.

For those users, the main problem was not raw capability. It was translation. They needed visible objects, consistent controls, a lower memory burden, and a safer way to issue machine instructions. GUI solved that problem. That is why it won.

The important point is that GUI did not replace the machine contract underneath. Software still ran on commands, files, processes, RPCs, and database updates. GUI reorganized those capabilities into something ordinary users could learn and trust. For forty years, that was the correct optimization target, because humans were the bottleneck.

2. Now

Why agents need CLI

Agents can drive a GUI through browser automation or computer-use models. But that is a compatibility technique, not an ideal substrate. It is slower, more brittle, and more ambiguous than calling an explicit capability directly.

Agents perform best when actions are named, parameters are typed, output is structured, and failure states are visible. CLI offers exactly that. It gives the model a stable verb, a clear input surface, parseable output, and a way to chain capabilities together without guessing what a button means today.

Put differently, the reason we keep returning to CLI is not nostalgia for black-screen terminals. It is that CLI provides a low-ambiguity execution contract with at least four properties:

• Actions and parameters are explicitly callable, not buried inside a visual hierarchy.
• Output is structured, so the next step can parse, validate, and reuse it directly.
• Capabilities compose, so multi-step workflows are not trapped inside any single product's UI.
• Failure modes, permission scopes, and logs are all inspectable — supervision, replay, and recovery become tractable.

API and CLI are the same thing in essence. But in desktop software, local tools, and mixed human-agent workflows, CLI remains the most practical way to expose an executable contract. It is scriptable, reviewable, composable, and easy to adopt incrementally.

This changes product economics. Once software demand is increasingly mediated by agents, a feature that exists only inside a deep GUI flow becomes harder to reach, harder to recommend, and harder to compose into a workflow. What used to be a UX detail starts becoming a distribution problem.

3. Next

What happens to GUI in an Agent OS

The next Agent OS will not look like a desktop copied into a chat window. Its primary interaction model will be language: speaking, typing, delegating, confirming. Underneath that, the system will need a real execution layer made of callable tools. That is where CLI + Skills comes in.

CLI provides the executable surface. Skills provide discovery, packaging, typed metadata, permissions, and reuse. Together they turn scattered capabilities into something an agent can reliably find, install, invoke, and combine.

GUI does not disappear, but its role evolves. It stops feeling like a maze the user has to walk through layer by layer, and starts feeling like a results pane — surfacing state, previews, diffs, and risk warnings, then asking for confirmation at the key checkpoints. In other words, the GUI that remains is no longer where users complete operations; it is where they understand outcomes and authorise milestones.

That is why we expect future software to become flatter. Fewer nested controls. Fewer brittle workflows. Fewer screens whose only job is to manually walk the user through steps an agent could execute directly. The richer the agent layer becomes, the simpler the GUI can afford to be. The point is not to drag humans back into terminal life; the point is that software now needs an execution contract that is honest to agents. Once that contract exists, voice and text can become the front door, CLI + Skills can become the machinery underneath, and GUI no longer has to pretend to be the whole operating model.

References

1. Ritchie, D. M., & Thompson, K. (1974). The UNIX Time-Sharing System. Communications of the ACM, 17(7), 365–375. doi.org/10.1145/361011.361061
2. Engelbart, D. C., & English, W. K. (1968). A Research Center for Augmenting Human Intellect. Proceedings of the Fall Joint Computer Conference (AFIPS '68), 395–410. doi.org/10.1145/1476589.1476645
3. Shneiderman, B. (1983). Direct Manipulation: A Step Beyond Programming Languages. IEEE Computer, 16(8), 57–69. doi.org/10.1109/MC.1983.1654471
4. Anthropic. (2025). Claude Code overview. docs.anthropic.com/en/docs/claude-code/overview
5. Anthropic. (2025). Agent Skills. docs.anthropic.com/en/docs/agents-and-tools/agent-skills
6. Model Context Protocol. (2025). Specification and SDKs. modelcontextprotocol.io