Stop Building Agents. Build Skills. What Anthropic Said That Changes Everything

The Founders’ AItrained on 25 years of our work

Questions as you read? Ask, or take the first-agent screen with you.

The first-agent screen → What's the difference between an AI skill and an AI agent?

Ask

Two Anthropic engineers stood in front of a room full of developers in November 2025 and told them to stop building the thing every AI vendor was selling.

“Stop rebuilding agents and start building skills instead.”

At the AI Engineer Code Summit, in front of an audience that had spent two years competing on agent count, agent autonomy, and agent benchmarks, that was a heretical sentence. It also happens to be correct.

Barry Zhang and Mahesh Murag had sixteen minutes. They used them to argue that the industry had been solving the wrong problem. Today’s agents are brilliant but lack expertise, the agent underneath turns out to be more general than anyone expected, and the expertise belongs in skills the agent loads when it needs them. They added that Fortune 100 companies were already using skills to teach agents their organizations’ best practices.

What follows is what they said, what has changed since, and what it means for how you invest in AI over the next twelve months. The short version of what changed: the format they described now runs well beyond Claude, which makes their argument stronger than it was when they made it. The technical move is small. The architectural implication is not.

The 16 Minutes That Changed How Developers Think About AI

The AI Engineer Code Summit is not a conference where heresy goes over well. The audience is developers and engineering leaders who have been deep in the AI agent space for two years: building, testing, deploying, debugging. Most of them work for companies whose entire AI roadmap is built around agents. Many of them are paid to ship agents.

Then two Anthropic engineers walked on stage and told them to stop.

The phrase “stop rebuilding agents” lands wrong because the entire AI market is structured around agent count as a proxy for capability. Vendor pitches measure agents per platform. Enterprise buyers evaluate platforms based on how many specialized agents they support. Investor decks show agent fleets as evidence of progress. The unspoken assumption: more agents = more intelligence = more value.

Zhang and Murag spent sixteen minutes dismantling that assumption. Their argument was technically simple and strategically devastating: agents are containers for capability. Skills are containers for knowledge. The industry has been optimizing the containers when the contents are what actually matters.

A 300 IQ generalist agent will give you intelligent-looking answers about taxes. An experienced accountant agent, the same model plus a tax skill, will give you the right answer. The difference is not reasoning capability. It’s domain knowledge. And domain knowledge is encoded in skills, not in agents.

What made the talk reverberate was not novelty. It was timing. Anthropic had shipped skills as a product five weeks earlier, on October 16, 2025, and by the time of the talk, the speakers said, that simple design had already grown into an ecosystem of thousands of skills. Zhang and Murag’s team did not invent the idea of writing expertise down for an AI to use. They built the format that made it practical.

Take this with you

Where to put your first AI agent.

A four-trait screen and a veto, so the first one you build survives contact with the work.

Homepage Send it to me

What Skills Actually Are (It’s Simpler Than You Think)

Here’s the part that surprises people most: a skill doesn’t need to contain any code.

A skill is a folder. Inside that folder is a markdown file called SKILL.md (a markdown file is just a plain text document with light formatting; anyone who can write a Google Doc can write one), plus optional reference files and, when a task calls for them, scripts. According to the Agent Skills specification, the file has to declare only two things at the top: a name, and a description of what the skill does and when to use it.

The rest of the file explains how the work is done. The reference files hold the deeper domain knowledge the skill needs to do its job well: templates, examples, constraints, reasoning patterns.

That’s the entire architecture.

When an agent encounters a task, it scans the available skills by their names and descriptions, the short summary at the top of each SKILL.md. If a skill is relevant, the agent loads its full SKILL.md. If the SKILL.md references a deeper file, the agent navigates to that file. The agent only carries what it needs for the task at hand.

To make this concrete: imagine a skill called client-proposal-writing. The folder contains a SKILL.md that describes when and how to write a client proposal in your organization’s specific style, plus reference files holding your past five winning proposals, your standard pricing logic, and your service descriptions and scope language.

