What is an agent-native CLI?

A CLI designed so AI agents can call it reliably: machine-readable output (JSON, exit codes), no interactive prompts, non-destructive dry-run modes, self-describing help output, and idempotent operations.

Why do AI agents struggle with existing CLIs?

Most CLIs output human-readable text, use interactive prompts for confirmations, have inconsistent exit codes, and require --force to bypass safeguards. Agents can't navigate these reliably without prompt engineering.

Is there a standard for agent-native CLI design?

No established standard. A 2026 HN post 'Principles for agent-native CLIs' outlined 10 principles but it's not a spec. GitHub CLI and Mistral's Spaces CLI are examples that follow agent-friendly patterns.

How do agents call CLI tools today?

Through shell wrappers, MCP servers (expensive), or direct shell access. Agents write bash to call CLIs but brittle output parsing causes failures. The token-efficient approach is direct CLI calls with grep/jq post-processing.

What makes a CLI machine-readable?

JSON output mode (--json flag), structured exit codes, no color/interactive output when piped, --no-input flag to skip prompts, and deterministic behavior given the same inputs.

← Back to dashboard

clawsmith.com/signal/agent-native-cli-design-missing-structured-output

⚠ IssueWide Opendev_tool_cliLive

No standard for building CLIs that agents can reliably call without prompt engineering

AI agents call CLIs constantly but most CLIs were designed for humans, not agents. Natural language output, interactive prompts, --force flags, and inconsistent exit codes make CLI automation fragile. The HN post 'Principles for agent-native CLIs' (112 pts, 19 comments) crystallized the frustration. CLI-Anything (HKUDS) tries to auto-convert any CLI to agent-callable. The gap: no toolchain or standard that makes a CLI robust for programmatic agent use without rewriting it.