TL;DR
- Agent sprawl is real — but the harder problem underneath it is skill sprawl. Skills that exist but aren't wired in. Skills that are wired in but stale. No single view of what you have.
- Skills and MCP servers are now the shared infrastructure layer of any agent setup. They need the same lifecycle code has always had: versioning, distribution, update propagation.
- For a solo builder: a registry with an update loop means fixing a skill once reaches every harness. That loop didn't exist before.
- For teams: the question isn't just "do we have skills" — it's "which version is each developer on, who reviewed it, and is it safe to run."
- Autonomous agents running headless in CI still need skills. They still drift. The manual sync model breaks when there's no human at the keyboard.
Have you been running into agent sprawl over the past year?
I have. Not in an abstract way — concretely. I have over 80 skills built up across a year of working with AI agents. They live in .claude/skills/, .agents/skills/, repo-specific directories, content drafts folders, and at least a dozen places I'd have to grep to find. Some are wired into Claude Code. Some into Cursor. Some into neither. Some were written, used once, and never touched again. A few I rebuilt from scratch because I forgot they already existed.
That's skill sprawl. And it compounds the agent sprawl problem instead of solving it.
The Thing Nobody Warned You About
When people talk about agent sprawl, they usually mean too many agents, too many tools, ungoverned access. That's real. But the harder problem is one level below it.
Skills are the shared context layer that makes agents useful for your work, not just capable work in general. I wrote about this last year — the difference between an agent that can do a thing and an agent that does the thing the way you need it done is the skill. The methodology, the heuristics, the failure modes, the output format. That's the skill.
The problem is that skills don't have a lifecycle. You write one. It lives somewhere. You fix a bug in it. The fix lives in one place. Every other harness, every other machine, every other developer on your team is still running the old version. Nobody knows.
This is the same problem software had with dependencies before package managers. You'd copy a library into your project. It worked. Then upstream fixed a bug. You never heard about it. You're still running the broken version.
Skills are there now. And MCP servers are getting there fast.
What My Workspace Actually Looked Like
Here's the concrete version. Across four repos on my main machine, I found 48 SKILL.md files. Some were installed properly — vendored into the right harness directories, showing up when agents loaded. Most weren't. They existed as files. They weren't doing anything.
The skills that were wired in were split: some in .claude/skills/, some in .agents/skills/, a few symlinked from a personal repo. When I fixed a skill — added a missing step, corrected a failure mode I'd hit — I updated one copy. The others stayed stale. I had no way to see which harness had which version without going directory by directory.
I wasn't managing skills. I was accumulating them.
The market is hitting the same wall at scale. Microsoft shipped APM in April — positioning it as the package.json for AI agent configuration, where you declare skills, prompts, instructions, and MCP servers once in an apm.yml and every harness gets the same setup. Portkey shipped a skills registry the same month. "Agent harness sprawl" is appearing in enterprise risk frameworks. The average enterprise now runs 12 agents, according to Salesforce's 2026 MuleSoft Connectivity Benchmark — and 50% of those agents are operating in isolated silos with no enterprise-level governance.
We spent 2025 building agents. We're spending 2026 figuring out how to govern what we built.
Skills and MCP Servers Are Infrastructure Now
The frame that clarifies this: skills and MCP servers are no longer optional context. They're the infrastructure layer of any serious agent setup. Every harness needs them. Every autonomous agent needs them. They need to be versioned, distributed, and kept current — the same way any other shared dependency does.
That's what was missing. Not better skills. Not more skills. A lifecycle for the ones that already exist.
When I publish a skill update today, tessl update propagates it to every harness that has it installed — Claude Code, Cursor, Codex, .agents/skills/, all of it. One command. I don't touch each directory manually. I don't remember to sync anything. The fix reaches everywhere or it reaches nowhere, by design.
That loop is the entire value. It's small and it's precise and it didn't exist before.
What This Means for Teams
Multiply my problem by a team of ten.
Now every developer has their own version of the skill. Some have the one from last month. Some have a fork they modified locally. Nobody knows whose is authoritative. Someone hits a failure mode and fixes it in their copy. The fix never propagates.
The questions a team needs to answer — which skills are approved to run, who reviewed them, what version is each developer on — are the same questions they already answer about npm packages. Dependency governance is a solved problem in software. It just hasn't been applied to skills yet.
The governance layer a team needs: which skills are approved, who reviewed them, what version each developer is on, a CI gate that fails the PR if the version wasn't bumped. That's a solved problem in software — it's what registries with role-based access and semantic versioning do. Tessl applies that model to skills. For a solo builder, most of it is overhead. The value is just the update loop. For a team, the governance layer is the point.
Autonomous Agents Are the Part Nobody's Talking About Yet
Here's where this gets sharper.
I run autonomous agents — headless sessions, CI pipelines, scheduled workflows with no human watching. They use tools. They follow workflows. They need skills to do that work the way I need it done, not just in a generic capable way.
Those agents still drift. When I update a skill, a headless agent running in CI has no way to know. It's still loading the old version. There's no person at the keyboard to notice.
tessl launch skill targets OpenHands, Codex CLI, and other autonomous runtimes directly. The same registry, the same versioned snapshot, the same update command — but the consumer is a running agent instead of a developer's local harness. The skill reaches the autonomous agent the same way it reaches Claude Code.
That closes the last gap. The manual sync model works when a human is at the keyboard. It breaks when the agent is running on its own.
What's Still on You
The inventory scanner (tessl inventory import) is built for exactly the problem I described — finding the skills you already have scattered across repos. It didn't work for me: it only reads public GitHub org repos, and my skills live in private personal-account repos. Zero results. The migration from sprawl to managed is still a manual job if your setup looks like mine.
Publishing is unilateral by default. Anyone with Publisher role can push to the registry with no review step. The CI gate exists — you have to choose to wire it in. The infrastructure is there. Whether teams actually enforce it is still a social decision.
Auto-generated evals only work for skills with a checkable output. Conversational workflows don't generate scenarios. You have to write those by hand.
These are real gaps. They don't undermine the core loop — publish, install, update — but they're worth knowing before you build on top of it.
The Open Question
The industry is converging on this fast. Microsoft APM, Portkey, and Tessl are three different bets on the same gap, made within months of each other. The format already converged — SKILL.md is readable by 30+ agent platforms. What was missing was the lifecycle. That's what's being built now.
For me, the immediate value was simple: fix a skill once and the change reaches every harness. That's it. That's the thing that didn't exist before.
Whether any of these tools becomes the standard the way npm did — or whether the whole category stays infrastructure for teams already thinking carefully about this — is the question the market hasn't answered yet.
For the broader argument — why the industry converged on git-native distribution and what it means that one company built the complete lifecycle — see Skills Are a Git-Native Distribution Primitive.
Top comments (0)