When someone in your firm asks the AI to draft a proposal, the agent finds client-proposal-writing, loads SKILL.md, applies the patterns, references the winning examples and pricing logic, and produces a draft that reflects how your organization actually writes proposals. Not generic. Not approximate. The specific language, the specific structure, the specific positioning.

The radical simplicity is the point. Skills are not a new technology. They’re a discipline for organizing what your organization already knows, in a form an AI can use. If your firm has ever written an onboarding guide, a sales playbook, or a “how we run client proposals” document, you’ve already done the editorial work of a skill. Anthropic’s engineers draw the same comparison: building a skill, they write, is like “putting together an onboarding guide for a new hire.”

The difference is that the AI reads the skill whenever it recognizes that kind of work, not just on day one, and not only when someone remembers to consult the wiki. That recognition runs on the one-line description, which is why the description matters more than it looks.

The hard work is not technical. It’s editorial: deciding what your skills library should contain, how each skill should be structured, and what counts as “doing this work the way our organization does it.”

That’s a knowledge problem. It’s the problem most organizations have been trying to solve for decades through documentation, wikis, training programs, and process books. None of those tools were ever read consistently. Skills are different because the reader is the AI, and it reads them whenever a task matches.

Since the Talk, Skills Have Become a Standard

A month after Zhang and Murag spoke, on December 18, 2025, Anthropic published the skill format as an open standard, arguing that skills, like MCP, should be portable across tools and platforms. The other major AI vendors took it up.

OpenAI says its ChatGPT and Codex skills “build on the open agent skills standard.” GitHub Copilot and VS Code read skills straight from a project’s folders, including the one Claude Code uses. Microsoft’s Copilot Studio imports a SKILL.md for agents built on its GitHub Copilot harness, and Google’s Gemini Enterprise defines each skill by a core SKILL.md file.

That strengthens the argument this article makes. The advice was to treat the skills library as the asset and the agent as the runtime that uses it. When this article first appeared, the obvious objection was lock-in: a library written for one vendor’s assistant is only as portable as that vendor. That objection has mostly gone. The core file now travels between the major assistants, although each vendor adds its own settings around it, and those settings do not travel.

Skills also run across a whole team now. On Claude’s Team and Enterprise plans, owners can provision skills to everyone in the organization, turn on sharing between people and groups, and require an owner’s review before a skill is published to the shared library. Sharing is recorded in the audit log. All of this has been available since December 2025.

A team is not the same as a product line, though. Skills uploaded through the API stay separate from the Claude app and from Claude Code, according to Anthropic’s documentation. Skills in a Claude account do now load in Claude Code when you sign in with that account, but only in that direction: a skill built in Claude Code does not appear in the app.

The file travels. The controls around it (who may install it, share it, change it, and see that it ran) mostly stay where they were set. That is a management question more than an architecture one, and it gets its own treatment in our guide to how agent skills work.

Why One Agent + Skills Outperforms a Dozen Specialized Agents

Here’s the move that takes a minute to absorb but reshapes how you think about AI architecture: a single capable agent equipped with a library of skills beats a fleet of specialized agents, because it keeps what the organization knows in one place.

This is counterintuitive in 2026 because the AI market has been organized around the opposite assumption: that you need a sales agent, a marketing agent, a customer service agent, a finance agent, each purpose-built and separately maintained. The pitch is that specialization equals quality.

In practice, specialization equals fragmentation.

Twelve specialized agents means twelve places where organizational context needs to be loaded, twelve places where it can drift, twelve places where it has to be updated when something changes. Each agent starts with whatever context it happens to have access to: usually generic, occasionally tuned, rarely shared. When something works particularly well in one agent, that learning does not transfer to the others. The Claude Projects redesign answers exactly this with a memory every thread writes into. Each agent gets better, or worse, on its own trajectory. The fleet is twelve separate AI systems pretending to be one. We’ve covered the consequences of this pattern in detail in AI Agent Sprawl. The short version is that more agents without a coherent architecture make the organization less intelligent, not more.

