Anthropic Is Betting on Skills. They’re Wrong—and Here’s Why.

Anthropic’s engineers have delivered one of the catchiest ideas in AI development: “Don’t build agents. Build skills instead.”

It sounds clean. It sounds economical. And it diagnoses a real problem: most AI agents are brilliant generalists with no lived experience of the job they are being asked to perform. They can reason, call tools, and write code, but they do not automatically know a company’s procedures, compliance rules, exceptions, or definition of a completed task.

Anthropic’s answer is the Skill: a folder containing instructions, scripts, and resources that a general-purpose agent loads when needed. Instead of maintaining twenty custom agents, the theory goes, maintain one capable agent and give it twenty modular skills. [1]

That is a useful design pattern. It is not the future of the entire agent stack.

The mistake is not Anthropic’s belief that skills matter. The mistake is treating domain specialization primarily as information loaded around a general-purpose model. A skill changes the context. It does not change the brain processing that context.

For repetitive, bounded work, repeatedly renting universal intelligence is not simplicity. It is centralized overengineering.

First, let’s state Anthropic’s position accurately

The viral slogan overstates what Anthropic actually says. Anthropic has not abandoned agents. Its own definition distinguishes fixed workflows from agents that dynamically control their processes and tool use. In 2025, Anthropic documented a production multi-agent research system. In April 2026, it explained a hosted service explicitly called Managed Agents. In August 2026, its researchers wrote that increased real-world interaction among agents was imminent. [2] [3] [4]

The narrower argument is that developers should stop creating fragmented custom scaffolding for every use case. Anthropic’s Skills system packages procedural knowledge into portable folders and uses progressive disclosure: the model initially sees a skill’s metadata, then loads detailed instructions or scripts when relevant.

This is good engineering. A tax checklist, document template, brand guide, or tested Python script should not be buried inside a giant prompt or rewritten on every run.

But a skill remains external guidance supplied to the same general-purpose inference engine. The model must still interpret the instructions, select the correct procedure, resist irrelevant context, emit the right tool call, and repeat this behavior every time. When the workload is stable and repeated thousands or millions of times, asking a frontier generalist to rediscover the same behavior is wasteful.

The skill library becomes its own agent problem

Anthropic’s pitch feels simplest when the library is small: one capable model, a handful of clean folders, and automatic selection. But “just add another Skill” does not scale indefinitely. Each addition changes the environment in which every other Skill must be discovered, selected, trusted, and followed.

This is not a hypothetical objection from outside Anthropic. It is the problem described in Anthropic’s own documentation.

Every Skill charges a metadata tax

Progressive disclosure is smart, but it is not free. Anthropic says the name and description of every installed Skill are loaded at startup and placed in the system prompt—about 100 tokens per Skill in its own estimate. Its authoring guide calls the context window “a public good” shared with the system prompt, conversation, request, and the metadata of other Skills. Its Managed Agents documentation is even plainer: each added Skill incurs a context cost, and mounting more Skills increases sandbox startup time. [13] [14] [15]

The body of an unused Skill may stay on disk, but the catalog still occupies attention. At ten Skills that is a rounding error. At hundreds, it is a permanent tax before the user’s actual task has begun.

Discovery is routing with a friendlier name

A Skill does nothing until the general-purpose model selects it. Claude makes that choice by matching the user’s request against each Skill’s short description. Anthropic calls the description “critical for skill selection” and discusses choosing from “potentially 100+ available Skills.” That means the supposedly simple architecture already contains a semantic router—it is merely embedded in the model rather than exposed as an independently tested component. [14]

As the catalog grows, descriptions overlap. A broad spreadsheet Skill can steal a query from a finance-reporting Skill. A compliance Skill may fail to trigger because the user used an unfamiliar phrase. Two individually good Skills may activate together and issue incompatible instructions. The failure is silent: the model still produces a fluent answer, just under the wrong procedure.

Anthropic’s enterprise guide concedes the whole scaling problem. It warns that too many active Skills reduce recall accuracy, that Claude may choose the wrong one or miss a relevant one, and that API requests support a maximum of twenty Skills. Its proposed remedies are to consolidate Skills or route requests to different Skill sets. [16]

The moment you must route a request to the right subset of Skills, “one agent with Skills” has become a multi-component orchestration system again.

Pruning is not optional; it is the product roadmap

A growing Skill library needs owners, versions, dependencies, telemetry, evaluation dates, deprecation rules, permissions, conflict tests, and rollback plans. Anthropic recommends all of them. It tells enterprises to maintain an internal registry, test every Skill both alone and alongside the existing catalog, consolidate overlapping Skills, monitor drift, pin production versions, and deprecate persistent failures. It also notes that usage analytics are not currently available through the Skills API, leaving customers to build application-level logging themselves. [16]

That creates an unavoidable pruning loop:

1. Teams add narrow Skills because narrow instructions trigger more precisely.
2. The catalog grows, consuming context and creating overlapping triggers.
3. Recall and coexistence degrade, so teams shortlist, bundle, merge, or retire Skills.
4. Broader bundles become harder to test and more likely to contain conflicting procedures.
5. Teams split them again or add a smarter router.

