← back

Agent Skills Are Not a Developer Problem. They're a Democratization Problem.

Apr 25, 2026·11 min read·
Agent SkillsFuture of AIEnablement

For about 30 years, the default assumption in software has been that the person who writes the code owns the behavior. You want the app to do X? Open a ticket. Wait a sprint. Ship it. The developer is the bottleneck because the developer holds the only language the machine understands. And the one who wields the power to shape the machine becomes the one to make or break it. But, perhaps we can do better.

Agent Skills are the gateway I’m going to use for this thesis. Is this post really about skills? Yes. Is it really, really about skills? Not really. Ask me the third time and I’ll admit this is actually a blog post trying to sell you on vegan ice cream, or worse, implementing MCPs across your org without RBACs.

A skill, in the Anthropic sense, is a folder with a SKILL.md file and maybe some supporting scripts. The SKILL.md is prose. It describes, in English, how an agent should behave when a particular kind of task shows up. “When the user asks for a Word document, do this. Here are the gotchas. Here’s what ‘good’ looks like.” The model reads it and acts accordingly.

This is the first real democratization of software behavior. Not “democratize AI” in the vague marketing sense - I mean something specific and historically unprecedented: the set of people who can author what a machine does has just expanded from “people who can code” to “people who can write down what they know.” That’s a different population by roughly two orders of magnitude. And every “who owns the skill registry” conversation I’ve seen in the last six months is asking the wrong question because it hasn’t absorbed this shift. The question isn’t which platform team runs the registry, or which devtools vendor wins the SDK wars. The question is: who knows how the work should actually be done?

The domain expert was always the bottleneck. We just couldn’t see it.

Take a concrete example. A law firm wants its agent to draft client memos. You can imagine two versions of how this goes.

Version I: developer interviews a partner for 45 minutes, takes notes, goes home, writes a prompt, iterates for a week, ships something the partner looks at and says “no, that’s not how we do it here, the citation format is wrong, the hedging is too aggressive, nobody opens with a summary at this firm, where did you get that structure from.” Back to the drawing board. This is the Jira-ticket cognitive architecture. It’s what we’ve been doing forever. It’s slow because the knowledge lives in the partner’s head and has to be translated, twice, through a person who doesn’t have it.

Version II: the partner writes the skill. Or - more realistically - the partner writes the draft of the skill, in the same English they’d use to train a first-year associate, and someone cleans it up. “When drafting a memo, open with the question presented. Never hedge on statutory interpretation without a Bluebook cite. Our house style for footnotes is X. Watch out for - ” and so on. The behavioral surface of the agent is authored by the person who knows the behavior.

The developer’s job in version two is not to write the skill. It’s to build the loader, the sandbox, the eval harness, the registry. The infrastructure. The physics of the system. That’s still real work - but it’s not the content. The content belongs to whoever owns the domain.

This is a bigger deal than it sounds. Because for the entire history of enterprise software, the org chart has been bent around the fact that developers had a monopoly on encoded behavior. Product managers wrote specs that developers translated. Designers made mockups that developers implemented. Domain experts gave interviews that developers synthesized. Every piece of organizational knowledge that made it into a system had to pass through a translation layer, and the translation layer had a throughput problem and a telephone-game problem.

Skills route around the translation layer. Not completely - somebody still has to test the thing, version it, make sure it doesn’t regress. But the authoring moves.

Which is why the registry matters, and why it isn’t a devtools product.

Once you accept that skills are domain artifacts rather than engineering artifacts, the shape of what a skill registry needs to be changes pretty dramatically. A code registry - npm, PyPI, Maven - is optimized for developers. Semantic versioning, dependency graphs, CI integration, the whole stack. It assumes the author is technical and the consumer is technical and the artifact is code.

A skill registry can’t make any of those assumptions. The author of a good “draft-a-discovery-request” skill is probably a litigator. The author of a good “triage-this-patient-intake” skill is probably a nurse practitioner. They’re not going to learn git. They shouldn’t have to. The whole point is that the English they already write is the artifact.

So the interesting design questions for skill registries aren’t the ones the devtools vendors are racing to answer. They’re things like:

You can actually see what democratization looks like when someone takes the premise seriously. Go poke around skillsmp.com/occupations for 5 minutes. The top-level navigation isn’t “JavaScript” and “Python” and “Rust.” It’s the U.S. Department of Labor’s Standard Occupational Classification - 23 major groups, 867 occupations, from paralegals to pediatricians to petroleum engineers to pastry chefs to dancers. Each occupation has its own bucket of skills. Lawyers get one. Registered nurses get one. Insurance underwriters get one. Cooks, private household gets one.