Skills work differently. A skill encodes domain knowledge once and makes it accessible to whatever agent needs it. The client-proposal-writing skill is the same skill whether your generalist agent uses it for a sales draft, a marketing case study, or an internal capability deck. When you refine the skill with better examples, sharper reasoning or updated pricing logic, every future use of that skill benefits. Improvements compound across uses, not just within an agent.

The architectural mechanism that makes this work is called progressive disclosure. The agent does not load every skill into its working memory at the start of a task. Instead:

• It scans skill names and descriptions only, a short line per skill, to identify what’s relevant.
• It pulls the full SKILL.md for any skill that matches the current task.
• It navigates to deeper reference files only when the SKILL.md tells it to.

The agent carries what the task needs and very little else. A large library is cheap to carry, though not free: under the open standard, each skill’s name and description load at startup, roughly 100 tokens apiece according to the specification, and a skill’s full instructions load only when a task matches it.

The limit that matters is the description. The agent chooses a skill by reading those short summaries, so a vague or overlapping description means the right skill never loads, and nothing tells you it didn’t. Anthropic’s own enterprise guidance warns that with too many skills active, Claude “may fail to select the right Skill or miss relevant ones entirely.” When Vercel tested skills against its own Next.js tasks, the skill was never invoked in 56% of cases (January 2026). Write every description as carefully as the instructions underneath it.

“But isn’t the answer both?”

The most common reaction to the skills-first argument is a softening one: “the answer is both.” Yes, we need agents. Yes, we need skills. Why frame it as a choice?

The framing matters because the question isn’t whether you need both. Every skill has to run inside an agent, and every agent benefits from skills. The question is which one you treat as the strategic asset and which you treat as the runtime. The market has spent two years investing in agents as the asset: the procurement decision, the platform decision, the integration project. Skills, when they show up at all, are tactical accessories. Zhang and Murag’s reordering, and ours, is that the asset is the skills library, and the agent is the runtime that uses it. The components are the same. The investment posture is reversed. The compounding goes to the side that gets treated as the asset.

This is why skill libraries scale where agent fleets do not. Adding a new skill costs almost nothing: a folder and a markdown file. Adding a new specialized agent costs significant rebuild work. The cost curves diverge, and the organization that treats skills as the asset wins.

The Accountant Analogy: Intelligence Without Expertise Is Entertainment

Zhang and Murag used a simple question to make the argument land: who do you want doing your taxes? They cast themselves as the candidates. One was Mahesh, “the three hundred IQ mathematical genius.” The other was Barry, “an experienced tax professional.” The answer from the stage was Barry, every time, because nobody wants a genius working out the tax code from first principles.

In our terms, the first candidate has maximum reasoning capability and no domain knowledge. The second has ordinary reasoning and deep domain knowledge. When the stakes are real, you want the person who has done the work, who knows the regulations, who has seen the edge cases, who understands which deductions hold up under audit.

This is the choice every organization is making, mostly unconsciously, when they invest in AI.

The 300 IQ genius is the agent without skills. Powerful general capability. Excellent reasoning. No domain expertise. It can produce something that looks like a tax return: articulate, thorough, confidently formatted. And it can be wrong in ways that would never occur to a beginner, because it does not know what it does not know.

The accountant is the same agent, plus a skills library. Same general capability. The difference is that the agent now has access to encoded domain expertise: regulations, organizational pricing structures, product specifications, historical patterns, escalation rules. It produces work that reflects how the organization actually operates, not how an articulate stranger imagines it might.

Our reformulation: intelligence without expertise is entertainment. Expertise packaged up is productivity.

Intelligence without expertise is entertainment. Expertise packaged up is productivity.

This applies to every AI implementation decision. When you evaluate an AI tool, the question is not “how smart is the underlying model.” Most current models are smart enough. The question is: how easily does this tool let me encode my organization’s domain expertise into a form the AI can use? If the answer is “we don’t really do that”, and the tool’s value proposition is the model’s intelligence in the abstract, you’re being sold the genius. You probably want the accountant.

