Skills Are a Trap

Skills feel like a roadmap, but a catalog is not a capability

Betting your product architecture on discrete packaged skills wins the current quarter and loses the architecture. Every vendor is shipping skills right now, and it feels like progress because it looks like a roadmap. A skill is a discrete, named capability, “draft the contract,” “reconcile the invoice,” “triage the ticket,” packaged so a buyer can point at it, price it, and check a box. The appeal is obvious. Skills convert a fuzzy model into a catalog. They give sales a line item, give the roadmap a unit, and give the customer something concrete to say yes to. Every’s “The Case Against Skills” named this pattern early, and it is only accelerating.

The thing that made large models valuable in the first place was never a list. It was generalization. Packaging that generalization back into discrete, scoped skills is a local-maximum trap.

I have watched teams reach for the skills model because it makes the next release legible. That is exactly why it is dangerous. The most legible path and the most durable path are rarely the same, and product leaders who confuse the two end up with a product that demos well and compounds slowly.

Discrete skills cap the ceiling instead of raising it

Here is the mechanism. When you build a skill, you scope it. You define its inputs, its outputs, its guardrails, its failure modes. That scoping is the whole value proposition to the buyer and the whole ceiling on the system. A skill can only ever be as good as its scope, and the scope is fixed at design time by a human who guessed at the shape of the work.

Real work does not hold still inside a scope. The invoice has a line the reconciliation skill never anticipated. The ticket spans two skills that were built by two teams and don’t talk. The contract clause needs judgment about a counterparty relationship that no skill was ever given context for. Every one of those cases falls through the gaps between skills, and the gaps are where the actual work lives.

So you build more skills. You build a skill to route between skills. You build a skill to handle the exceptions the first skill couldn’t. The catalog grows, the integration surface grows faster, and the marginal skill delivers less than the one before it. This is the same trap the API-first era hit when every capability became an endpoint and the real complexity moved into orchestrating the endpoints. You end up maintaining a combinatorial mess whose ceiling is the sum of its scoped parts, when the model underneath was capable of more than any scope allowed.

The system doesn’t get smarter as you add skills. It gets more brittle. That is the opposite of what compounding infrastructure is supposed to do.

Judgment is the unit that actually compounds

Treat judgment as the unit of value instead of capability. Judgment is what a good operator applies when the situation doesn’t match the playbook, which is most of the time. It reads context, weighs tradeoffs, decides what matters, and knows when to escalate. It is generalized by definition, and it improves with exposure rather than degrading at the edges of a scope.

Building for judgment looks different from building for skills. You give the system broad context and a clear objective instead of a narrow input contract and a fixed output. You invest in the substrate, the data, the memory, the feedback loop, that lets the system reason across situations it was never explicitly scoped for. You measure it on outcomes, not on task completion. A skills system passes when it does the named task. A judgment system passes when the customer’s problem is solved, whether or not the path matched any script.

This is the self-learning architecture I keep arguing for, applied one level up. A skill is a snapshot of someone’s understanding on the day it shipped. A system built for judgment gets better every time it sees a case it hasn’t seen, because the substrate accumulates rather than the catalog. A skill is a fixed asset that depreciates. A judgment system compounds.

Meet the work where it is, and stay with it wherever it goes. Skills were scoped for where the work was, and they can’t follow it.

The objections from the skills camp don’t hold

The strongest case for skills is reliability. A scoped capability is predictable, testable, and safe to sell to an enterprise that needs to know exactly what it bought. A judgment system, the argument goes, is a black box you can’t put in a contract.

This is a real concern and it does not defeat the thesis. Reliability is an engineering property, not an architecture. You get reliability from evaluation, observability, and constrained action surfaces. You can bound what a judgment system is allowed to do without scoping what it is allowed to reason about. The skills camp conflates “predictable behavior” with “narrow scope,” and those are separable. You can have a system that reasons broadly and acts within tight, auditable limits. That is harder to build than a catalog. It is also the actual product.

The scoping objection, that customers want to buy named things, is a sales artifact rather than a product truth. Customers bought “search” and “recommendations” as named features for years; underneath, the durable ones were general ranking systems, not a catalog of hand-built rules. You can sell judgment as named outcomes while building it as general capability. The package the buyer sees and the architecture underneath do not have to be the same shape, and the teams that win will make sure they aren’t.

Enterprise sales is the last objection, and it’s the weakest. Enterprise buyers are not loyal to skills. They are loyal to outcomes and to the vendor who keeps delivering them as the buyer’s needs change. A skills catalog is a promise you’ll deliver exactly what you scoped. A judgment system is a promise you’ll deliver even when the need moves. Over a multi-year contract, the second promise is worth more, and procurement knows it.

Build the substrate, sell the outcomes

For product leaders, the move is not to abandon shipping fast. Ship fast, cut scope, deliver the thing customers can say yes to today. The discipline is in what you cut scope on. Cut scope on the surface, the specific outcomes you commit to this quarter. Do not cut scope on the substrate.

Concretely: invest in context, memory, and the feedback loop before you invest in the twentieth skill. Build evaluation and constrained action surfaces so reliability comes from bounding behavior, not narrowing reasoning. Package what you sell as outcomes the buyer recognizes, and keep the architecture underneath general. When a competitor ships a shiny new skill, do not chase it with a skill of your own. Ask whether your judgment layer already covers that case and just needs surfacing.

The teams building skills are building a catalog. The teams building judgment are building a system that renders the catalog obsolete one case at a time. Both will demo well next quarter. Only one of them still matters in three years.