That’s what a democratized registry looks like. It looks like the BLS, not like npm. And once you see it that way, you can’t unsee it - the shape of the index tells you who the index is for, and npm’s shape is telling you a very specific story about whose knowledge it thinks is worth cataloging. A registry organized around occupations is making a different bet: that the next decade of valuable machine behavior will be authored by everyone who has an occupation, not just by everyone who has a GitHub account.

Democratization also means translation.

You can put the most beautifully designed, mouth-watering authoring tool in the world in front of a nurse manager or a senior underwriter, and it will still fail if the first thing they see is the words “agent skill” and “MCP server” and “tool-use schema.” Because those words don’t mean anything outside of a pretty small room.

Democratizing software creation doesn’t only mean “let non-developers write behavior.” It also means building a translator layer on top of the vocabulary - one that turns the insider terms into things the consuming entity can actually reason about. An “agent skill” to a litigator is a trained paralegal with a written playbook. An “MCP server” to a hospital ops lead is a hookup to the EHR. A “registry” to a curriculum team is a shared drive of lesson plans, with rules about who can edit what. None of those translations are perfectly precise. They don’t need to be. They need to be close enough that the person on the other end can say “oh, I know what that is, I’ve been managing those for fifteen years” and start using it.

This is the part the industry is worst at. We name things for ourselves. We publish docs written by the people who built the thing, for the people who are about to integrate with the thing, and we act surprised when the actual user - the one whose job the thing was built to change - bounces off the first paragraph. A democratized registry doesn’t just lower the authoring floor. It lowers the comprehension floor. If a plumber, a pediatrician, and a paralegal can’t read the landing page and understand what this is for them, the translation layer hasn’t been built yet, and the democratization hasn’t actually happened - no matter how elegant the underlying primitives are.

The companies that figure this out first win the decade. We get wrapped up on who’s gonna win the AGI race, when your real big win is sitting a few corridors away, at sales, or maybe HR.

real footage of us toiling away

real footage of us toiling away when the real brink of abundance is living amongst us

This inverts where most companies are putting their AI budget. Right now the money is going to platform teams, to MLOps, to whoever promises an “AI transformation.” Fine. That infrastructure needs to exist. But the delta between a company that uses agents well and a company that doesn’t isn’t going to come from the platform. It’s going to come from whether the people who actually know how the work gets done were given the tools, the permission, and the 30 minutes it takes to write down what they know.

Which is a management problem. An HR problem. A knowledge-capture problem. A democratization problem.

Real paradigm shifts come from the mental model you are operating from, to build the tentacles of the lean mean machine you wish to create. So, the shift from “coding is a mostly resolved problem” ( and the associated dread this tends to stir in devs..) needs to turn into “We write less code by hand, for us. And now - also for others”

Skills are prose. Prose is written by the people who know things. For the first time in the history of software, the people who know things don’t need a translator. The registry, the governance, the review process, the authoring tools - all of it has to be built for them, not for the developer who used to hold the keys.

Claude Desktop, Codex, and whatever may come next - is our north star. A developer skill delivered through a developer surface would be the old world with a new coat of paint. We meet them where they are: They’re in a desktop app, same as they are for Slack or Notion or email. The skill meets them there, in the app they already open on Monday morning, and asks them questions in English about the domain they already know. That’s the delivery channel the democratization actually runs on.

In most orgs, developers are a minority of headcount once you count sales, support, legal, finance, ops, design, and people. The “non-developer” isn’t some edge-case persona in the corner of the org chart. They are the org chart. Every authoring tool built only for the developer minority is, by construction, a tool built for the wrong 90% of the company.

Which means the inverse is also true: If you can empower the 90% of people who actually do the work, you’re not making a productivity tweak—you’re creating compounding revenue in places it has never compounded before. It’s all very circle-of-life, without one of your favorite Disney characters meeting its sad demise. We feed the grass, the grass feeds us, and then we all sit very content on our next quarterly call as the sales team showcases how they secured 2x more contracts thanks to one senior seller’s tactics (a hidden gem until then, btw) being translated into an agent skill called “My Second Sales Brain” and handed to every new hire.

So, to the part where I make my final point: I’ve built a meta-skill to allow anyone to build a skill registry. You drop it into Claude Desktop, you say “help me design a skill registry,” and it walks you through the four decisions that actually matter:

It walks you through those decisions and then assembles a working skill registry for you at the end.

Get it here.

And if you’re a developer reading this and feeling a little sidelined - don’t. The force needs us now more than ever. Somebody still has to build the thing the nurse manager’s design document turns into. The loader, the sandbox, the eval harness, the registry service itself, the lightsabers (if you want to keep the metaphor running..)

You’re just no longer the only person in the room with a lightsaber, there are others indistinguishably like you, that used a framework agent skill of how to build lightsabers.