The market is currently saturated with geniuses. The competitive opportunity is in becoming the kind of organization that builds accountants: one that takes the expertise locked in your most experienced people, your historical decisions and your hard-won workflow knowledge, and encodes it into skills an AI can apply consistently and at scale.

Take this with you

Where to put your first AI agent.

A four-trait screen and a veto, so the first one you build survives contact with the work.

Homepage Send it to me

What Large Enterprises Are Already Doing With Skills

The talk also named who was already using skills. Zhang and Murag said they had been talking to Fortune 100 companies that use skills to teach agents their organizations’ best practices, including the particular ways they use their own internal software. They also described developer productivity teams serving thousands, and in some cases tens of thousands, of developers, using skills to teach coding agents the organization’s code-style expectations.

That second group is the clearest illustration. When one skill carries an organization’s coding standards into every developer’s AI tools, code quality stops depending on which developer wrote the code and starts depending on the standard written into the skill.

The same move works anywhere expertise can be written down. A compliance checklist with the order of checks and the escalation paths. The underwriting rules that live in three senior people’s heads. The standard for marking up a contract. The policy for handling a refund or an escalation. Those are our examples of where skills fit, not deployments the speakers reported.

Notice what’s not on this list: building more agents.

The architecture the speakers described points the same way: one capable, general agent, plus a growing library of skills that encode the organization’s specific expertise. The skills library is the strategic asset. The agent is the runtime that uses it. This is the same architectural argument we’ve made about knowledge bases that compound rather than just accumulate. Only now the skill format gives that knowledge a structure the AI can use directly.

This is the gap mid-market companies have not yet closed. The mid-market AI conversation in 2026 is still anchored around agent procurement: which platform, which vendor, which specialized agents to deploy first. The companies the speakers described had moved on to a different question: how to get their own expertise into skills.

The strategic implication for any organization not yet at Fortune 100 scale: the competitive moat is not the AI model you license, the platform you choose, or the agents you deploy. Those are commodities. The moat is the body of organizational expertise you’ve encoded into skills: the knowledge your AI uses, that your competitors cannot easily replicate, and that compounds in value every time you refine it.

Mid-market organizations that recognize this in 2026 will be operating in a different competitive category by 2027. The ones that don’t will be deploying their fourth specialized agent platform and wondering why nothing has structurally changed.

The Architecture Insight Anthropic Actually Made

There’s a deeper insight underneath Zhang and Murag’s talk, and it changes how you should evaluate AI tooling.

After building Claude Code, they said, Anthropic realized it was not only a coding tool but a general-purpose agent. The architecture they described is converging on four parts: an agent loop that manages the model’s context, a runtime that gives the agent a file system and the ability to read and write code, MCP servers that connect it to the outside world, and a library of skills. The loop reasons, the runtime acts, MCP reaches your systems, and the skills hold the expertise.

What’s interesting is what doesn’t change. The model can be upgraded. The runtime can be tuned. New connections can be added. But the structure stays constant. Every agentic AI system, when you strip it down, is a variation on this pattern.

What changes between a mediocre implementation and an extraordinary one is not the components. It’s the contents of the file system.

Specifically: the domain knowledge you’ve encoded into the files the model reads when it’s working. The skills. The reference materials. The accumulated patterns of how your organization approaches its work. The model is the same. The runtime is the same. The difference is the knowledge architecture you’ve built around it. And as we’ve covered in how learning loops keep that knowledge architecture improving over time, the architectural decision to make the system self-refining is what separates a snapshot from a living asset.

This almost entirely reframes the most common AI question we hear in client conversations: “which AI tool should we use?”

The tool matters much less than most evaluation processes assume. Within the current generation of capable AI platforms, the gap between the best and the merely good model is relatively narrow for most business applications. The gap that actually predicts outcomes is the knowledge architecture. An organization with a robust skills library running on a competent AI platform will dramatically outperform an organization with a marginal skills library running on the most capable AI platform.

That’s not a controversial claim if you think about it from first principles. Smart people without domain knowledge produce mediocre work. The same is true of capable AI models. The knowledge architecture is doing the work. The model just executes it.

