A million agent skills in seven months, almost half installed once

In seven months, a public catalogue of agent skills passed GitHub, npm and the App Store in time to 1 million units. Nearly half of what it accumulated in that period was installed exactly once. Both sentences come from the same report, State of agent skills, published by Vercel on 25 September 2026, and together they describe a collection of attempts, not an installed base.
The current reading treats an install as adoption. The report does not support that reading and states it in its own methodology note: the counters are aggregates of the catalogue, not unique people, not independent choices. What exists is a very visible supply and a demand that has not yet learned how to measure itself.
What the first million agent skills show
The report measured one thing only: what people install when the agent gains a new capability without changing models. The Agent Skills format was introduced by Anthropic in October 2025, the skills.sh site, which hosts the catalogue, opened in January 2026, and seven months later the count passed one million.
Three lines summarise the finding.
- The catalogue reached 1 million skills and nearly 280 million installs in seven months of operation.
- Nearly half of the skills were installed exactly once; 375 of them, 0.04% of the catalogue, account for 62% of installs, and the top 1.2% accounts for 94%.
- The time to 1 million was shorter than GitHub's, the App Store's and npm's, in the comparison made by the report itself.
The million is supply. A publishing channel without friction grows fast, and the third line is the easiest headline to write. The second is the one that matters to a company, because it describes a catalogue in which almost everything is an attempt and almost nothing is routine.
| Platform | Months to 1 million units | Data source |
|---|---|---|
| skills.sh | 7 | State of agent skills report (Vercel, 25 Sep. 2026) |
| GitHub | 27 | Same report, comparison made by Vercel |
| App Store | 63 | Same report, chart caption |
| npm | 117 | Same report, comparison made by Vercel |
None of the last three rows went through independent audit: they are Vercel's comparison with the trajectory of other platforms, and they enter here as a claim by whoever operates the catalogue. The four rows also do not measure the same unit, because a packaged skill, a repository, an application and a package are not the same thing, and the chart places all four on the same axis of months. The caution is not formality. A number that crosses four platforms without a common methodology is a narrative, and narrative is precisely what this subject has no shortage of.
A catalogue of a million is not a market of a million
A million published skills measures the size of the supply. The report states that the install counters are aggregates of the catalogue, not unique people or independent choices, and records that nearly half of it was installed once. That describes a collection of attempts, not a base in operation.
The arithmetic in the report is simple and uncomfortable. Three hundred and seventy five skills account for 62% of installs, and the most installed skill of all stays below 1% of the total. The report reads the same data as the absence of a winner: competition happens inside each task, because the team that chose an expense report skill has no reason to install a second one. An item that does not reach 1% of installs is nobody's default, and a catalogue without a default is not copied from a report.
The current reading is that 280 million installs prove corporate traction. They do not. The counter adds up installation events, and the report declares the counters to be aggregates of the catalogue without describing the counting mechanism. What the counter does not record is what matters: whether the skill ran once, whether it ran a thousand times, whether it was granted permission to touch a real file, or whether the team still remembered it existed two weeks later.
The failure mode is silent and it has a shelf life. A skill was written for the model and the tool format in force in the month it was born; when the vendor changes the shape of a response or the connector moves to a new version, it stays installed and stops working. The install that counted it does not disappear. The catalogue measures installation, not operation. The most expensive case is the reverse: the skill that keeps running and gets worse, without raising an error, delivering a plausible result that nobody opens a ticket to dispute.
That holds for a skill as an isolated artefact. A skill that only describes a procedure in text ages slowly. The one that calls an external tool ages at the speed of the connector.
Agent tooling ages by the same mechanism, and faster. A tool registry for agents solves discovery and authorization; versioning what has already been authorized remains the work of whoever operates it.
The supply is technical, the demand is business
More than half of the listings teach software engineering, agent workflows, data, infrastructure or security, and software engineering alone accounts for about a quarter of the catalogue. In installs the order changes: engineering sits at 18%, agent workflows at 15%, business operations and writing close to 11% each, and no category passes a fifth.
The average per listing shows who sustains the catalogue. Business operations receive 74% more installs than the overall average, writing and documents 50% more, cloud and infrastructure 42% more. Software engineering receives about 30% less, education and productivity 39% less, research 55% less. The people who write skills are engineers automating their own work. The people who install skills are people with work left over on a Tuesday.
Agent workflows and automation add up to 14.8% of installs in the classified sample, behind only software engineering, and they form the largest category among listings with 100 thousand installs or more. What scales is not the skill that knows more. It is the one that chains better.
That inversion has a direct consequence for buyers. A catalogue stocked by engineers offers excellence in problems the buyer has already solved, and offers little where the operation gets stuck: reconciliation, billing, proposal follow up, month end close. The distance between the people who publish and the people who pay the bill is the space left open for whoever implements agents inside a company.
Where the generic skill stops and the company's judgement begins
Work common to any sector accounts for 66% of classified skills and 87.5% of installs, with an average of 3.6 times more installs per listing than skills specific to one sector. Only one in eight installs is tied to a specific sector. The catalogue delivers the generic with efficiency and leaves the specific entirely to whoever operates.
Generic, here, has a precise meaning: the skill works in any company because it knows nothing about yours. A skill that reviews contracts can be excellent across different companies precisely because it ignores the taxonomy of clauses, the amount above which legal has to approve, and the list of counterparties the commercial team knows by heart.
The judgement that separates one company from another lives in those three details, and none of them fits in a public catalogue. That is why 87.5% of installs go to work common to any sector: the catalogue delivers what is common with efficiency, and what is left is the operation, and that is where the agent has to get it right.
A skill is a piece of corporate software. It has an owner, a review, a permission, a version and a maintenance cost, and that cost grows with the number of systems it touches. Treating a skill as a disposable package is the mistake the next phase of the market will charge for, and the charge arrives in the form of a simple question: who approved that skill that ran over the CRM last quarter?
The cost the install does not show: reviewing, authorizing and maintaining
The install costs one command. What comes after it costs process: someone decides who approves the skill, which files and systems it can reach, in which environment it runs, how you prove it improves the work, and who maintains it when the model or the connector changes. None of that appears in the catalogue counter.
The path of a skill inside a company has seven steps, and the first one begins before the download.
| Step | Control question | Who answers |
|---|---|---|
| Catalogue | What is installed, in which workspace, at which pinned version, published by whom and under which namespace? | Owner of the agent platform |
| Selection | Which process problem does it solve, and what is the alternative without it? | Process owner |
| Review | Who read the content and, when the skill ships a script, the code and the dependencies before it runs? | Security and process owner |
| Permission and scope | Which files, systems and actions can it reach? | Security |
| Sandbox execution | What can it break if it gets it wrong? | Platform |
| Effectiveness test | Does the agent do better with it than without it? | Process owner |
| Maintenance and version | Who updates it when the model or the connector changes? | Skill owner |
The step that stalls programmes is the third. Reviewing means reading the content and, when the skill ships a script, the code and the dependencies. A skill in the Agent Skills format can package a script, a template and a dependency beyond the instruction text, and the runtime that loads it executes what came in the package with the agent's permissions. Reading does not scale like installing. One command takes seconds; reviewing a skill that touches a financial file consumes a meeting, and that meeting has no natural owner in any structure. When nobody convenes it, the programme moves forward with broad permission and zero review, which is the same as having no programme.
There are two questions that the table separates and that most teams merge into one: origin, who published the skill and under which namespace, and approval, who authorized that item inside here. Installing by name, without a pinned version, is a floating dependency, because what runs tomorrow may not be what was reviewed yesterday and the approval record keeps pointing at the old version.
Permission without scope is total access with a nice name. The post on agent permissions and traceability covers the design of that layer in detail, and the question it leaves behind is the one that matters here: can the skill read the file, or can it change the file, or can it send it outside?
Nexforce Work delivers that set as a desktop workspace for non technical teams, with a layer of approvals and permissions, sandbox execution, a skill manager, scheduled runs and MCP connectors. Nexforce Code brings the same discipline to the developer, with agents and subagents defined per project, rule files versioned alongside the code, skills and headless runs. The difference is where the decision is recorded: in Work, in the permissions layer; in Code, in the rule file that the repository versions. Neither of them decides, on behalf of the company, who approves.
The design of who approves what is in agent governance in production, and it does not arrive with the download.
The metric that should replace the install
The report projects, and projects is the word, that the quality of a skill comes to be measured by effectiveness instead of popularity: the skill is only justified if the agent does the work better with it than without it. Tests with that design are not yet installed practice. The projection points to where measurement should go.
The design of the test is simple to describe and expensive to run. A set of tasks, on the same model version and with the same permissions, each one executed with the skill loaded and without it, with repetition and with the outcome defined before the run, judged by the result and not by the elegance of the text produced. Two runs of a task do not separate effect from noise, because the difference between one round with the skill and one without may be nothing but model variance. The cost grows in proportion to the repetition, and that is why counting installs is cheaper than measuring effect.
While the measure is popularity, the counter does not distinguish the skill that improves the work from the one that merely lengthens the prompt. The distinction appears only when someone runs both versions and looks at the outcome. The post on agent evaluation beyond the final answer shows why evaluation has to look at the path, not only at the output.
The limit of the projection has to be clear: the report does not publish that benchmark, does not define the metric and does not measure any skill by effectiveness. It says the tests will come. A company that decides to adopt the criterion now will build it alone, with the tasks of its own operation, which is more work and more useful than waiting for a market standard.
What this changes in the decision to adopt agents in 2027
For whoever adopts agents, the decision stops being which catalogue to use and becomes who owns the artefact. A million available skills does not reduce the work of governing the skills the company chose, and it increases the surface that needs inventory, permission, test and version.
Three questions separate an agent programme from a pile of downloaded files. Which skills ran over which systems last quarter, with which permission and approved by whom. Who owns each one and what happens when that person leaves the company. And how you prove, with the task of your own operation, that the agent delivers more with the skill than without it.
None of them is answered in the catalogue. All of them are answered with a record of who approved and of what each run touched, and that record is the part nobody installs. Approval does not prove execution: a skill approved and never executed and another that ran outside the approved scope pass through the same stamp.
The list of what has to exist before the agent runs in production is in the production agent platform checklist.
Nexforce Agents develops and implements agents in B2B operations, and the two solutions of the unit exist so that a skill stops being a downloaded file and becomes an artefact with an owner, a version and a defined scope. The gain is not in the catalogue. It is in how many skills the company can keep working without anyone having to remember them.
Frequently asked questions
The four questions below appear in almost every adoption meeting, and all of them have the same root: a catalogue number being read as proof of a result. The answers stay inside what the report measures, without extrapolating to a market census that does not exist.
Is a million skills a sign of maturity in agent adoption?
No. The number measures what was published in a public catalogue, and the report itself records that nearly half of the catalogue was installed once. Maturity would show up somewhere else: skills with an owner, a version and an effectiveness test running over systems of record. The report measures none of that, and no public data measures corporate adoption of skills in Brazil.
Does an install count as corporate adoption?
It does not, and the report declares the limitation. Installs are aggregate counters of the catalogue, not unique people or independent choices, and they may be revised as the data improves. An install proves that someone ran an installation. It does not prove recurring use, a permission granted, an integration completed or a result.
Why does a generic skill not solve a specific operation?
Because it works in any company precisely by ignoring what is yours: the taxonomy of your documents, the threshold that triggers approval, the exception the team has applied for years. The report shows 87.5% of installs in work common to any sector and an average of 3.6 times more installs per listing in that band. The generic is the start of the work, not the end.
How do you measure whether a skill is worth it?
By comparing a set of tasks with and without the skill, on the same model version and with the same permissions, with repetition, and judging by the result of the task. That is the test the report projects as the next measure of quality, and it does not yet exist as a published standard. Until then, the decision stays with the process owner, who is the one who knows what a good outcome is.
References and further reading
Primary source for every number cited: the State of agent skills report, published by Vercel on 25 September 2026 and updated on the 30th of the same month, at https://vercel.com/blog/state-of-agent-skills. The comparisons of time to 1 million are also from the report. None of them went through independent audit.
Internal reading on what sustains the operation, linked in the body: agent permissions and traceability, agent governance in production, tool registry for agents, agent evaluation beyond the final answer, and the production agent platform checklist.
Where to start
The list of what already exists in your operation is the first artefact, and it does not depend on a vendor. Write down each installed skill, the owner, the pinned version and the permission granted, and mark the ones that touch a system of record. Three skills are enough for the first effectiveness test: the same task, with and without it, on the same model version. What passes becomes routine with a review date; what fails leaves the inventory before anyone opens a ticket.
The catalogue keeps growing at a pace no review can follow, and that is why the decision to adopt agents in 2027 runs through whoever signs the approval, not through which catalogue is in fashion. Three skills with an owner, a permission and a test deliver more than an entire catalogue installed once.

Deploy Work and Code Agentswith zero software licensing costs
Automate operational tasks and code writing autonomously with dedicated agents integrated into your systems
Free TrialRelated articles

Does the AI agent benchmark show that the harness changes the cost?
Ora's benchmark ran the same model in two agent harnesses and measured 7% fewer steps, 2x native success and about 15% lower total cost after fixing prompt caching. What to measure in your agent's cost.
Read more
AI agents in production: essential platform checklist
Before deploying AI agents in production, your platform requires 6 essential controls across execution, state, sandboxing, observability, and budget limits.
Read more
Agentic AI: The Complete Guide to AI Agents in the Enterprise
What agentic AI is, how it differs from traditional chatbots, the four pillars of the architecture, governance protocols, and how to implement autonomous agents in enterprise production.
Read more