Lexicon

Tools

n.—cached intelligence for agents.

A working definition, the one I keep converging on across different conversations: a tool is an external capability an agent can invoke—an API, an MCP server, a database, an enterprise system, a search engine, a file system, increasingly a local or remote CLI. The vocabulary is still settling across the ecosystem—Anthropic, OpenAI, Microsoft, and the various skill registries don't yet use identical terms—but the shape of the consensus is clear enough: a tool provides capability. It's something an agent uses.

One trend worth naming on its own: the rise of the CLI as a first-class tool. For years, command-line interfaces were considered the human-unfriendly layer that GUIs existed to hide. Agents have inverted that. A well-designed CLI—scriptable, composable, predictable in its outputs—turns out to be exactly the interface an agent wants, for the same reasons it was always the interface a power user wanted. The accessibility argument that justified forty years of GUI-first design quietly stops applying once the user is software.

The framing I keep coming back to—borrowed from a recent Hugging Face post that's stuck with me—is that a good tool is cached intelligence. It doesn't just expose a function; it encodes a workflow, an abstraction, a set of already-handled failure modes, built once by someone who understood the domain. When an agent invokes that tool, it inherits all of that accumulated judgment without spending a single token rediscovering it.

That's also why the quality of a tool layer matters more than the size of the model sitting behind it. A frontier model wired to thin, poorly designed tools will still struggle on real-world tasks. A smaller model wired to well-designed tools will often outperform it. Tools are where domain knowledge gets to live outside the model—which is exactly why they're a harness concern, not a model concern.