Axi

Agent eXperience Interface (AXI)

AXI defines ergonomic standards for building CLI tools that autonomous agents interact with through shell execution.

Before you start

Read the TOON specification before building any AXI output.

1. Token-efficient output

Use TOON (Token-Oriented Object Notation) as the output format on stdout. TOON provides ~40% token savings over equivalent JSON while remaining readable by agents. Convert to TOON at the output boundary — keep internal logic on JSON.

tasks[2]{id,title,status,assignee}:
  "1",Fix auth bug,open,alice
  "2",Add pagination,closed,bob

2. Minimal default schemas

Every field in stdout costs tokens — multiplied by row count in collections. Default to the smallest schema that lets the agent decide what to do next: typically an identifier, a title, and a status.

• Default list schemas: 3-4 fields, not 10
• Default limits: high enough to cover common cases in one call (if most repos have <100 labels, default to 100, not 30)
• Long-form content (bodies, descriptions) belongs in detail views, not lists
• Offer a --fields flag to let agents request additional fields explicitly

3. Content truncation

Detail views often contain large text fields. Omitting them forces agents to hunt; including them wastes tokens. Truncate by default and tell the agent how to get the full version.

task:
  number: 42
  title: Fix auth bug
  state: open
  body: First 500 chars of the issue body...
    ... (truncated, 8432 chars total)
help[1]: Run `tasks view 42 --full` to see complete body

• Never omit large fields entirely — include a truncated preview
• Show the total size so the agent knows how much it's missing
• Suggest the escape hatch (--full) only when content is actually truncated
• Choose a truncation limit that covers most use cases (500-1500 chars)

4. Pre-computed aggregates

The most expensive token cost is often not a longer response — it's a follow-up call. If your backend has data that agents commonly need as a next step, compute it and include it.

Aggregate counts: include the total count in list output, not just the page size. Agents need "how many are there?" and will paginate if the answer isn't definitive.

count: 30 of 847 total
tasks[30]{number,title,state}:
  1,Fix auth bug,open
  ...

Derived status fields: when the next step almost always involves checking related state, include a lightweight summary inline.

task:
  number: 42
  title: Deploy pipeline fix
  state: open
  checks: 3/3 passed
  comments: 7

Only include derived fields your backend can provide cheaply — a summary ("3/3 passed"), not the full data.

5. Definitive empty states

When the answer is "nothing", say so explicitly. Ambiguous empty output causes agents to re-run with different flags to verify.

$ tasks list --state closed
tasks: 0 closed tasks found in this repository

State the zero with context. Make it clear the command succeeded — the absence of results is the answer.

6. Structured errors & exit codes

Idempotent mutations

Don't error when the desired state already exists. If the agent closes something already closed, acknowledge and move on with exit code 0. Reserve non-zero exit codes for situations where the agent's intent genuinely cannot be satisfied.

$ tasks close 42
task: #42 already closed (no-op)    # exit 0

Structured errors on stdout

Errors go to stdout in the same structured format as normal output, so the agent can read and act on them. Include what went wrong and an actionable suggestion. Never let raw dependency output (API errors, stack traces) leak through.

error: --title is required
help: tasks create --title "..." [--body "..."]

• Validate required flags before calling any dependency
• Translate errors — extract actionable meaning, discard noise
• Never leak dependency names — suggestions reference your CLI's commands, not the underlying tool

No interactive prompts

Every operation must be completable with flags alone. If a required value is missing, fail immediately with a clear error — don't prompt for it. Suppress prompts from wrapped tools.

Fail loud on unrecognized input

Reject unknown flags and arguments — never silently ignore them. A dropped flag is worse than an error: the agent gets plausible-looking output it believes is scoped or filtered, then proceeds confidently on wrong data. This is the same guarantee a CLI already owes for an unknown _command_; extend it to flags.

$ tasks list --stat closed
error: unknown flag --stat for `list`
help: valid flags for `list`: --state, --assignee, --limit (--help always allowed)

• Validate before any dependency call, with exit code 2 — the same as a missing required flag. Each command declares its own known flags; an unrecognized one is rejected by name and the command's valid flags are listed.
• `--help` always passes — it's the one universal flag. Beyond it, a CLI may standardize its own always-allowed globals (e.g. an --account selector); whatever the set, those flags pass on every command and are never reported as unknown.
• Renamed or removed flags get a targeted hint, not the generic list — point at what replaced them (--status was renamed; use --state instead) so the agent self-corrects in one step.
• Per-subcommand flag sets. For grouped nouns where one command dispatches to subcommands (a list vs a create under the same noun), validate against the _subcommand's_ flags — they differ, and only the subcommand layer knows which is in play.
• Make the error self-correcting in one turn. The agent's deterministic next move after an unknown-flag error is to run <command> --help (e.g. tasks list --help) — so fold that lookup into the error: list the valid flags inline, or print the command's concise --help block directly beneath it. Per §4 the expensive cost is the follow-up call, and per §10 per-command help is already concise, so inlining it collapses the two-turn correction into one.

Output channels

• stdout: all structured output the agent consumes — data, errors, suggestions
• stderr: debug logging, progress indicators, diagnostics (agents don't read this)
• Exit codes: 0 = success (including no-ops), 1 = error, 2 = usage error

Never mix progress messages into stdout. An agent that reads "Fetching data..." will try to interpret it as data.

7. Ambient context via session integrations

Register your tool into the agent's session lifecycle so every conversation starts with relevant state already visible — before the agent takes any action.

Pattern:

1. Provide an explicit setup command that installs or repairs a session hook or plugin after user intent is clear
2. At session start, the integration runs your tool and provides a compact dashboard as context
3. The agent receives this as initial context and can act immediately

# Agent sees this at session start — no invocation needed:
specs[2]{id,title,status}:
  1,Fix auth bug,open
  2,Add pagination,in-progress

help[2]:
  Run `mytool specs view 1` for details
  Run `mytool specs create --title "..."` to add a spec

Rules:

• Default app targets: by default, support Claude Code, Codex, and OpenCode. Do not hard-code a single agent integration when the tool can reasonably support multiple agents
• Explicit opt-in: register hooks or plugins only from a user-invoked setup command, not from ordinary CLI commands
• Portable commands: hook commands should use a PATH-verified binary name when it resolves to the current executable, and fall back to the full absolute path otherwise. This keeps global installs portable while ensuring hooks do not accidentally run a different binary