A marketing team creates a "campaign brief" skill. A sales team builds a "customer email" skill. A customer support team writes a "customer response" skill. All three SKILL.md files do exactly the same thing: summarize customer context, apply the company's branding tone, and pull data from the company's CRM. This is skill sprawl.
Agent skills are easy to create locally, but become a challenge to maintain across teams. Even at smaller scale, different teams develop multiple versions of the same workflow. At larger scale, it's impossible to determine clear ownership, and there's no reliable way to know which skill is safe or canonical without governance. This needs a solution.
The basic approach is to keep them in a git repository. But that runs into limits very fast. For one thing, it's a non-starter for non-technical teams. Agent skills are somewhat unique in that they're not just engineering tools — they're ubiquitous. Business owners and non-technical users need to author and use them too. Another reason is the lack of necessary features: observability, granular access control, and versioning enforcement. This becomes a distribution and governance problem.
Four Categories of Problems
We can categorize the stated problems into four groups:
- Governance: Who approves a skill? Who owns it? Who can modify it? Who decides when it is deprecated?
- Quality: Does the skill produce reliable outputs? Does it work across different tasks, models, and harnesses?
- Observability: Which skills are used frequently? Which ones are failing? Which hogs all the traffic?
- Distribution: How is versioning enforced? How are skills discovered by agents and users? How do breaking changes roll out safely?
MCP as a Distribution Layer
MCP server solves several of these problems. MCP is not just for the developer's convenience. It's an instrumentable distribution layer that solves the N×M integration problem by standardizing two-way communication between LLMs and external tools. Agents pull skills remotely via a structured protocol instead of reading local files. Every skill invocation is logged in real time. Versioned endpoints replace file edits. Promoting from experimental to stable is easily auditable.
Reference Implementation
The reference implementation: fastmcp-skill-server (built on FastMCP).
- Two MCP tools:
list_skillsreturns available filenames;get_skillreturns raw.mdcontent on demand - Skills live as
.mdfiles in askills/directory — the server just serves them - Single Docker container, bearer token auth, Python 3.12 + uv
SKILLS_DIRenv var + volume mount (-v ./my-skills:/app/skills) lets domain teams run federated servers from the same image without touching platform infrastructure
CI/CD-gated evaluation:
- Skill eval: did the agent produce correct output using the skill?
- Route eval: given a prompt, did the agent select the right skill? (observable via MCP proxy)
Using an MCP server allows us to address several problems. The remaining ones are organizational. The platform engineering team can help maintain the features for the MCP server while domain teams operate the services.
Ownership Model
| Stakeholder | Responsibility |
|---|---|
| Platform engineering | Owns MCP infrastructure; sets technical standards; publishes blueprint for domain-team federated servers |
| Domain teams | Author skills; named owner required per published skill |
| Security | Reviews permissions and sensitive integrations |
| Compliance | Reviews regulated workflows |
| AI enablement | Owns standards, test harnesses, release policy |
| Cross-functional committee | Approves canonical repo entries; enforces named owner + sunset date |
From the Field: AgentCamp Bangkok
At AgentCamp Bangkok, Joel Dickson from Agoda Thailand described exactly this problem at scale. Tens of skill repositories, teams distributed across time zones, no shared governance. His solution was to create a consolidated service maintained by committees coming from different teams. He deliberately reduces velocity for introducing new skills in exchange for a higher level of reliability.
Three Problems Without Good Solutions Today
Cross-runtime validation. The tooling landscape in 2026 is still fragmented without a dominating player. New harness and runtime environments emerge every day; it's impossible to design a proper validation system for every single one of them.
Routing opacity. Skill selection logic is a combination of harness, underlying model, and the skill's metadata itself. Greedy skills that dominate routing are still difficult to detect.
Content layer review done by human reviewers is still the bottleneck.
The Bottom Line
Enterprise agent skill distribution is a solved problem at the infrastructure level. The organizational model is harder, and most teams discover this the wrong way.
SaiJaiAI works with enterprise teams to design the operating model, MCP distribution layer, evaluation pipeline, and observability stack from day one. If you're standing up an agentic workflow at scale and want to skip the trial and error, let's talk.