Agents need an operating contract.
Developers need the approval line.

For the agent

Resolve intent without
risking a stuck shell.

Measured, not asserted

Less for the agent to read —
and the gap grows with the repo.

We measured this rather than claiming it. On a synthetic monorepo with a linear dependency chain (pkg-1 ← pkg-2 ← pkg-3 …), we compared the tokens an agent has to read to reach a confident, dependency-correct release plan: manually discovering every package.json and running npm publish --dry-run on each package, versus one xops ask "release the stack" --plan --json call. No package was actually published or pushed in either path.

The manual path grows roughly linearly with package count — each additional package means another file to read and another dry-run call. The xops number stays flat because ask --plan returns a routing decision (which command to run and why), not a per-package enumeration — confirmed by checking that the raw output was byte-identical at every package count tested.

Method: tiktoken cl100k_base token counts of raw command output fed back into context (not model reasoning tokens), measured at 3, 6, and 10 packages on a synthetic fixture with minimal near-empty package files. Real monorepos have larger files and longer dry-run output, so this ratio is likely a lower bound, not an upper one — but we're not claiming a number we haven't tested at production scale.

For the developer overseeing the agent

Know what an agent can do
before you hand it the release.

You're not the one typing --plan --json. You're the one deciding whether to let an agent run a release unattended at all. xops draws an explicit line between what an agent can do on its own and what needs your approval — so that line is something you can audit, not something you have to take on faith.

The dividing line is irreversibility, not difficulty: anything that only inspects or plans is on the left. Anything that publishes to npm, pushes to git, or rewrites dependency specs needs --yes set explicitly by whoever configured the agent — it cannot cross that line by accident in a non-interactive run.

What you get back after an agent run

• ✓
  A journal, not a log to scroll throughLocal file changes are tracked per run. xops undo --last reverses them without you reading agent chat transcripts to figure out what changed. See Undo.
• ✓
  A distinct signal for "it half-worked"Exit code 2 means publish succeeded but push failed — a different outcome from total failure (1) or a refused approval (4), so you don't have to parse prose to know which.
• ✓
  External effects are reported, not hiddennpm publish and git push are irreversible by design. xops logs them with full detail instead of pretending they can be undone.

Why this is redefined, not wrapped

Same model. A caller
that can't ask a follow-up question.

xops doesn't add a new mental model on top of npm install, npm publish, and git push. It makes that existing model legible to a caller that can't ask a clarifying question when something is ambiguous. A human stuck at a confusing prompt can read the screen, think, and answer. An agent stuck at the same prompt in a non-interactive shell just hangs — the orchestrating process eventually kills it, and the release is left half-done with no record of why.

That's the actual redefinition: not new commands, but the same release contract — discover the graph, plan, execute in order, journal, report — expressed in a form a deterministic process can consume. Why → for code agents covers the underlying product values; this page is the contract itself.

Beyond shell access

Agents do not need more commands.
They need operating context.

A code agent can already run npm test. That is not enough. It needs to know whether npm is the right package manager, which packages changed, which tests exist, which tools own quality checks, whether dependency monitoring is active, whether API tests can run, whether MaGit is present, whether utilitix is relevant, whether a command mutates files, whether an external effect is irreversible, and whether approval is required.

• ✓
  No hidden promptsAn agent cannot get stuck waiting on a question that will never be answered.
• ✓
  No guessed commandsxops resolves the repo-specific command instead of the agent inventing one.
• ✓
  No surprise setupSeamless user-space tools may be bootstrapped only when safe; setup that writes repo config or touches external services stays approval-bound.
• ✓
  No irreversible effects without explicit approvalPublish, push, deploy, and external SaaS effects always require --yes.

Beyond shell, beyond ask

MCP-aware agents skip the shell.
They call typed tools instead.

xops ask --plan --json is for agents that still run a CLI. For agents and IDE runtimes that speak MCP natively, xops ships a first-party MCP server in the same package — no separate install, no sidecar process to manage.

MCP tools are typed and policy-aware — they call SDK functions and xops planners, the same core ask uses, not arbitrary shell execution. Mutations, publish/release, tool installation, and exposure scans return structured approval-required or authorization-required results unless the caller supplies explicit approval and an MCP profile that allows the action — the same approval line covered in Safety, just expressed as a structured result instead of an exit code.

Humans use the CLI. Scripts and platforms use the typed @x12i/xops SDK. Agents use MCP. All three call the same xops core, so a plan an agent gets over MCP matches what a human would see running xops ask by hand.

Agent economics

The most expensive agent work
is guessing.

A code agent can spend a surprising amount of time just learning how a repo works: which package manager to use, which script is correct, which packages changed, which tests matter, which tools are configured, and whether an operation is safe.

xops turns that discovery into a command. Instead of reading half the repo, the agent can call xops ops status. Instead of guessing tests, it can call xops affected test. Instead of parsing noisy logs, it can read normalized findings. Instead of hanging on approval prompts, it gets a deterministic approval-required exit code.

"Cheaper" here means fewer tokens, fewer retries, fewer wasted tool calls, and less expensive model reasoning — less discovery, less log interpretation, fewer retry loops, narrower scope, and exact next commands instead of re-planning from scratch after every step. We are not claiming a fixed percentage; the mechanism is structural, not a marketing number.