Your know-how is now a folder of markdown: skills sprawl, and the microservices mistake worth skipping this time

At the AI Engineer conference last week, Imad Touil of QuantumBlack, McKinsey’s AI arm, gave a talk on how AI-native organisations run on skills that we have been forwarding around the team ever since. His argument, compressed: agents, harnesses and MCP servers are all becoming commodities. The thing that is not a commodity, the thing that is actually yours, lives one layer up.

We obviously have a horse in this race: shareskills exists because we believe exactly that. So treat this post as a sympathetic read, but one that went and checked the claims. The short version: the evidence that skills work is now quantitative, the sprawl he warns about is real (we can see the early symptoms in our own 33-skill library), and the industry has been handed a rare gift, which is the chance to learn a governance lesson before the mess instead of after it.

How skills became the unit

A skill is a folder with a `SKILL.md` in it: instructions an agent reads before doing a job. We have written a plain-English guide to when a task deserves one. What changed in the last nine months is that this stopped being an Anthropic feature and became infrastructure. The format was published as an open standard in December 2025, and by mid-2026 roughly forty products read it, including Claude Code, OpenAI’s Codex, GitHub Copilot, VS Code, Cursor and Gemini CLI. In August, the Agent Plugins 1.0 packaging standard from Amazon, Microsoft, OpenAI, Cursor, GitHub and Vercel adopted the same skill format as its payload.

Touil’s framing for why this matters is the sharpest we have seen: a skill makes organisational know-how executable, portable and cheap. Your contract-review playbook used to live in a senior person’s head, then in a wiki page nobody read. Now it is a file an agent actually runs. That is a genuinely new kind of asset, and organisations are minting them at speed, mostly without noticing.

The evidence they work is no longer vibes

For most of the past year, “skills make agents better” was folklore backed by demos. It now has a benchmark. SkillsBench, published in February, pairs 87 tasks across 8 domains with curated skills and deterministic verifiers, then runs every task with and without the skill across 18 model-and-harness configurations:

• Curated skills lifted the average pass rate from 33.9% to 50.5%, a 16.6 percentage point absolute gain, with every configuration improving (from +4.1 to +25.7 points).
• Smaller models with skills can match larger models without them. Written-down know-how substitutes for raw model capability, which is a remarkable economic fact hiding in a benchmark table.
• Focused skills beat big ones. Skills with at most three modules outperformed larger, exhaustive bundles. Piling everything you know into one mega-skill measurably hurts.

That last finding matches what we see in practice. When we wrote up how our own team runs a client meeting on six shared skills, the design rule that made the pipeline trustworthy was one job per skill, chained, never one monolith. It is nice when the benchmark agrees with the scar tissue.

The warning: we have run this experiment before

The second half of Touil’s talk is the uncomfortable half. If skills are where the value concentrates, then unmanaged skills are where the liability concentrates, and the software industry has a precedent for exactly this shape of failure. In the microservices era, teams that could suddenly mint services cheaply did, by the hundreds. Uber ended up with thousands of services with overlapping APIs and tangled dependencies; Gilt Groupe accumulated hundreds of redundant ones. The pattern was always the same: the unit of work got cheap to create before it got cheap to find, trust and retire.

His team modelled it: fifteen teams creating skills independently over six months, no shared visibility. Duplication compounds, quality variance widens, and nobody can answer the question that eventually matters most: which version of our know-how is the agent actually running? With a registry in the loop, the simulation flips. The moment one team publishes a skill, the next team’s harness discovers and reuses it, and the whole organisation gets a common floor.

What sprawl looks like at 33 skills

You might file that under “enterprise problems, not mine.” Here is the thing: we run a small team, our library holds 33 skills, and the early symptoms are already visible in it. Two people wrote two overlapping tender-response skills about a week apart, one covering the pipeline, one covering the writing style, neither knowing about the other until they were both published. We have two different meeting-notes skills that arrived from two directions. And one skill in our library is literally slugged `name`, because someone saved the scaffold without filling in the placeholder, and a slug is forever.

None of this is a crisis. All of it is the seed of one. Every symptom above surfaced because the library is shared: the duplicates were visible enough to notice, merge and assign an owner. The same two tender skills as files on two laptops would have quietly diverged for a year. If sprawl shows up at 33 skills in one team that talks every day, the fifteen-teams-six-months simulation is not a hypothetical, it is a forecast.

What governance actually has to do

The microservices era also teaches what the fix is not: an architecture review board that everything queues behind. The teams that got it right invested in a platform that made the good path the easy path. Translated to skills, we think the checklist is:

• One place to look. A catalog agents can search, so the second team discovers the first team’s skill instead of rewriting it. Discovery is the anti-duplication mechanism; nothing else scales.
• Versions with history. Every run should start from the current version, and “current” should be a fact, not a guess. Version drift across copied skills is how last quarter’s rules keep reviewing this quarter’s contracts.
• Ownership and roles. Anyone can propose a change; a maintainer approves it. The library stays alive without becoming a free-for-all.
• Trust at the update boundary. Skills from outside your org are a supply chain, and the update is the attack surface. Risky changes should be held for human review; internal iteration should stay frictionless. Those are different trust problems and deserve different treatment.
• A way out. Retiring a skill matters as much as publishing one. A catalog full of zombies is a catalog nobody trusts.

Readers of this blog will recognise that list as, roughly, shareskills’ product roadmap, which is the sympathetic-reader disclaimer from the top of this post cashing out. We built the library, the versioning, the propose-and-approve roles and the update gate because we hit each of these problems in our own work first. The talk gave us better language for why they generalise.

The cheap time to start is now

The microservices generation adopted governance after the sprawl, at the price of multi-year platform migrations. Skills offer the rare chance to do it in the right order, because most organisations are early: the research says five in six AI users are still in the chat window, and most teams’ skill count is closer to our 33 than to Uber’s thousands of services. Adopting a registry when you have a dozen skills is an afternoon. Adopting one when you have four hundred, spread across laptops and forked into private variants, is a project with a steering committee.

Touil’s framing deserves the last word, lightly paraphrased: skills are the first format in which organisational know-how is executable. That makes your skill library a strange new thing, part codebase, part employee handbook, part institutional memory. You would not run any of those three without knowing where the current version lives. Now there is a fourth thing, and the same rule applies.