How agents talk to your product.

I noticed something a few weeks back.

I wasn't opening dashboards anymore. Neither was the AI agent sitting next to me. We were both just typing commands. gh pr create. vercel deploy. supabase db push. The same operations I used to point-and-click my way through were happening in a terminal. The agent and I were using the same tools.

That sounds small. It isn't.

It reframed something for me. We treat dashboards as the main thing. The CLI as a developer convenience. The API as something other code uses. They feel like separate worlds. They aren't. They're three different doors into the same room, and one of them (the dashboard) is the only one a human ever sees.

Most software was built around the assumption that the human is the user. That assumption is starting to break.

That line was the seed of this issue. The deeper version of the same observation: CLIs are one of the doors, not the only one. Products today have multiple ways an agent can call them, and the next few years of software gets built around all of them. This issue walks through what each one is and what changes when you build with all of them in mind.

The shift, in plain terms

If you've never thought about what a "non-human user" of software looks like, let me put it plainly.

Most software gives you a dashboard. Buttons, screens, settings tabs. You point, you click, you read.

But every product also exposes other ways to be used. None of these are new. APIs and CLIs have existed for decades. They were always how software talked to other software. AI agents are just the newest "other software" that needs them.

Think about Spotify. The app version: open the app, search for a song, tap play. The CLI version, if it existed: type spotify play "song name". The API version (this one is real): another app sending an HTTP request to Spotify's public API. The MCP version, if it existed: ask Claude "play that song you played me last week." Same outcome, different doors.

A robot can't see your screen. It can't move your mouse. It can't tell what's a button and what's a banner ad. But it can absolutely read text, call APIs, and use CLIs. Pictures are hard for software to understand. Words and protocols are not.

Here's the full ecosystem in one breath:

• CLIs. Type a command, the product responds. The lowest-friction surface to ship.
• MCP servers. A standard wire any AI can plug into. Solves the problem where every AI used to need a custom integration with every tool.
• REST APIs. Other code calling your product over the internet. The oldest sibling, the most universal.

Most modern products end up with all three. The rest of this issue takes them one at a time.

CLIs, the easiest entry point

The pattern of any CLI is the same. You name a tool, then a verb, then options. git push origin main. vercel deploy. gh issue list. Once you've used three, you've seen the shape of all of them. They're built to be predictable, because anything reading them (human, script, or agent) needs the shape to be consistent.

If you want to feel this for yourself, the fastest path is GitHub's CLI. Five minutes from nothing to "I can talk to GitHub through words."

Install it.

brew install gh

That's macOS. On Linux, apt install gh. On Windows, winget install --id GitHub.cli.

Authenticate.

gh auth login

See your repos.

gh repo list

That's the same view as github.com, just text. Now the part that matters:

gh issue list --json number,title,state,author

[
  {
    "number": 9543,
    "title": "Add idempotency to webhook delivery retries",
    "state": "OPEN",
    "author": { "login": "octocat" }
  },
  {
    "number": 9541,
    "title": "Document --json flag in quickstart",
    "state": "OPEN",
    "author": { "login": "mona" }
  },
  {
    "number": 9538,
    "title": "Fix CLI auth token refresh on macOS",
    "state": "CLOSED",
    "author": { "login": "defunkt" }
  }
]

That --json flag changes the output from human text into structured data. The kind an agent or script can read directly. Without --json, the agent would have to parse a screenshot. With --json, it just reads the data.

Vercel, Stripe, Supabase, Fly.io all ship the same flag. They figured out something simple: the people reading their CLI output aren't always people anymore. Sometimes it's a script. Increasingly it's an AI.

What does this actually look like in practice? Two real examples. I ask an agent for something. The agent picks the right CLI, reads the context, and runs the command.

$ gh repo create notes-2026 --public --confirm
✓ Created repository ajinkya259/notes-2026 on GitHub
✓ Added remote: https://github.com/ajinkya259/notes-2026.git
✓ Initialized empty Git repository in /Users/ajinkya/notes-2026/.git/

$ fly deploy
==> Verifying app config
--> Verified app config
==> Building image
    Pulling base image...
    Building Dockerfile (12 layers)
--> Build complete
==> Pushing image to Fly
==> Creating release v17 in app 'notes-2026'
==> Deploying notes-2026...
--> Health checks passing on 2/2 instances
--> v17 deployed successfully

A good agent-friendly CLI has four traits. It prints structured data, not pretty text. It uses the same shape every time. It's predictable about success and failure (specific errors, not generic "something went wrong"). And its --help doubles as the manual.

MCP servers, the standard wire