This is not modularity defeating complexity. It is complexity moving from agent code into taxonomy maintenance. Anthropic did not eliminate orchestration; it made customers build a Skill control plane.

Composition multiplies the testing burden

A Skill can pass every isolated test and still degrade the system when another Skill is installed. Anthropic explicitly requires “coexistence” testing because a new description can steal triggers from existing Skills. The important unit of quality is therefore not the Skill; it is the Skill set, the model version, the available tools, the system prompt, and the user request together. Change any one of them and previously validated behavior can move.

This creates a combinatorial problem. No serious team will test every possible subset of a large catalog. It will test common bundles and hope the long tail behaves. The practical escape is to make those bundles smaller and role-specific—which is another name for creating bounded agents with constrained capabilities.

Static instructions create procedural debt

Skills are editable, which is an advantage when policy changes. But editability is not learning. A failed run does not improve the Skill unless someone captures the trace, labels the failure, changes instructions or code, reruns the evaluation suite, completes a security review, publishes a new version, and monitors the rollout.

As Skills accumulate, they freeze yesterday’s API conventions, exception lists, brand rules, and compliance interpretations. Anthropic’s own guide warns authors to avoid time-sensitive information. But operational knowledge is inherently time-sensitive. A model can follow stale instructions perfectly and still be wrong. [14]

The Skill ecosystem expands the trusted computing base

A Skill is not merely a prompt snippet. It can contain executable scripts, network calls, tool instructions, and references that run inside an agent’s permission envelope. Anthropic tells enterprises to treat installing a Skill with the same rigor as installing production software. Its risk table flags arbitrary code, instruction manipulation, external network access, hardcoded credentials, and data exfiltration. Repository Skills can also be changed by anyone able to commit to the mounted repository. [16] [15]

Early research suggests this is not theoretical. A 2026 preprint analyzing 31,132 marketplace Skills reported at least one detected vulnerability in 26.1 percent of them; Skills containing executable scripts were 2.12 times more likely to be flagged than instruction-only Skills. Another preprint’s 202-case benchmark reported attack-success rates as high as 80 percent against frontier-model agents exposed to malicious Skill-file instructions. These are emerging, study-specific results—not universal failure rates—but they show why every added Skill expands the audit surface. [17] [18]

The monoculture problem remains

Even a perfectly managed catalog still routes every procedure through the same general-purpose brain. The same model’s instruction-following quirks, blind spots, jailbreak susceptibility, and regression risks propagate across every department. Skills diversify context, not cognition.

A heterogeneous system creates actual fault boundaries. A quantized extraction model cannot casually decide to send an email if it has no email tool. A policy verifier can be trained and evaluated on policy violations rather than on general helpfulness. A transaction agent can be denied open internet access. The frontier model remains available for ambiguity, but it is no longer the universal interpreter and universal executor.

There is independent evidence for this shortlisting principle in tool use. A 2026 preprint evaluating registries of up to 3,251 tools found the familiar tradeoff: show too many options and the model struggles to choose; show too few and the correct option may be absent. An adaptive shortlist improved Claude Sonnet 4.6’s downstream selection accuracy in the reported experiments. Skills and tools are not identical, but the inference is straightforward: metadata-driven capability selection becomes a retrieval problem as the catalog grows. [19]

The missing layer: specialized intelligence

Three different things are too often collapsed into the word “specialization”:

1. A skill supplies procedures, references, scripts, and examples at runtime.
2. Fine-tuning or adapter training changes the model’s learned behavior for a task or domain.
3. Quantization compresses that trained model—commonly to 8-bit or 4-bit weights—so it needs less memory and can run faster or on smaller hardware.

Quantization by itself does not create expertise. A compressed generalist is still a generalist. The stronger counterproposal is task-trained specialist models, quantized for efficient inference, each operating inside a narrow agent loop.

NVIDIA Research and Georgia Tech’s position paper, Small Language Models are the Future of Agentic AI, argues that agent systems repeatedly invoke models for a small number of specialized tasks with limited variation. Its recommended design is heterogeneous: use small specialists by default and selectively escalate work requiring open-domain reasoning to a larger model. [6]

The evidence is not limited to a position paper. TinyAgent fine-tuned 1.1-billion- and 7-billion-parameter models for function calling and demonstrated that task-specific edge models could match or exceed much larger cloud models in that bounded capability. Octopus v2 reported that a 2-billion-parameter on-device model surpassed GPT-4 on its function-calling evaluation, cut required context length by 95%, and improved latency 35 times compared with a retrieval-based Llama-7B setup. Salesforce’s xLAM research likewise showed that action-specialized models could deliver competitive—and on selected function-calling benchmarks, superior—performance with far smaller models. [7] [8] [9]

These results do not prove that a tiny model is universally smarter than a frontier model. They prove something more commercially useful: universal intelligence is not required for every step of an agentic workflow.

Why the specialist-agent architecture wins

Consider an AI system that processes customer email, checks account status, classifies intent, selects a policy, drafts a response, updates a CRM, and escalates unusual cases.

