Agents Love the Command Line

For most of software's history, we built one interface — for humans. Clicky, pretty, designed for eyes and mouse hands. Dharmesh Shah (HubSpot's co-founder) just published a piece arguing the next era needs a second interface, designed from the ground up for agents, and the cleanest way to ship it is to do what we did for sysadmins in 1985: build a great CLI. The interesting part isn't the nostalgia. It's that HubSpot is betting its agent strategy on it.

What You Need to Know: HubSpot launched a private-beta "Agent CLI" — a command-line interface built from scratch for agents like Claude Cowork and OpenAI's Codex, not repurposed from a developer CLI. Shah argues the industry has a new dual audience (UX for humans, AX for agents) and that "agent-native" CLIs need to be designed differently than human-facing ones, with token efficiency and structured errors as the primary design constraints.

Why It Matters

• The agent interface problem isn't solved by your existing API. A multi-step workflow that takes a human 5 clicks takes an agent 5 round-trips, each one costing tokens and latency. The protocol that minimizes both is the one designed for atomic, complete operations.
• Repurposing your dev CLI for agents is a trap. Pretty tables, color-coded errors, and human-readable progress messages burn tokens and force agents to parse formatting instead of consuming data.
• UX is not going away. The "AX is the new UX" framing is wrong. You ship both. Companies that treat agent-native interfaces as an afterthought will ship a worse agent product than the ones that design both sides in parallel.
• MCP is the new entrant, not the incumbent. Coverage is still thin. CLIs are the existing substrate most companies have — and the right move is to make them agent-aware, not to wait for an MCP-everything future.
• The HubSpot bet is signaling. When a $30B+ CRM company launches a CLI as its agent strategy, that's a market signal that the GUI-first SaaS playbook is being supplemented, not replaced.

What Actually Happened

The Dual-Interface Argument

Shah's core framing: software has had one audience for fifty years — humans. Dashboards, buttons, chat windows, color palettes, hover states, all of it designed around how we like to work. That audience isn't going away, but there's a second one now, and it doesn't care about any of that.

The second audience is the agent. Its preferences are surprisingly aligned with senior engineers who lived in bash and vim: precise commands, predictable outputs, structured data, low token cost, and errors that are programmatically actionable rather than narratively helpful. The thesis: UX and AX are parallel disciplines, not the same discipline with different skins.

Shah calls out the most common shortcut. A lot of software companies, when asked to "support agents," will surface the developer CLI they already have, point an LLM at it, and call it done. The CLI was written for a human, so it has pretty tables, color codes, and English-language error messages. An agent has to parse all of that, burning tokens on formatting metadata, and is more likely to give up or do the wrong thing. Shipping that as "agent-ready" is a quarter saved and a customer lost. (Source)

The Three Doors an Agent Has

Shah's model of how agents reach into software has three entry points, each with different trade-offs:

• API — built for developers writing integrations. The agent uses it one endpoint at a time, so multi-step work burns tokens on round-trips. This is the worst fit for agentic workflows.
• MCP — Model Context Protocol, "a brand new protocol built for agents, letting them discover what software can do without hard-coded integrations." Coverage is still thin, but the bet is that it becomes the universal agent interface.
• CLI — built for technical users, used for decades. Agents use it for precise commands and structured outputs, but it's typically designed for humans unless you do the work to redesign it.

The mature strategy, Shah argues, is to redesign the CLI deliberately for the agent audience. The work isn't theoretical — HubSpot did it.

What "Agent-Native" Means in Practice

Shah is explicit about the differences. A developer wants a command they can remember and type quickly; the agent wants a command that finishes the whole job in one call. Developers want outputs that look good in a terminal; agents want outputs they can parse without guessing. Developers want errors that help them think; agents want errors they can act on programmatically.

Concretely, that means:

• Atomic commands. One command, one complete operation, not a sequence of three commands an agent has to chain.
• Structured output by default. JSON or similar, not ASCII tables with box-drawing characters. The agent shouldn't have to regex your help text.
• Actionable errors. Error codes and machine-readable fields, not "Sorry, something went wrong. Please contact support if this persists."
• Token efficiency. No marketing copy, no "Welcome to Product X CLI!" banner, no padding in stdout.

The result: the agent stops spending its context budget orchestrating and starts spending it on the actual task.

The HubSpot Agent CLI

HubSpot's private-beta Agent CLI is the proof point. It was designed from the agent's perspective from day one, not retrofitted from the existing developer CLI. The targets named explicitly are Claude Cowork and OpenAI's Codex — i.e., the two leading agent frameworks as of mid-2026.

The bet is twofold. First, that agentic systems will become a major surface for B2B SaaS access, so selling a CLI is selling a product. Second, that the customers who care about agentic access (developers, AI-forward teams, automation shops) are exactly the segment that will grow the fastest, so being the CRM with the best agent interface is a real distribution advantage.

For builders, the practical takeaway isn't "go use HubSpot." It's "go look at your own CLI and ask whether it would still work if the human reading the output was replaced with a model that pays per token." If the answer is "no, the output is too verbose and the errors aren't structured," you have an AX debt problem. (Source)

The Take

I've been writing shell scripts for twenty years and the only thing that surprises me about this argument is how long it took the SaaS industry to rediscover it. The CLI is the lowest-friction interface for any task where the consumer is a machine, and the moment your second user becomes a model, the CLI stops being a power-user feature and starts being the primary surface.

But Shah's framing is too generous to one thing: the "agent-native" rebrand is mostly just good CLI hygiene that we forgot to do. Atomic commands, structured output, no padding — that's what a good CLI looked like in 1995. The reason most modern CLIs don't have those properties is they were written for marketing demos and chat screenshots, not for use. Agent-native design is what you get when the user is a model that doesn't tolerate being marketed at.

The MCP line is the one I'd push back on. Coverage is thin today, but the protocol is solving a real problem (discovery + auth) that the CLI doesn't solve well. A CLI is great when the agent already knows what it wants to do. MCP is the protocol that lets an agent figure out what to do in the first place. Most software products will need both. The interesting design question isn't "CLI vs MCP" — it's "what's the right division of labor between them" — and that answer will look different for a CRM (HubSpot's case, where workflows are well-known) than for a database (where discovery actually matters).

The last thing worth saying: the cost of getting this wrong compounds. A bad agent interface doesn't just make the agent slower, it makes it more likely to fail. And an agent that fails on a customer's actual data is a customer you don't get back. The teams that win the next five years are the ones who treat the agent as a first-class user on day one, not a follow-up ticket six months after launch.

Quick Summary

HubSpot shipped an Agent CLI designed from the agent's perspective — atomic commands, structured output, token-efficient errors. Dharmesh Shah argues modern software needs both a UX and an AX, and the cheapest path to a good AX is rebuilding the CLI, not repackaging the API or waiting for MCP coverage.

Sources

• Simple.ai by Dharmesh Shah — Agents Love the Command Line
• GitHub — awesome-cli-coding-agents
• NxCode — Claude Code vs Codex CLI 2026 Comparison
• MindStudio — Codex vs Claude Code: Which AI Coding Agent Should You Use in 2026