III · Tool Use & EnvironmentEmerging★

Agent-Computer Interface

also known as ACI, Agent-Friendly Tooling, SWE-Agent ACI

Design the tool surface for an LLM agent specifically, with affordances different from human-facing CLIs.

This pattern helps complete certain larger patterns —

  • specialisesTool Use★★— Let the LLM produce typed calls against an external toolkit instead of producing free-form text the surrounding system has to parse.

Context

A team is building a coding agent, a research agent, or another domain agent that drives a file system, a shell, a web page, or an API that was originally designed for a human sitting at a keyboard. The agent is expected to read, edit, and act over those surfaces inside a fixed context budget, often for hundreds of turns per task.

Problem

Human-facing tools are wrong-shaped for the agent: a normal text editor returns a whole 4000-line buffer when the agent only needs ten lines, a generic shell prints unbounded stdout that overflows context, and a web page returns minified JavaScript instead of structured state. The agent burns turns scrolling, paginating, and re-reading content it cannot fit, and signal-poor outputs (no exit codes, no linter feedback) hide the information the model actually needs to decide its next step.

Forces

  • Agent-friendly tools require parallel implementations alongside human ones.
  • Tool surface must balance agent ergonomics with capability completeness.
  • Linter / type signal exposure helps but adds output volume.

Example

An engineering team wires their agent to the standard bash and a desktop-grade text editor. Every diff balloons into a 4000-line buffer, output gets truncated mid-stack-trace, and the agent burns turns scrolling. They replace the surface with an Agent-Computer Interface: a file_view tool that returns numbered windows with elision markers, an edit tool that takes line ranges, and a run tool that streams the last 200 lines plus exit code. Task success rates rise sharply on the same model.

Diagram

Solution

Therefore:

Design tools specifically for agents: file viewer that shows a windowed slice with line numbers, edit tool that re-runs linter and shows results, shell that returns structured stdout/stderr/exit-code, search tool that filters and ranks. Each tool's signature + return type optimised for the agent's context budget and reasoning shape.

What this pattern forbids. Agent tools follow a deliberate ACI design contract; raw human-CLI tools are not exposed as primary tools.

The smaller patterns that complete this one —

  • generalisesSynthetic Filesystem Overlay·— Project heterogeneous enterprise data sources into a single Unix-like tree exposed through filesystem primitives so the agent reuses path semantics it already knows instead of learning a bespoke API per source.

And the patterns that stand alongside it, or against it —

  • complementsTool Loadout★★— Select a small task-relevant subset of available tools per request rather than exposing the full registry to the model.
  • complementsJSON-Only Action Schema✕— Anti-pattern: restrict the agent's action language to JSON tool-call dictionaries even for tasks where code-as-action (functions composing, loops, conditionals over results) would be the natural shape.
  • complementsAgent Privilege Escalation✕— Anti-pattern: let an agent's effective permissions be the union of its own identity, the identities of its tools, and the identities of the services those tools call.
  • complementsAgent Adapter★★— An interface layer connecting an agent's tool-calling protocol to heterogeneous external tools, normalizing their schemas into one the agent expects.
  • complementsLarge Action Models (LAMs)·— Use a model class specifically trained for action execution (tool calls, UI navigation, workflow steps) rather than text generation, when the workload is dominated by reliably completing actions in real systems.
  • complementsHierarchical Tool Selection★— Organise tools into a tree of categories so the agent first picks a branch and then a specific tool within it.
  • complementsTool Transition Fusion·— Mine tool-call telemetry for high-probability X-then-Y transitions and fuse those pairs into a single composite tool, shrinking the planner's step count.
  • complementsMachine-Checkable Tool Contract★— Express every constraint a tool places on its caller in the machine-readable schema rather than the prose description, and return failures as typed fields the caller can branch on.

Neighbourhood

Click any neighbour to follow the language. Scroll to zoom, drag to pan.

Used in recipes

Used in frameworks

Show 9 more

References

Provenance