Skip to main content

Agent-Accessible Products

If agents cannot use your product, agents will replace your product.

The Shift​

Every application on your computer used to be designed for a human clicking buttons in a graphical interface. That era is ending.

AI agents live in the command line. They operate by reading text, executing commands, and parsing structured output. When an agent needs to schedule a meeting, it does not open Google Calendar and click around. It calls an API. When it needs to deploy code, it does not click buttons in a dashboard. It runs a CLI command.

The companies that survive the agentic transition are the ones making their products usable by agents, not just humans. The ones that do not will watch agents route around them entirely.

What "Agent-Accessible" Means​

An agent-accessible product exposes its core functionality through interfaces that agents can use programmatically:

CLI (Command Line Interface). A terminal command that does what the button in your app does. stripe charge create --amount 5000 --currency usd instead of clicking through a payment form. vercel deploy instead of dragging files into a dashboard. gh pr create instead of navigating GitHub's web UI.

API (Application Programming Interface). An HTTP endpoint that accepts structured input and returns structured output. Every SaaS product has a web interface. The ones that matter also have an API that does everything the web interface does.

MCP (Model Context Protocol). The emerging standard for AI agents to discover and use tools. An MCP server tells an agent what capabilities are available, what inputs they need, and what outputs they produce. Think of it as a menu that agents can read.

Structured output. When your product returns data, it should be parseable. JSON, not HTML. Markdown, not PDFs. Plain text, not screenshots. If an agent has to screenshot your UI and use computer vision to read it, you have already lost.

Why This Is Urgent​

Agents are increasingly the ones deciding which tools get used. When a human tells their Personal Jarvis "schedule a meeting with Sarah next Tuesday," the agent picks the tool. If your calendar product has a CLI or API, the agent uses it. If your calendar product is a web-only GUI with no programmatic access, the agent uses a competitor that does have one.

This is already happening:

  • Developers choose Vercel over competitors partly because vercel deploy is a single command
  • Stripe dominates payments partly because its API is legendary
  • GitHub won over alternatives partly because the gh CLI makes every operation scriptable
  • Anthropic built Claude Code as a CLI first, not a desktop app, because that is where agents live

The pattern is clear: the products that win in the agentic economy are the ones that treat CLI and API access as first-class, not as an afterthought bolted on for "power users."

Agent SEO​

There is a new kind of discoverability emerging. Call it agent SEO.

Traditional SEO is about making your product findable by humans searching Google. Agent SEO is about making your product usable by agents operating on behalf of humans. When someone tells their Personal Jarvis to reconcile their books, the agent picks the tool. If your accounting software has a CLI and an API, the agent can use it without the human ever opening your website. If your competitor is GUI-only, the agent cannot use it at all.

The landscape is shifting. Darwinian selection is now favoring companies that make agents' lives easier. Your product's fitness is no longer just about the human experience. It is about the agent experience. Companies that expose CLIs, publish open source skill files for common workflows, and make their APIs trivially accessible will have better agent SEO. Their products will be the ones that agents recommend, integrate with, and default to.

This is not a hypothetical. Switchbooks, a QuickBooks replacement built by Ryland Beard, is a real example. Switchbooks already had an AI agent built into its own UI with about 20 tools, visible memory, and full bookkeeping automation. That was table stakes. After reading this article, Ryland added an MCP server on top of his existing API endpoints. It took him 60 seconds. Not an exaggeration. His API was already built, so exposing it to external agents was trivial. Now any user running Claude Code or any other harness can reconcile their books, create payees, categorize transactions, and pull financial reports without ever opening the Switchbooks UI. The next step is publishing open source skill files for common accounting workflows so that agents can onboard themselves to Switchbooks with zero friction.

The lesson: if your product already has an API (and it should), making it agent-accessible is an afternoon of work. Maybe less. The hard part was building the product. Exposing it to agents is the easy part that most companies are sleeping on.

The CLI Renaissance​

After a decade of IDEs getting heavier and browser-based editors trying to replace local development, the command line has re-emerged as the center of gravity. Existing CLI tools are gaining entirely new utility when paired with AI agents, without requiring any modification.

GitHub's gh CLI is the canonical example. It was designed for human developers, but agents discovered it, configured authentication, and started operating autonomously. Nobody had to build an "agent integration." The CLI was already agent-accessible by virtue of being a well-designed CLI. Polymarket shipped a Rust-based CLI and within days agents were building terminal dashboards, querying markets, and automating trading logic.

The lesson: a good CLI is often the fastest way to make your product usable by agents. You do not need to build a custom integration. You need to build a good CLI.

What to Do If You Build a Product​

1. CLI-ify everything​

Every action a human can take in your GUI should be available as a terminal command. The design principles that make a CLI good for agents are the same ones that make it good for humans:

  • --help that explains intent, not just syntax. An agent reads --help to understand what a command does. Write it for someone who has never seen your product.
  • --json for machine-readable output. Every non-trivial command should support JSON output. This is how agents parse your responses.
  • Non-zero exit codes on failure. Agents detect errors by checking exit codes. If your CLI returns 0 on failure, agents will not know something went wrong.
  • Clear authentication error messages. An agent that gets a cryptic auth error will waste tokens retrying. Tell it exactly what went wrong and how to fix it.
  • One obvious login command. tool auth login, tool auth status. Keep it simple.
  • Stable commands and flags. Treat your CLI surface like an API contract. Breaking changes break agent workflows.

2. API-ify everything​

Every action should be available as an HTTP endpoint. Document it. Make it consistent. If a human can do it by clicking, an agent should be able to do it by calling.

3. Support structured output​

JSON by default. Markdown for human-readable content. Never trap data inside proprietary formats that agents cannot parse.

4. Publish an MCP server​

MCP (Model Context Protocol) is the emerging standard for agents to discover and use tools. Originally created by Anthropic, it was donated to the Linux Foundation's Agentic AI Foundation in late 2025 (co-founded with Block and OpenAI). The ecosystem has grown to over 10,000 active servers with 97 million monthly SDK downloads.

Best practices for MCP servers (from the MCP Best Practice Guide):

  • Single responsibility. One clear domain per server. Focused toolsets, not kitchen-sink implementations.
  • Contracts first. Strict input/output schemas, explicit side effects, documented error handling.
  • OAuth 2.0 authorization. Least-privilege defaults. Per-tool, per-parameter authorization checks.
  • Input validation and output sanitization. Prevent downstream injection attacks.
  • Secrets in secret stores. Never inline credentials. Never rely on the model to keep secrets private.
  • Observability. Structured logging of who, what, when, why. Track success rates, latency, and policy violations.

5. Design for composability​

The output of your tool should be parseable as input by another tool. Agents chain tools together. If your tool's output is a pretty-printed table that cannot be piped, you are breaking the chain.

6. Write an AGENTS.md​

Add a section to your documentation (or a standalone AGENTS.md file) that describes your product's available tools, preferred output formats, authentication flows, and usage rules. This is the "onboarding doc" for agents. One file can be the difference between an agent figuring out your tool in seconds versus burning tokens in confusion.

What to Do If You Use a Product​

When choosing tools for your operation, ask: "Can an agent use this?" If the answer is no, that tool has an expiration date. Prefer products with CLIs, APIs, and open data formats. Your Personal Jarvis can only be as capable as the tools it can access.

This is also why the MVJ architecture uses plain markdown files instead of proprietary apps. Markdown is the most agent-accessible format there is. Any tool can read it. Any agent can write it. No vendor lock-in. No API key required.

Further Reading​

Internal:

External: