Three years ago, the conversation in every enterprise was “tools for all.” Marketing had their stack. Sales had theirs. CS had theirs. Finance had theirs. Each function had bought four to six SaaS tools, each one optimised for a specific job, none of them talking to each other architecturally.
That sprawl became a problem. Then a category. Then an org chart line: Head of GTM Operations, Head of RevOps, Chief Strategy Officer. The discipline emerged because the sprawl forced it to.
I think we're about to repeat the pattern. Different layer, same shape.
Skills for all is the next sprawl.
Here's what I'm watching unfold in real time at the enterprises I'm closest to.
Six months ago, “agentic AI” in sales meant a Chrome extension that drafted emails. Today, every team that touches revenue is creating skills. The enablement team has built a skill for competitive battle cards. The marketing team has built one for content velocity tracking. The RevOps team has built one for forecast adjustment. The CS team has built one for renewal-risk scoring. The sales team has built three of their own, one per AE who got tired of waiting for someone else to build it.
Most of these skills don't talk to each other. Most of them aren't versioned. Most of them aren't centrally documented. Most of them have no clear owner if the person who built them leaves the company. Most of them duplicate functionality of skills already built elsewhere in the org the marketing team's content velocity skill and the enablement team's content gap skill are 70% the same skill, built by people who didn't know the other existed.
This is skills sprawl.
And it's about to be a much bigger operational problem than tools sprawl ever was, because skills are easier to create, harder to maintain, and significantly harder to audit.
A few things I'm thinking about as the pattern accelerates.
First, just like content management became a function inside enablement, skills management is going to become a function inside someone's org. Probably RevOps. Possibly a new GTM engineering function. The person who owns it will be responsible for: skill versioning, skill discovery (which skills exist? who built them? what do they do?), skill quality control, skill deprecation, skill interdependencies (which skills invoke which other skills), and the meta-question of when to consolidate two near-duplicate skills built by different teams.
Second, the skills that survive are going to be the ones that are autonomous, not just configurable. There's a difference between a skill that says “give me input X and I'll produce output Y” and a skill that says “watch for trigger Z and run automatically when it fires.” The first is automation. The second is autonomy. Enterprises will accumulate hundreds of the first kind and never use most of them. The few autonomous skills will produce most of the value.
Third, there's going to be a new kind of skill: the meta-skill. A skill whose job is to build, evaluate, or coordinate other skills. We've started experimenting with what Karthi and the team have been calling meta-skills internally skills that contain GTM context and taste, that other skills inherit from, that adapt themselves to the tenant they're running in. That's a different layer than “write me a prompt that does X.” It's closer to a programming abstraction. Most teams haven't started building those yet. They will.
Fourth, the skill hierarchy itself becomes architecture. Which skill calls which other skill, which skills share state, which skills run synchronously vs autonomously, what happens when two skills disagree these are real architectural questions, and they're the kind of questions that traditionally got solved by software engineers, not enablement leaders. The teams that figure out the architecture early will compound. The teams that let everyone build their own skills in isolation will spend Q4 2026 trying to figure out why their AI investments aren't producing results.
I don't have a clean solution to share.
I'm naming the pattern early because I think most enterprises haven't seen it yet, and I'd rather they hear it from someone who's been in their seat than discover it as a Q4 audit finding.
If you're a CRO or VP of Enablement or Head of RevOps: take an audit of every “skill”, “agent”, or “custom GPT” that's been built inside your function in the last six months. You'll probably find more than you expected, with less clarity about ownership than you'd like. That's the start of skills sprawl. The sooner you name it, the easier it is to architect around it.
Tools for all became RevOps. Skills for all is going to become something. It just doesn't have a name yet.
Naming it is half the work.
.avif)
.avif)