The implication for AI strategy: stop evaluating AI primarily on the basis of model capability. Evaluate it on the basis of how well the platform supports the knowledge architecture you need to build: how flexibly you can encode domain expertise into reusable, accessible, improvable skills. That’s the variable that compounds. The model is just the runtime that uses what you’ve built.

What Skills-First Architecture Looks Like in Production

Here’s the part of this article that risks sounding self-promotional, but is too central to the argument to skip:

bosio.digital has been operating our internal AI operating system, the same one we deliver to clients, on skills-first architecture since early 2026. We restructured our internal stack around the pattern in the months after Zhang and Murag named it, the skills layer went live at the end of March 2026, and we have run production work on it every day since. Most of the market is still arguing about agents.

We didn’t read about this at a summit and write a think piece. We shipped it.

Concretely: our operating system is structured as a library of skills that encode organizational context (brand voice, client knowledge, financial logic, content production, service delivery patterns), alongside operational skills that handle workflow tasks. Every workflow we’ve built for ourselves and for clients is a skill. A folder. A SKILL.md. Reference files that capture the specifics. Each skill is reusable across the entire system. Each skill compounds in value as it’s used and refined.

When we publish an article, the writing process is shaped by a skill that encodes how we write articles: voice, structure, citation discipline, internal linking patterns. When we send a client proposal, the proposal is drafted using a skill that encodes our positioning, pricing logic, and service architecture. When we run financial reports, those move through a skill that encodes how we categorize expenses, what we measure, what’s considered material. The agent is generic. The skills are specific. The combination produces outputs that reflect how bosio.digital actually operates.

The architecture is the one Zhang and Murag described. If you want to see where it fits inside the broader maturity arc, where Stage 4 living intelligence is reached only when the skills library compounds, we covered that in the current state of AI for business.

This isn’t said as a victory lap. It’s said because it changes what we can credibly tell you about adopting skills-first architecture, and what we can show you, not just describe.

One limit on that experience, stated plainly: our library is written for Claude, and we have not moved any of it to another vendor’s platform. We can tell you what skills-first architecture does inside one system. We can’t yet tell you from our own work how cleanly a library travels.

For a mid-market organization considering this shift, the primary risk is not technical. The architecture is small. The risk is editorial: deciding what your skills library should contain, how to structure it, what counts as “this is how our organization does this work,” and how to maintain it without it becoming another stale documentation project. That work cannot be outsourced to a tool or a generic vendor. It has to be done by the organization, with help from someone who has done it before.

We’ve done it before. We did it for ourselves first. That’s the offer.

What Skills-First Means for Your AI Strategy in the Next 90 Days

If skills-first architecture is the direction, and the evidence above suggests it is, the practical question becomes: what does this mean for the next ninety days of your AI investment?

Three questions, each answerable by any leader, that diagnose where you are and what to build next.

Question 1: What workflows in your organization are currently locked in someone’s head?

Every organization has them. The senior person who knows exactly how to handle the difficult client situation. The operations lead who knows which approval shortcuts are safe and which aren’t. The veteran salesperson who knows how to position against the toughest competitor. This expertise is the most valuable knowledge your organization owns, and the most fragile, because it leaves when the person leaves. The first skills to build are usually the ones that capture this kind of knowledge before it walks out the door.

Capturing it does not make the person less important. A skill is that person’s judgment written down so the AI can apply it in more of the work, and it stays right only while someone with that judgment keeps it current. That is what we mean by Humans First AI: the AI carries your people’s expertise further, and your people remain the ones who own it.

Question 2: What expertise would become ten times more valuable if it were reusable?

Some knowledge is valuable when one person uses it. Some knowledge becomes radically more valuable when every relevant interaction can use it. Brand voice. Client communication standards. Decision frameworks. Pricing logic. Quality criteria. These are the categories where encoding into skills produces the largest leverage, because the skill applies everywhere the work happens, not just where the original expert is in the room.

Question 3: What does your AI skills library look like right now, and if you don’t have one, what are you building instead?

