Your App Needs a CLI for AI Agents

I think agents are going to do most of the ordinary work in an application: the creating, editing and bulk changes people now do by clicking through forms. Humans will still use screens, but I expect the screen to shrink to the things people want to look at, like charts, previews, and the approval page before something irreversible happens. If that’s right, the first question about any app is whether an agent can drive it, and a lot of apps today would have to answer no.

This is a prediction, and I haven’t measured it. The evidence I have is my own daily use of GitHub’s CLI and what Stripe has started writing into its docs for agents.

What my agents do with the GitHub CLI

My coding agents use GitHub’s gh CLI constantly, and I’ve stopped thinking about it.

When a pull request is ready, the agent runs gh pr checks with the --watch flag. Per the manual, --watch keeps watching until the checks finish. If they pass, it runs gh pr merge, which takes the merge strategy as a flag (--squash, --rebase, --merge) and can wait on requirements with --auto, per the merge docs. On my sites a merge to main is a deploy, so that sequence is a gate, and the agent runs it without me.

I have a real scar from that gate. On September 30 I had a command shaped like gh pr checks 28 --watch | tail -1 && gh pr merge 28. The && tested the exit status of tail, which was 0, so it merged a pull request whose CI had failed. A formatting failure went to main and deployed. The fix was in the next PR, and the gate now has no pipe in front of the test: if gh pr checks 28 --watch; then gh pr merge 28; fi. I mention it because exit status is what made the bug findable. The agent branches on it, and when I read the script afterward I could see exactly which exit status the && was testing.

Two more habits. When I want structured data, agents ask for it with --json, which gh pr checks supports with a list of named fields, and for anything the porcelain commands don’t cover they call gh api, which the manual describes as making “an authenticated HTTP request to the GitHub API and prints the response.” We’ve used gh stack, an official extension, for stacked pull requests, but most of our merges now go through GitHub’s merge queue, and the agent still uses the same command. Per the merge docs, when the branch requires a merge queue, gh pr merge adds the pull request to the queue once required checks pass, and turns on auto-merge if they haven’t passed yet.

That’s the whole list of what I’ll claim about gh. I’m not describing a sophisticated setup. An agent reads a command, runs it, reads the text that comes back, and decides what to run next.

Why a CLI suits an agent

An agent works in text. A CLI takes text and returns text, and every flag is a name the agent can read. The agent never has to find a button in a screenshot.

The part I value most is --help. A well-built command documents itself, and the agent reads that documentation exactly when it needs it. It doesn’t have to be loaded into the prompt ahead of time and it doesn’t go stale, because it ships with the binary. An agent that has never seen your tool can run yourapp --help, then yourapp invoices --help, and have a working picture in two calls.

Compare that with the alternatives. Driving the web UI through a browser works, but it is slow and breaks every time someone changes a layout. A raw API works well but leaves the agent to discover which endpoints exist and what the payloads look like. A CLI sits on top of the API and hands the agent a map. It also helps the technical humans. Plenty of people who use your product already live in a terminal and would take their data there if you let them.

I’m not going to turn this into a guide to designing a good CLI. The Command Line Interface Guidelines already cover that. My claim is only that the surface should exist.

DHH wants to bring his own agent

DHH made the same argument at Rails World 2026. Around the 45:23 mark of the keynote he says he would rather bring his own agent than use a chatbot built into the app. Then he gets specific: “if your app doesn’t have a CLI, I want to see it by next Friday,” so that he can use your application “without actually ever having to touch it” (46:05). I covered that segment, the HEY CLI demo, and the four controls I’d put on any agent-facing CLI in my read of the Rails World talk, so I’ll stick to the part of his argument this post depends on.

That part is the division of labor. The vendor doesn’t have to build and maintain a mediocre assistant inside every product, because the user already has an agent they picked and trust. The vendor only has to make the product drivable.

Stripe wrote instructions for the agent

The best example I’ve found of a vendor designing for this is the Stripe CLI’s stripe pay page. The docs for that command speak to the agent directly. The page says: “This command can move money. Use --agent or --json to review transfer details in machine-readable output. Only add --yes after the user confirms the recipient, amount, currency, and source financial account. Use --dry-run to validate the flow without creating or sending the transfer.”

Read that as a spec for how a destructive command should behave when an agent is calling it. There is a flag for machine-readable output, a flag for rehearsing the action, and a confirmation flag the agent is told to add only after a human has agreed to the specific details. The page also says what to do when the recipient is unclear: use Stripe Directory to find candidates, ask the user to choose, and “Don’t guess the recipient.”

