Your App Needs an Interface an Agent Can Use

When I ask an agent to work with an application, the first obstacle is often not intelligence. It is access to the operation I need. Can it find the right record? Can it update one field without rewriting the rest? Can it check whether the change actually happened? Does the interface describe failure clearly enough to recover without guessing? A dashboard can be excellent for a person and still make those questions difficult for an agent. My view is that applications intended to participate in automated workflows need dependable programmable interfaces. For many products, a useful CLI should be part of that interface—not an afterthought reserved for a small group of developers. That does not mean every website needs a terminal, or that human interfaces should disappear. It means the dashboard should not be the only practical way to use a product's important capabilities.

Agents can click. That is not the whole answer.

Browser and computer-use agents can interact with graphical interfaces. Saying that agents cannot click would miss tools that already exist. But being able to click is different from having a dependable operation. A page may require several interactions to expose a field. A redesign may move a button. A successful click may leave an ambiguous save state. The agent then has to infer whether it has completed the business action from what the screen appears to show. A well-designed programmable interface can give it something more explicit: an operation with documented inputs, a stable identifier, a structured result and a way to read the exact object back. UI automation remains useful, particularly when no better interface exists. I just would not make it the only automation path for a product I expect agents to use regularly.

The API, CLI and tool server have different jobs

An API provides a programmatic contract. It can support custom applications, integrations and automation without tying them to a particular shell or agent framework. A CLI makes operations discoverable and composable from a terminal. It can wrap that API while adding help, convenient authentication, file input and machine-readable output. A person can use it interactively, and an agent can use the same operation in a bounded workflow. An MCP server exposes tools and resources through a protocol that compatible agent clients can discover and call. That can make an integration easier to reuse across hosts, especially when the host already manages structured tool calls. These are complementary options, not a tournament with one permanent winner. CircleCI's comparison offers a useful development-loop framing, but the right choice still depends on the existing product, the operations required and the client's capabilities. A thin tool server that exposes only half the API is not necessarily better than a mature CLI. A CLI that prompts interactively for every step may be awkward for an unattended agent. A direct API integration can be precise but make the caller responsible for more authentication and recovery work.

Products already show the pattern

GitHub CLI explicitly serves terminal use and scripts. It gives people and automation another interface to the same service rather than forcing every task through GitHub's website. Stripe CLI supports building, testing and managing integrations from the command line. Its documentation also includes agent setup, showing how a programmable surface can become part of an agent-oriented development workflow. These examples do not prove that every category of SaaS is becoming CLI-first. They show something more useful: a product can serve human interaction, conventional automation and agent workflows without making one interface do every job.

What I want from an agent-ready CLI

I care less about whether a product advertises an “AI integration” than whether its operations behave well. A practical interface should offer:

Discoverability: clear help and examples, including how to select the right account or environment.
Structured output: stable fields and identifiers that a caller can parse instead of scraping a presentation table.
Complete reads: pagination and explicit completeness signals so a partial result does not look like the whole dataset.
Clear errors: distinguish permission failures, missing objects, invalid input and transient service failures.
Safe writes: previews where appropriate, predictable retry behavior and a way to avoid duplicate creation after an uncertain response.
Read-back: retrieve the exact target after a write, rather than treating an exit-zero command as proof of the intended change.

Some of these properties belong in the underlying API. A good CLI should preserve them, not hide them behind pleasant output.

Access is not authorization

Giving an agent a CLI does not make its commands safe. A shell can reach unrelated files and programs, and an authenticated process may carry more authority than the particular task needs. MCP does not automatically solve that either. Per-user authentication, scoped credentials, audit trails and approval gates depend on the implementation and deployment—not on the protocol name alone. I want boundaries that match the job: the right account, the right environment, the smallest useful authority, and an explicit decision before consequential sends, purchases or destructive changes. The tool should also keep secrets out of normal output. A management command that returns credentials alongside harmless metadata can turn a routine inspection into an exposure.

A new interface, not a new kind of user who replaces everyone

The agent is another caller. Sometimes it represents a developer. Sometimes it helps a person who never intends to learn the CLI themselves. That second case is interesting. A reliable text interface can let a person express an intent naturally while an assistant handles the technical interaction beneath it. The user still needs understandable previews, meaningful approvals and trustworthy results. So my request to application builders is not “replace your dashboard with a shell.” It is: make the important operations accessible through a documented, verifiable contract. Ship a good CLI where it fits. Add structured agent tools where they add value. An agent-ready product should be easier to operate deliberately—not simply easier to operate without supervision.