Build for Agents: Why CLIs Are the New Distribution Channel

Andrej Karpathy, the former Tesla AI director, posted about CLIs last week, and the post drew nearly 2 million views. He argued that CLIs are exciting precisely because they're "legacy" technology. Their conventions (stdin/stdout, flags, JSON output, pipes) were designed decades before AI agents existed, and agents turn out to use them well.

His larger point was a question for every product builder: "If you have any kind of product or service, think: can agents access and use them?" If the answer is no, agents cannot use your product, and it may be missing from a fast-growing distribution channel for software. That question is the core of AI agent readiness .

Karpathy's Thesis: Legacy Is an Advantage

In his demo, Karpathy asked Claude to install the Polymarket CLI (a Rust-built command-line tool for querying prediction markets) and then to build "any arbitrary dashboards or interfaces or logic." Three minutes later, Claude had a working terminal dashboard showing the highest-volume Polymarket contracts and their 24-hour price changes.

The setup needed no API integration code, no auth flow and no SDK. The CLI outputs structured data, and the agent works with that output directly.

He then repeated the exercise with the GitHub CLI. Claude browsed repositories, inspected issues, reviewed pull requests and read code. The agent combined existing command-line tools into workflows that would have taken a developer hours to wire up by hand.

CLI tools follow conventions that have not changed in decades. They take flags, write text or JSON to stdout, and compose through pipes. Their --help flag describes their own capabilities. That gives an agent discoverability, structured I/O and composability, with no UI screenshot or DOM parsing.

Agents Are Becoming a Distribution Channel

Beyond CLIs, agents are becoming an important distribution channel for software. Some use structured interfaces such as CLIs, MCP servers, and machine-readable documentation. Browser agents can also navigate rendered marketing sites and onboarding flows, so products should support both programmatic and browser-based access.

MCP grew quickly. It went from zero to 97 million monthly SDK downloads in twelve months, and over 10,000 active servers are running. OpenAI, Google DeepMind, Microsoft and Cloudflare have adopted it, and Anthropic donated MCP to the Linux Foundation in December 2025. Running an MCP server is starting to feel like running a web server.

85% of enterprises are expected to have AI agents deployed. Structured, programmatic access is valuable for reliable automation, while browser agents may combine the DOM, accessibility tree, and screenshots when using a GUI. A CLI, MCP endpoint, or machine-readable documentation gives agents a more deterministic path next to that browser interface.

Why CLIs Suit AI Agents

Karpathy put "legacy" in quotes because he does not mean CLIs are outdated. The traits that make them old (stable conventions, text-based I/O, predictable behavior) are the traits that make them work well for agents.

Justin Poehnelt, who builds Google Workspace tooling, recently wrote a guide on designing CLIs with agents as the primary user. He puts it this way: "Human DX optimizes for discoverability and forgiveness. Agent DX optimizes for predictability and defense-in-depth." Those are different design targets.

His practical recommendations include accepting raw JSON payloads as first-class input (not just convenience flags), exposing runtime-queryable schemas so agents can introspect capabilities without loading docs, adding field masks to keep responses small and save token budget, and including --dry-run flags so agents can validate before executing. If you are building a CLI today, his post is worth reading in full.

The Four Agent-Accessible Surface Areas

Karpathy's post ends with a checklist. I expand it into four surface areas where products can publish machine-readable paths for compatible agents:

1. Command-Line Interface (CLI)

If your product has an API, it should have a CLI. The Polymarket CLI that Karpathy demoed is built in Rust, and agents can use it to query markets, place trades and pull data from the terminal without an SDK.

Four design principles apply. Output JSON by default when stdout isn't a TTY, expose an --output json flag, support raw payload input alongside convenience flags, and make the CLI self-describing via schema introspection commands.

2. MCP Server

I've written about MCP before. In short, it defines a structured way to connect AI systems to external tools. Several major clients support MCP. Publishing a server creates a compatible tool interface, while client support, configuration, and authorization still determine whether it is used.

Discovery matters too. A /.well-known/mcp.json file publishes endpoint metadata at a known location. Our scanner records whether that discovery document is present and valid as an Agent Protocols signal. It does not prove that a client discovered or used the endpoint.

3. Machine-Readable Documentation

Tutorial videos and interactive getting-started guides are less deterministic for automated retrieval. Add documentation agents can parse directly, such as Markdown, llms.txt, OpenAPI specs, and structured knowledge bases.

llms.txt (our checkpoint 1.4) is a single file at your domain root that tells AI models what your site does and how to navigate it. It works like robots.txt for comprehension instead of crawling, although clients decide whether to read it. We also check for OpenAPI specs and agents.json as published machine-readable interface signals.

4. Agent Protocol Endpoints

Several other protocols cover different jobs. WebMCP handles browser-based agent interactions, Google's A2A lets agents delegate tasks to each other, and agents.json advertises what your AI agents can do. Each publishes or exposes structured interface metadata, and client support and use vary.

The stable-core contribution from our scanner's Agent Protocols category measures OpenAPI documentation and actionability, live OpenAPI and MCP verification, and structured API error responses. An A2A Agent Card is emerging bonus evidence and does not affect the headline score. WebMCP is experimental, non-scored evidence. That includes form quality and interactive surface evidence. These checks record published signals, not whether an agent will use the product.