The page notes that stripe pay is in preview for eligible US and UK businesses and needs a funded Treasury financial account, so you can’t go use it today unless you qualify. I’m citing it for the design.

What interests me is who the documentation is for. Normally a docs page tells a person what the command does. This one tells the caller how to behave, and it assumes the caller is a model that will follow the instruction. If you ship a CLI, someone is going to point an agent at it. Put the instructions you’d want that agent to follow in the help text and the docs, the way Stripe did for --yes.

The UI keeps what people want to see

If agents handle the ordinary create, read, update and delete work, I think the screen shrinks to the things people want to look at.

Charts and dashboards, because a number in a terminal is worse than a line going up or down. Video, images and previews, because you can’t judge a design from a JSON blob. And the approval screen, the page you see right before something irreversible happens, where a person looks at the real consequence in a form built for human eyes. I think that last one gets more important as agents get more capable, because the agent can prepare the transfer, the deploy or the deletion, and a human still needs a good place to say yes.

What I expect to go away is the part where a person clicks through several screens and fills in a form to do something an agent could do in one command. Settings pages, bulk editors, import wizards and admin tables are the parts I’d expect to see less of, because nobody enjoys them and an agent doesn’t mind.

I argued in SaaS isn’t dead, you’re just not paying for tokens yet that someone still has to patch, secure and keep running whatever gets built, and that the math leaves vendors looking better than the “SaaS is dead” argument assumes. This post makes a narrower claim about the surface. I think the vendors that do well will be the ones whose product an agent can operate, and the interface their customers see most often might not be the web app.

I expect apps that don’t give agents a way in to lose to apps that do. Picture two accounting tools with the same features. A customer tells their agent to reconcile last month, and the agent finishes one of them in a few commands. The other has no CLI, no documented API worth the name and no MCP server, so the agent drives a browser and gets stuck on a date picker.

MCP vs CLI

Whether MCP fits better than a CLI comes down to where the agent runs.

Use a CLI when the agent is local and the user is a developer: a coding agent in a terminal, running commands on a machine the person controls, against credentials the person already has. That is the gh case. The agent gets the same tool a human would, with the same login, and the setup cost is installing a binary.

Use MCP when the person on the other end may not be technical and the vendor needs to enforce the limits itself. Stripe’s Treasury for agents, announced October 21, 2026, is delivered through Stripe’s MCP server. Founders connect their agent to a Treasury account, and the announcement says startups choose which accounts and data agents can reach, whether agents can only read or can also act, and when a human must approve money movement. Those controls are the reason to put a protocol layer between the agent and the money. A protocol gives the vendor a place to enforce them, whatever agent shows up.

Stripe ships both, and both move money. stripe pay leaves the confirmation to the agent and the person at the terminal, which is why its docs spend so many words telling the agent when to add --yes. Treasury for agents puts the account scopes and the approval step on Stripe’s side, through MCP, so they hold whatever agent connects.

I haven’t run a benchmark comparing the two on tokens or speed, and I’d distrust anyone who gives you a clean number without saying how they measured it. The decision turns on where the agent runs and who is accountable for what it does. If you go the MCP route, I walked through building an MCP server in Phoenix.

What I’d do with an existing app

If you own an app, the cheapest place to start is the commands your support team runs by hand and the operations your power users repeat. Expose those as subcommands with --json output, a real exit code, and a --dry-run on anything that writes. Make --help accurate, because the agent will read it before anything else. Then put a scoped token behind it before you hand it to a customer. Credentials are where these projects go wrong, and I’ve written about where agent secrets should live separately.

What I’d watch for

I could be wrong about the timeline. Agents might stay a power-user tool for longer than I think, and most customers might keep clicking through screens for years. A CLI is cheap to build compared with a redesign, though, and it pays off right away for the developers and support staff who already want it. If agents turn out to be the main operator, you’ll have a head start, and if they don’t, you’ll still have a scripting surface your best customers will use.

The test I’d run this week: pick the five things a customer does most often in your product and ask whether an agent could do them end to end without opening a browser. Each one where the answer is no goes on the backlog, starting with the one your support team does by hand most often.

If you’re a founder weighing what to expose and what to leave human-only, that’s a decision I help with as a fractional CTO and vCISO for AI startups, and it’s the kind of thing worth settling before a customer’s agent finds the endpoint you forgot about. The consulting page has the details.

Read next: what DHH said at Rails World 2026, including the part about who owns the code nobody reads.