Agents
Capabilities
Individual abilities made reliable and given no interface of their own: “read an invoice,” “extract an appointment,” “check a text against policy.” Building blocks like these can be tested, versioned, and plugged into any workflow. The counter-design to the do-everything chatbot: small, composable, measurable. Software craft instead of magic.
An example
“The model can review contracts” is not a statement about capability but a sales claim. It becomes testable only like this: across 200 contracts from our archive, it finds 94 percent of the missing liability caps, misses six percent, and in four percent of cases flags one that doesn't exist. That is enough to decide whether using it is defensible. The sentence before is not.
A closer look
A capability does exactly one thing, has a fixed interface and its own quality measure, such as “read an invoice” or “classify a customer.” It is testable, versionable, and reusable, precisely because it has no interface of its own.
Why it matters
The useful translation of “can” is always: in what share of cases, under what conditions, with what kind of error. Capabilities are also uneven. Models can suddenly do a task that the previous generation could not do at all, and fail at something that looks easier. The consequence for planning: don't assess general capability, measure your own task, and repeat that measurement with every model change. Anything else transfers other people's results onto a different case.
Commonly misunderstood
The scoping decides. Cut too coarsely, and a capability becomes a second application; cut too finely, and you end up with a toolkit nobody can keep track of.