Competitive Dynamics: What the Evidence Supports

Publishing an MCP server gives compatible clients a structured integration path. That path can be tested, documented, and maintained, but its presence does not show how many clients will discover it or whether they will use it successfully.

Twenty years ago, companies that invested in SEO early captured organic traffic that compounded for years. That history explains why teams may invest in machine-readable interfaces before demand is clear, but it does not establish an adoption curve for agent interfaces.

Goldman projects $780 billion in application software by 2030, with agents capturing 60%+ of those economics. That projection motivates experimentation with machine interfaces, but it does not establish which products agents will use.

What to Do Right Now

Here are five steps, in order of impact:

1. Ship a CLI with JSON output. If your product has an API, wrap it in a CLI that accepts JSON input and outputs structured JSON. This is usually the lowest-friction path to agent accessibility. Use --output json or auto-detect when stdout isn't a TTY.
2. Deploy an MCP server. Use the official TypeScript or Python SDK. Expose your core actions as MCP tools. Add /.well-known/mcp.json for discovery.
3. Export docs in markdown. Create an llms.txt file at your domain root. Publish an OpenAPI spec. Make sure your documentation is available in plain text or markdown, not just rendered HTML.
4. Add agents.json. Advertise your AI agent capabilities with a machine-readable agents.json file. It tells other agents what your product can do.
5. Measure your agent readiness. Scan your site to see your results across all 77 checkpoints, from crawler access and structured data to agent protocols and security headers.

We Built a CLI Too: @isagentready/cli

Alongside our MCP server and Claude Code skill , I've shipped @isagentready/cli , a command-line tool that scans a website for AI agent readiness from your terminal. It follows the CLI patterns described above.

Install it globally or run it directly with npx:

# Install globally
npm install -g @isagentready/cli

# Or run directly
npx @isagentready/cli scan example.com

A single command gives you scores, letter grades, and a category breakdown across all 77 checkpoints:

A+  example.com  98/100
  Scanned in 1.7s

  Categories

  ███████████████ 100%  AI Content Discovery (30% weight)
  █████████████░░  89%  AI Search Signals (20% weight)
  ███████████████ 100%  Content & Semantics (20% weight)
  ███████████████ 100%  Agent Protocols (15% weight)
  ███████████████ 100%  Security & Trust (15% weight)

Add --verbose to see every individual checkpoint, or --json for machine-readable output. For agents, the CLI also detects when stdout is piped and switches to JSON automatically:

# Piped → auto-JSON, no flag needed
isagentready results example.com | jq '.overall_score'

# Field masks to save token budget
isagentready results example.com --fields domain,overall_score,letter_grade

# Browse the rankings leaderboard
isagentready rankings --grade high --json

# Stream all rankings as NDJSON
isagentready rankings --page-all --fields domain,overall_score | wc -l

# Validate without hitting the API
isagentready scan example.com --dry-run

# Runtime schema introspection for agents
isagentready schema scan

The CLI implements several patterns from Justin Poehnelt's guide: auto-detection of non-TTY mode, an explicit --output json|text override, field masks for context window constraints, --dry-run for validation, NDJSON streaming, and a schema command for runtime introspection. It also ships with a CONTEXT.md file, structured guidance that AI agents can read to understand conventions and invariants.

Any AI agent (Claude Code, Cursor, a custom pipeline) can install the CLI and start scanning websites, pulling scores and querying rankings without reading a docs page. The same data is available through three paths: the web scanner , the CLI , and the MCP server . Humans use the GUI, and agents can choose the CLI or the MCP server.

How Our Scanner Measures Agent Accessibility

Parts of Karpathy's checklist overlap with published signals that the scanner measures. This table describes that limited alignment:

What Exists Today

These interface formats exist today, and their published signals can be measured. Actual discovery, interaction, and task success require runtime evidence outside the static score.

The web was built for human browsers, and automated clients now use several kinds of interface. Products can expose CLIs, MCP servers, and structured docs alongside a GUI without treating any single interface as proof of adoption.

Karpathy closed with three words: "Build. For. Agents." It works as a design guideline, not a measured prediction about product use.

Sources

• Andrej Karpathy on CLIs as agent-native interfaces, X - Original post on CLIs as "legacy" technology for AI agents (Feb 2026)
• You Need to Rewrite Your CLI for AI Agents, Justin Poehnelt - Detailed guide on agent-first CLI design patterns
• web2cli: Every Website Is a Unix Command, GitHub - CLI tool turning websites into parseable commands for agents and humans
• Introducing Polymarket CLI, Suhail Kakar on X - The Rust-built CLI that sparked Karpathy's post
• @isagentready/cli, GitHub - Open-source CLI for scanning AI agent readiness from the terminal
• IsAgentReady: What Is MCP? The Model Context Protocol for AI Agents
• IsAgentReady: What Is WebMCP and Why Your Website Needs It
• IsAgentReady: What Is Google's A2A Protocol? Agent-to-Agent Communication
• IsAgentReady: What Is agents.json? Advertising AI Agent Capabilities
• IsAgentReady: The State of AEO: Key Insights from Vercel's 2026 Report