Pretrained Interfaces: Designing Tools for What LLMs Already Know

When building tools for coding agents, we often ask: what API should we expose?

Maybe the better question is: what interface does the model already know?

Modern LLMs have extremely strong priors for certain interfaces. They have seen millions of examples connecting intent, commands, output, errors, and subsequent actions.

Some obvious examples:

• Unix shell — pipes, stdin/stdout, exit codes, processes
• Git — status, diff, history, branches, commits
• rg / grep — textual search
• Filesystem — paths, files, directories
• SQL — relational querying
• HTTP/REST — resources, methods, status codes, JSON
• JSON / JSONL — structured machine-readable data
• Python — scripting and programmable APIs
• GDB / LLDB — breakpoints, stepping, stacks, registers
• Make / CMake / Ninja — builds and dependency graphs
• Docker — images, containers, logs, exec
• kubectl / Kubernetes — declarative resources and state
• Regex — compact matching and transformation
• Compiler diagnostics — file:line:column: error
• Unified diff / patch — representing changes

These interfaces effectively have part of their documentation compressed into the model weights.

That has an interesting consequence for agent-tool design:

Don’t teach the model a new interface if you can faithfully express the capability through one it already knows extremely well.

Model weights are a form of preloaded interface knowledge.

Good agent interfaces might therefore be the ones that maximize pretrained interface leverage: use familiar semantics where they genuinely fit, and spend context tokens only on what is actually new.