Most organizations, asked this question honestly, will answer that they don’t have one. They have AI tools. They have prompt libraries, maybe. They have a few custom GPTs or Projects floating around in individual accounts. They don’t have a skills library: a centrally maintained collection of structured domain knowledge that any AI agent in the organization can use.

The platforms have caught up with the idea. Claude’s Team and Enterprise plans support an owner-managed library with review before publishing, and the same skill file now loads in ChatGPT, GitHub Copilot and Gemini Enterprise. The missing piece is rarely the tool anymore. It is deciding what goes into the library and who keeps it current.

That’s the architectural gap. The next ninety days of AI investment, for most organizations, should be about closing it.

Not by buying a new platform. Not by deploying more agents. By identifying the most valuable organizational expertise, encoding it into skills, and building the institutional discipline to maintain and expand the library over time. The technology is small. The organizational work is significant. The competitive separation between organizations that do this and organizations that don’t is going to be visible within the next year.

The Architectural Choice

Stop building agents. Build skills.

The technical translation: stop optimizing the runtime. Start encoding the knowledge.

The strategic translation: stop competing on AI procurement. Start competing on the body of organizational expertise you’ve made accessible to your AI.

The honest translation, in our words: stop hiring 300 IQ generalists who’ve never read your tax code. Start training accountants.

The architecture is small. The work is real. The advantage compounds. The window for being early is narrow.

Sources

• Don’t Build Agents, Build Skills Instead (Barry Zhang and Mahesh Murag, AI Engineer Code Summit, New York, November 2025; video and transcript): the source talk, the tax question, the enterprise examples, the four-part architecture and the MCP distinction.
• Introducing Agent Skills (Anthropic, October 16, 2025): the launch of skills as a product.
• Equipping agents for the real world with Agent Skills (Anthropic Engineering, October 16, 2025): the onboarding-guide comparison and how progressive disclosure works.
• Skills for organizations, partners, the ecosystem (Anthropic, December 18, 2025): the open standard and organization-wide skill management.
• Agent Skills specification (agentskills.io, read September 2026): the two required fields and the loading tiers, including roughly 100 tokens per skill at startup.
• Agent Skills client showcase (agentskills.io, read September 2026): the 46 products listed as supporting the format.
• Provision and manage skills for your organization (Claude Help Center, read September 2026): owner provisioning, sharing, publishing review and audit logging on Team and Enterprise plans.
• Skills for enterprise (Claude Platform documentation, read September 2026): custom skills do not sync across claude.ai, Claude Code and the API.
• Build skills (OpenAI, read September 2026): ChatGPT and Codex skills built on the open standard.
• About agent skills (GitHub Docs, read September 2026): the project folders GitHub Copilot reads skills from, including .claude/skills.
• Use Agent Skills in VS Code (Visual Studio Code documentation, read September 2026): the same folders, read by VS Code.
• Skills overview for agents (Microsoft Copilot Studio documentation, read September 2026): SKILL.md import for agents on the GitHub Copilot harness.
• Create and manage skills (Gemini Enterprise, Google Cloud documentation, read September 2026): each skill defined by a core SKILL.md file.
• AGENTS.md outperforms skills in our agent evals (Vercel, January 27, 2026): the skill was never invoked in 56% of cases.
• Extend Claude with skills (Claude Code documentation): the SKILL.md folder structure in Claude Code.
• How Claude Code works (Claude Code documentation): the agent loop, and how skills differ from MCP connections.
• AI Agent Sprawl (bosio.digital): the architectural problem skills-first solves, agents accumulating without coherent organization.
• The Self-Improving AI (bosio.digital): learning loops and how skills compound when paired with refinement discipline.
• From Raw Data to Living Intelligence (bosio.digital): knowledge compilation as the substrate skills are built on.
• The Current State of AI for Business: A Practitioner’s Map (bosio.digital): where skills-first architecture sits inside the broader AI maturity arc.
• Trustworthy AI Agents (bosio.digital): the governance layer for agentic deployments running on skills.
• bosio.digital’s internal AI operating system: our production implementation of skills-first architecture, with the skills layer live since March 2026.

Frequently Asked Questions