If a CLI is "your product, but typeable," an MCP server is "your product, but plug-in-able."

Underneath, most MCP servers are just standardized wrappers around your existing REST API or CLI. The protocol's job is to give every AI client a consistent way to discover and call those operations. The work it's wrapping is the same HTTP or shell work your product already does. What MCP adds on top is a uniform shape: a way for any agent to ask "what can you do?" and get back a structured list of tool definitions, then call them without writing custom integration code.

Here's the problem MCP solves. Before it existed, every AI tool that wanted to talk to your product needed a custom integration. Claude needed one. ChatGPT needed another. Cursor needed a third. The math was brutal: every AI multiplied by every tool. The integration code never stopped multiplying.

Anthropic released the Model Context Protocol in November 2024. The idea was small: define one standard wire format. Tool vendors implement an MCP server once. AI vendors implement an MCP client once. Now any AI can talk to any tool. The math collapses from n × m to n + m.

It worked. The public registry held about 1,200 MCP servers in early 2025. By April 2026 it had crossed 9,400.

What an MCP server looks like in practice:

The thing that makes MCP feel different in practice: with a server in place, you don't write code to use the product. You ask Claude a question. Claude figures out the MCP call, makes it, returns the answer. The whole interaction is conversational on top, structured underneath.

If your product has a CLI or a REST API, an MCP server is often the next ten lines of work. The cost is small. The reach (every AI client at once) is large.

REST APIs, the older sibling

REST APIs have existed forever. Every modern product has one. What changes when the consumer is an agent is how they get designed.

A REST API is a way for other code to call your product over the internet. You expose URLs (/users, /orders/123, /payments/refund) and other code makes HTTP requests against them. This is what powers every mobile app, every Zapier workflow, every backend integration anyone has ever shipped.

For agents, four things matter more than they used to:

curl https://api.stripe.com/v1/charges \
  -H "Authorization: Bearer sk_test_..." \
  -H "Idempotency-Key: order_1247_charge" \
  -d amount=2000 \
  -d currency=usd \
  -d source=tok_visa

{
  "id": "ch_3PmKj22eZvKYlo2C0iQB1234",
  "object": "charge",
  "amount": 2000,
  "currency": "usd",
  "status": "succeeded",
  "paid": true,
  "created": 1746460800
}

Most products built before 2022 have all four of these problems somewhere. The teams that fixed them earliest are now the easiest to integrate against, and that head start compounds every time a new agent shows up.

What you can actually build with this

Once a product exposes itself across CLI, MCP, and REST, what does that combination unlock?

A range of things, from "useful" to "this would have taken a week of clicking last year."

The pattern is the same in every example. A human sets the goal. The agent reads context through some combination of CLIs, MCP servers, and APIs. The agent acts through the same surfaces. The product never had to build anything new for any of this. It just had to be readable.

The market already voted

If this still reads like opinion, look at the numbers.

Three things are happening at once.

First, agents are getting plugged into real software at real companies. 78% of enterprise AI teams already had at least one production agent talking to a tool through MCP. That's "happening" not "coming."

Second, every major AI vendor (Anthropic, OpenAI, Google, Microsoft, AWS) is building on the same protocols. They aren't competing on glue. They're competing on what runs on top of the glue. The MCP server registry grew almost 8x in a year because every product that wants to be talked to by an agent now ships one.

Third, products themselves are restructuring. Salesforce announced Headless 360 in April 2026. The pitch was one line: every Salesforce capability is now a CLI command, an MCP tool, or an API call. The dashboard isn't going away. It's just no longer the only door.

The pattern across all three shifts: companies aren't deciding whether to expose their products to agents. They're racing to do it first.

What this means if you're building

Pull this thread far enough and a punch list emerges. Not all of it has to be true on day one. All of it should be true by year two.

1. Ship a CLI alongside the dashboard. Default it to JSON output. Return clear, specific errors.
2. Ship an MCP server, even a minimal one. It's almost always a thin wrapper over the CLI or REST API.
3. Every action behind every button needs a code-callable equivalent. Most products have a 30-40% gap.
4. Publish an OpenAPI specification for your REST API. Agents need it more than humans need docs.
5. Make endpoints idempotent. Make errors specific. Add rate-limit headers.

Most teams are at 1 or 2. The teams shipping fastest are at 4 or 5. The pattern that separates them isn't more engineers. It's the recognition that the product has multiple non-human readers, and they're going to keep showing up whether you've prepared for them or not.

The good news: every item has a well-trodden path. There's a Stripe CLI to study. There's an MCP server template to fork. There's an OpenAPI spec format to follow. None of this is greenfield invention.

The line worth remembering