You all know this, but just to recap: A skill is a folder with a text file in it. The file states what the job is, when to do it, and what a finished piece of work looks like. Anthropic published the format in October 2025 and released it as an open standard that December; Microsoft, OpenAI, Google and Cursor had adopted it within weeks1. Roughly a hundred tokens per skill sit in the model’s context at rest, enough for one general agent to know that dozens of jobs exist and to read the whole of a job only when that job arrives. Nice.
Weirdly, almost nobody in engineering is talking about that file - Skills.
The conversation is about agents: how to build them, orchestrate them, evaluate them, chain them. As usual, we in technology have spent a year describing the new technical workforce (agents - before we become theirs) and saying almost nothing about how their work is described. That same error got us into all sorts of trouble with micro-services. By the time we had finished patting ourselves on the back for this new architecture we suddenly realised that the description of those granular services often didn’t map to the job to be done.
Nobody adopts a platform. They adopt a way of doing a job. The reason skills spread faster than agents is not that they are more powerful. They are smaller. A skill is a description a competent person can write in an afternoon about work they already do, and the thing that reads it is often already installed - e.g. the harness you are using, which instructs its agents with your skills.
The name and description of every skill are loaded at startup; the body is read when the job is invoked; the scripts and reference files are opened only if the work reaches them. An organisation can hold a hundred descriptions of its own work in front of a general model for less context than one of them consumes once it is running. That is a different acquisition curve from agent building, and a different budget line.
The agents do the actual work. But the skill describes the work to be done.
The word agent has the answer inside it. From agere, to drive, to do: an agent is one who acts on behalf of a principal. There is no such thing as agency in the abstract; there is only agency conferred, bounded and instructed. Every serious debate about agents is a debate about the quality of the instruction, that seems to hide the instruction itself!
The model context protocol, the open standard by which a model reaches external tools and data, supplies a good example connection. MCP does not supply the procedural knowledge for using that connection well. Anthropic’s engineers reported a five-server configuration consuming around 55,000 tokens in tool definitions before the user had said anything, and a Google Drive to Salesforce workflow that fell from 150,000 tokens to 2,000 when it was rewritten as code the model called on demand rather than tools stuffed into its context.2. That is one illustrative case rather than a benchmark but the independent tests since have gone the same way. The lesson is not that tools are bad, it’s that they need context. In terms of the example above, they need to know when and what to ‘demand’…
Clayton Christensen, looking at product design, had a great insight. The critical unit of analysis, he realised, is the circumstance and not the customer.3
People do not buy a milkshake; they hire one for a long commute and a boring drive. The competition is a banana. His framework - Jobs To Be Done - is a lens for finding the job the buyer is already trying to do. When thinking about what we need to get AI to do, we need to think of our jobs to be done first… and then think about how to make the milkshake and what flavours it might have.
McKinsey’s 2026 global survey found eighty per cent of respondents reporting that AI had improved their own productivity, while the share reporting any EBIT impact at all sat at thirty-seven per cent, essentially unchanged from a year before4. The organisations getting financial return were the ones that had redesigned the work rather than inserting AI into work as it stood: nearly three-quarters of high performers against a quarter of everyone else.
The year before, the same research put the proportion scaling agents in any given business function at no more than ten per cent. The much-quoted MIT finding that ninety-five per cent of enterprise generative AI pilots return nothing is preliminary and contested on its method, and the reason its authors give still holds up against everything beside it: the failures are not model failures, they are a learning gap, brittle workflows and misalignment with, you guessed it, the jobs to be done.
Where agents do belong, they belong small. Ten steps at ninety per cent reliability each succeed about a third of the time; at eighty-five per cent, a fifth. The arithmetic is the whole of the production problem with long autonomous chains, and no amount of enthusiasm alters it. What raises reliability in deployed systems, on the evidence published so far, is structure around the model rather than a better verification step at the end. Skills can be used for scoping, routing and handoffs between specialists whose work can be checked.
OWASP’s 2026 top ten for agentic applications puts it in one line every architect should steal: autonomy is a feature to be earned, not a default setting6. Obviously, least agency sits beside least privilege. An agent should be scoped to a singular task, carry short-lived credentials for that task, run inside a sandbox with an egress allow list, and be registered somewhere a human can find it. Engineers build that today. A business analyst does not. But in my view, they do so together in small pods - working with each other and iterating on getting the match between the job to be done and its granularity of execution right.
A caveat exists though. Rich Sutton’s7 view is that hand-built structure loses to general method plus scale, again and again, over decades. Applied here it says skills are a kind of scaffolding, and scaffolding is what the next model absorbs. The people building the harness, the program that holds the model and decides what it can see and call, say this openly: bet on the model, not on the wrapper; build the feature even though you will delete it in three months. Lance Martin at LangChain watched his own multi-agent research structure become the bottleneck as models improved, and warned that abstractions are dangerous precisely because they make structure hard to remove8. One comparison on a hard agent benchmark found that swapping the model moved pass rates roughly three times as far as swapping the harness. If you are betting on anything other than raw capability, the last five years say you lose.
This kills a particular kind of skill: the one that tells the model how to do something it could work out - NOT the job to be done in your company. Maybe a model can infer how to draft a payment message based on pervasive message standards like Swift, PSD2 etc. But it cannot infer that your bank changed it’s tolerance for anti money laundering and that a new process exists for vetting certain kinds of transactions.
That is not scaffolding around the model. That is the precise well formed requirement, and the requirement has always been the scarce artefact in enterprise software. More so, managing its evolution over time…
It’s not all rosy for the skills though. Business users authoring their own automation is a prediction that has failed three times. Spreadsheets, then low code, then robotic process automation: one survey of citizen development put fifty-four per cent of projects down as failures inside a year and fewer than one in five as clear successes, and the failure modes were ungoverned logic, no engineering involvement and a silo per tool9. A hammer does not make a carpenter.
Skills also come with a new attack surface. Snyk’s study of one public skills marketplace this year found prompt injection in thirty-six per cent of a sampled set and over a thousand malicious payloads, in a market where daily publishing had grown roughly tenfold in three weeks10 .A markdown file that instructs an agent holding your credentials is exactly what Simon Willison calls the lethal trifecta: private data, untrusted content, and a way out.
These are arguments about what a skill is. Treat it as a personal macro downloaded off the internet and you have built the worst of low code with a credential attached. Treat it as a governed description of how this organisation does a piece of its work, held in a registry, reviewed like code, versioned, owned by a named person and executed under least agency, and you have something the citizen developer wave never had: one artefact that is simultaneously the requirement, the documentation and the running instruction.
Ask what your AI programme has produced this year and maybe you will be shown a list (or demo?) of agents, a platform diagram and a count of pilots. Ask for the list of jobs and there often isn’t one.
An organisation that can describe its work can buy any model and swap it next quarter. An organisation that cannot will keep building agents that do something nobody asked for, faster and at greater expense, and will call the result a capability.
As professionals in this space, we need to get back to talking about the jobs to be done, enabling our users to define them using skills, and building processes and tests that make that safe and easy for the new kinds of builders we are about to unleash.