Skill versus capability

Enterprise architects love the word "capability." "We need meal-planning capability." "Invoice capability is a priority." Strategy conversations need that vocabulary. Roadmaps need it. Vendor RFPs need it. Capability alone, however, does not tell anyone whether the work lives in tribal knowledge, a pipeline script, a Skill package, or an agent habit that rediscovers the same path every week.

Helpful context: This page assumes familiarity with what is a skill, what is a cognitive unit, and libraries of cognition. Those primers define the targets capability talk must map onto.

Two different questions

Strategy asks what the organisation must be able to do. Architecture asks how known work is packaged so teams can reuse, substitute, and evaluate it. "We can verify invoices" is a capability claim. Verify Invoice as a sealed package with inputs, outputs, cognitive units inside it, side-effect grants, and a procedure suite is a Skill. The capability may exist long before the Skill exists. Packaging is maturity work, not a rename.

Question	Object
What can we do?	Capability
How is that known work packaged?	Skill

A capability can live as tribal knowledge, a runbook, a pipeline script, or an agent habit. Only some states deserve Skill packaging. Packaging makes the capability searchable, substitutable, and evaluable as a procedure rather than as folklore. This matters because capability language without packaging leaves reuse informal and evaluation impossible at procedure level. An organisation may claim invoice verification capability while three different teams run three different scripts with no shared contract, no common evaluation, and no way to substitute one implementation for another when a model upgrade changes output formatting.

Decompose meal-planning capability

Take the informal claim: "meal-planning capability." Decompose before anyone selects a model. "Interpret the household request" maps to cognitive unit InterpretWeek plus agent strategy. "Compose a provisional week" maps to Skill Compose Weekly Plan. "Judge weekday practicality" maps to cognitive unit JudgeWeekdayPracticality in a judge library. "Pursue accepted plan" maps to the Meal Planning Agent goal.

Informal claim	Thoughtware mapping
Interpret the household request	cognitive unit InterpretWeek plus agent strategy
Compose a provisional week	Skill Compose Weekly Plan
Judge weekday practicality	cognitive unit JudgeWeekdayPracticality in judge library
Pursue accepted plan	Meal Planning Agent goal

"Meal-planning capability" decomposes into named Skills, library cognitive units, deterministic shell work, and an agent goal. The decomposition changes staffing and evaluation. Procedure owners maintain Skills. Domain experts maintain judge libraries. Agent owners maintain pursuit policy and stop conditions. Without mapping, teams buy "capability platforms" that excel at demos and are weak at ownership. Incidents become debates about model quality when the real gap is unnamed procedure seams.

What capability talk hides

Capability slides often smuggle four different objects into one bullet: open judgments that belong in cognitive units, known procedures that belong in Skills, exact enforcement that belongs in code, and pursuit that belongs in an agent when paths still vary. Model fluency is not a Skill. Tool access is not a Skill. A pipeline may implement a capability without yet being a Skill. Acting on the world does not settle the question. See acting is not agency.

A cognitive unit decides. A Skill performs. An agent pursues.

The cognitive unit Ch. 16

That quote serves as a sorting test. Capability language should eventually land on one of those verbs. When someone says "capability," four follow-up questions resolve the mapping. Is the procedure known enough to Skill-package today? Which judgments remain cognitive units with contracts? Which exact checks belong in deterministic code? Who pursues the outcome if the path still varies case by case? If the procedure is known and nobody pursues, the architecture needs a Skill, not an agent. If pursuit is needed, the architecture needs an agent that calls Skills for settled work. See where the cognitive unit ends and the agent begins.

Libraries scale capabilities

Capabilities become durable when they live in libraries of cognition. A domain library holds reusable cognitive units like GenerateCandidates. A Skill library holds sealed procedures like Compose Weekly Plan. Organisational libraries hold cross-domain packages like AskTargetedQuestion. Capability roadmaps should name library placement and owners, not feature dates alone. "Ship meal planning" without library ownership is a demo date, not an architecture commitment.

The invoice verification parallel shows the same structure. "We can verify invoices" spans retrieval, field interpretation, variance calculation, materiality judgment, and posting under grant. Capability language treats that as one line item. Thoughtware decomposition assigns cognitive units to field judgments, a Skill to the verification procedure, code to exact arithmetic and permission checks, and an agent only if queue pursuit with escalation is in scope.

Maturity path

Capabilities often mature in a predictable order. They begin as tribal perform work inside agent exploration, where the agent rediscovers the same path because nobody has packaged it. They become a named trajectory when the path repeats consistently. They reach Skill package status when a contract and procedure evaluation arrive. They become library publications when other teams need the same capability. See when a trajectory becomes a Skill. Skipping steps leaves capabilities permanently informal. The maturity path is also observable in production traces: when the same sequence of cognitive unit calls appears across multiple agent runs with minor variations, the system is signalling that a Skill boundary wants to be drawn around that recurring procedure.

Common mistakes

The most common mistake is the capability slide backed by a pipeline repo: strategy says capability while code is a script with no contract. The second is an agent that absorbs capability language, where pursuit rediscovers composition because nobody packaged the Skill. The third is a cognitive unit that absorbs capability language, where one call tries to decide practicality, variety, fit, and repair quality together. The fourth is a vendor capability map treated as architecture, where partner diagrams replace responsibility design.

Roadmap language that survives build

Capability bullets survive build only when decomposed into rows before engineering starts. Each row names an owner type: agent goal, Skill package, cognitive unit in a library, or deterministic shell rule. Dates attach to packages, not to vibes. When leadership asks "do we have meal-planning capability?" answer with the decomposition table from this page. Capability exists at the organisation level. Skills and libraries exist at the engineering level. Conflating the two levels causes roadmap theatre.

Vendor RFPs often request "AI capabilities" without decomposition. Respond with packaged Skills and library cognitive units that can be evaluated, versioned, and substituted. Refuse single-model blobs that cannot name procedure seams or judgment contracts. Procurement teams benefit when architecture maps capability claims to evaluable packages. A vendor that cannot decompose meal planning into Skills and cognitive units is selling demos, not durable capability material. The decomposition test during procurement also protects against vendor lock-in: when each cognitive unit and skill has a named contract, substituting one vendor's implementation for another becomes a bounded integration task rather than a full system rewrite.

What to do next

Pick one capability from the roadmap and decompose it into agent goal, Skills, cognitive units, and code. Mark which parts are known enough to package this quarter. Assign library placement for reusable judgments and procedures. Run one session with product and domain experts: take three capability bullets from the roadmap, decompose live on a whiteboard, capture the table in the spec. The session costs an hour. It saves quarters of compound naming debt. Repeat until stakeholders start asking "which Skill owns that?" before asking "which model?"

See what is not a cognitive unit, decide, perform, pursue, and minimum sufficient loop.

Read next: Minimum sufficient loop.