Someone built a coffee shop you order from via SSH.
Not a joke. Not a demo. A real business called terminal.shop. You type ssh terminal.shop and you can buy coffee from your command line.
If that strikes you as a fun gimmick, you’re missing what it actually is. It’s a statement about where the interesting software is being built right now.
Because here’s what I keep noticing: the most advanced AI systems that exist today all live in the terminal.
Claude Code. Codex. OpenCode. The coding agents that are actually pushing the frontier of autonomous, multi-step work. They’re all CLI-native. Not by accident. By design. They don’t render dashboards. They call commands, read outputs, chain workflows, and loop.
Meanwhile developers are rediscovering the terminal in their own right. Ghostty, Warp, the whole TUI renaissance. The terminal isn’t dying. It’s getting rebuilt for the next era.
So here’s the thing I want product leaders to sit with: the terminal isn’t where retro developers go to feel cool. It’s where agents operate. And if your product isn’t there, it’s invisible to a whole emerging layer of software.
I’ve been writing for a while about what happens when agents become the primary operators of enterprise software. In “The Death of the Application” I argued that the UI layer is going to collapse. Agents don’t click. They don’t scroll. They don’t navigate dropdown menus. They call functions and read responses.
This post is the practical follow-up. If you’re a SaaS vendor, a data product owner, or anyone shipping software that other companies use, how do you actually make your product agent-ready?
The answer is a three-layer stack.
API-first. Your capabilities have to exist programmatically, not just visually. Every meaningful action a user can take in your UI should be available as an API call. This is table stakes. If your product is GUI-first and API-second, you’ve built a human-only product.
MCP. Model Context Protocol is becoming the standard for how LLMs discover and use tools. Exposing your product as an MCP server puts you in the agent’s toolbelt without requiring every orchestration layer to write a custom integration. You go from “the agent has to be taught to use our API” to “the agent already knows how.”
CLI. The universal interface. Any agent, any framework, any workflow can shell out to a command. A CLI is the lowest-common-denominator way of making your product callable from any agentic context, including the ones that haven’t been invented yet.
These aren’t alternatives. They’re a progression. API-first is the foundation. MCP makes you discoverable. CLI makes you universal.
Here’s the test. Anything your UI can do, an agent should be able to do too. If a human can click it and an agent can’t call it, you’ve built part of your product in a place that’s inaccessible to the fastest-growing consumer of software on the planet.
Here’s the uncomfortable thing for SaaS vendors: the walled garden model is over.
For twenty years the play has been to build the most beautiful, opinionated, end-to-end experience possible. A product so polished and complete that the customer doesn’t want to leave. Stickiness through UI. Lock-in through workflow.
That playbook assumed the user was a human. When the user is an agent, or more accurately when a human is using an agent to orchestrate across ten different products, the beautiful UI becomes a liability. It’s a wall between your product and the orchestration layer.
The vendors who win the next decade are the ones who stop trying to be the destination and start trying to be the canvas. Clean APIs. MCP servers. CLIs. Documentation agents can actually parse. Everything composable, everything callable.
And if you’re on the buying side of this, if you’re a data leader or an engineering leader evaluating vendors, CLI access is now a real criterion. Not a nice-to-have. Not a developer experience detail. A question about whether this product can participate in your agentic future at all.
Ask the vendor: “Can an agent use this?”
If the answer is “well, we have an API,” dig further. Is it complete? Is there an MCP server? Is there a CLI? Or is the real product trapped behind a login screen that only humans can get past?
And this isn’t a far-future concern. The coding agents are already here. The enterprise agents are coming fast. The data teams I talk to are already wiring LLMs into analytical workflows, and the first question they hit every time is: “which of our tools can the agent actually talk to?”
The answer to that question is going to shape procurement decisions for the next five years.
One more thing. Building a CLI used to be real engineering work. It isn’t anymore.
The same coding agents that benefit from your CLI can build your CLI. I put one together for my own use to manage the server rack in my basement: provisioning K3s services, handling VMs, backups, DNS, secrets. A real control plane, built mostly by pointing a coding agent at the problem and iterating.
That’s the leverage. The thing you’re building to serve agents, agents can help you build. When someone tells me a CLI is a quarter-long engineering investment, I’m skeptical. Maybe two years ago. Not today.
Someone built a working business on SSH-based commerce. That’s the bar now. If a coffee shop can figure out how to be terminal-native, a $50M ARR SaaS product doesn’t really have an excuse.
Turn your product into a CLI. Not for the developers.
For the agents.