The general-agent approach asks one large model to do all of it. Skills may load the customer-service policy and CRM instructions, but the same expensive model still handles classification, extraction, tool selection, drafting, and verification.

Each component can be evaluated against a precise contract, retrained independently, run locally when privacy matters, and quantized to fit its throughput and hardware target.

Agent economics expose the one-model problem

Agent workloads are not ordinary chat. They call a model repeatedly inside perceive-plan-act loops. Anthropic reported that its agents used roughly four times the tokens of ordinary chats, while its multi-agent research system used roughly fifteen times as many. [3]

A large model may be justified for difficult planning. Using it for every classification, formatting, extraction, and validation step compounds cost without necessarily improving the outcome. A small local specialist turns recurring token charges into reusable infrastructure capacity. Local inference is not free—hardware, power, monitoring, and maintenance remain real costs—but it changes the economics of predictable, sustained volume.

Five reasons specialists deserve a place inside the loop

1. Lower marginal cost

Do not activate a frontier-sized network when the job only requires a narrow fraction of its capability. The saving compounds because agent loops make multiple model calls per task.

2. Lower latency and higher throughput

Smaller models require less memory movement and compute. Quantization pushes the advantage further. QLoRA showed that 4-bit quantization could make fine-tuning dramatically more memory-efficient while preserving full-precision fine-tuning performance in its experiments. AWQ demonstrated 4-bit deployments with a reported three-to-four-times performance improvement over FP16 in TinyChat. Exact gains depend on the model, hardware, format, batch size, and serving stack. [10] [11]

3. Better repeatability on bounded tasks

General-purpose models are optimized across enormous input distributions. That flexibility is valuable during exploration, but it introduces behavioral variance. A specialist trained on the actual tool schema, exceptions, output format, and failure cases can be more consistent inside its target distribution.

4. Privacy and control

A locally hosted specialist can process sensitive operational data without sending every intermediate step to an external provider. This does not automatically make it secure; access controls, encryption, isolation, logging, updates, and prompt-injection defenses still matter. But data residency and model-version control become architectural choices.

5. A real improvement loop

A skill tells a model what to do. A specialized model can learn from validated examples. Incorrect tool arguments improve the function-calling specialist. Missed policy exceptions improve the policy model. Weak drafts improve the response model. The system develops competence at the component level instead of indefinitely expanding a markdown playbook around a generalist.

Skills survive—but inside a bounded architecture

The strongest version of this argument does not throw Skills away. It puts them in their proper place.

Skills are excellent for procedures that change frequently, inspectable reference material, deterministic scripts, and organizational rules that subject-matter experts must edit without retraining a model. Specialized models are better for stable, high-frequency behavioral patterns where latency, consistency, privacy, or per-call cost matters.

Agents remain necessary when a system must maintain state, choose actions, use tools, recover from failures, seek approval, or pursue an outcome across multiple steps. A skill cannot act by itself. It has no loop, goal, memory, permissions, or authority.

The real architectural question is which model should sit inside each loop.

The practical architecture: a federation of specialists

1. A lightweight router identifies the task, risk level, and required capabilities.
2. A specialized, quantized model handles a bounded role using a minimal toolset and only the relevant skills.
3. Deterministic code validates schemas, calculations, permissions, and irreversible actions.
4. A frontier model receives novel, ambiguous, or high-reasoning cases.
5. Human approval gates remain in place for high-impact actions.
6. Production traces and end-state evaluations feed a continuous improvement loop.

Routing has empirical support. RouteLLM showed that learned routers could reduce model-serving cost by more than two times in some evaluations without sacrificing response quality. The broader lesson is that model selection should be dynamic and based on the task, not permanently fixed at the most capable—and most expensive—option. [12]

There are limits. Maintaining several models creates versioning, routing, deployment, and observability work. Sparse traffic may not justify dedicated infrastructure. Poorly defined tasks will not produce reliable fine-tuning data. Quantization can reduce accuracy, especially at aggressive bit widths. Specialist models can fail badly outside their training distribution unless the system detects uncertainty and escalates.

Those are engineering constraints, not a refutation. They tell us when to use specialists, not whether specialists are viable.

The final verdict

Anthropic correctly identified the waste in building a new monolithic agent framework for every business function. It correctly made procedural knowledge modular, discoverable, and reusable.

But if its slogan becomes an argument for one general-purpose frontier model with an ever-growing library of Skills, it stops being simplification and becomes centralized overengineering. Anthropic’s own enterprise guidance says the library must be limited, routed, consolidated, evaluated in combination, secured like software, version-pinned, monitored, and pruned. That is an orchestration platform hiding in a folder structure.

Worse, the system repeatedly rents universal intelligence for jobs that can be learned, compressed, tested, permission-scoped, and executed by smaller models. Skills can tell one generalist how to impersonate many specialists. They cannot give the system the cost profile, fault isolation, learned behavior, or security boundaries of genuine specialization.

The future is not “skills instead of agents.”

The future is skills inside agents, specialist models inside bounded loops, routers that send only the hardest cases to frontier intelligence, and deterministic controls around all of them.

The agent is not dead. The general-purpose-model monoculture is.