The Skill Is the Unit of Work

There is a moment in every agent programme, usually somewhere between month four and month seven, when the numbers stop making sense. The team has done everything the guides recommend. It connected the warehouse. It wrapped the ticketing system. It added the pricing service, the entitlement lookup, the document store, the calendar, the internal search. The tool count on the slide has gone from six to sixty, and the slide looks like progress. Then someone plots resolution rate against tool count and finds that the line bends the wrong way.

This surprises people because it contradicts an intuition that works everywhere else in software. More capability normally means more coverage. In agentic systems it means more choices per step, more descriptions competing for attention, more plausible-but-wrong paths through the same request, and more ways to be confidently incorrect. Sixty tools is not a richer environment. It is a harder exam with the same amount of study time.

The deeper problem is a category error. A tool is a capability: run this query, open this ticket, send this message. A business does not run on capabilities. It runs on procedures — the quarter-end revenue check, the escalation path for a data-quality incident, the way a refund above a threshold gets approved, the sequence a new region follows before its numbers are trusted. A procedure has an order, a set of allowed sources, a definition of done, and a person whose name is attached to it. None of that fits inside a function signature.

So the useful unit is not the tool. It is the skill: a written, named, owned, versioned description of how a specific job is done here. Tools are the verbs. Skills are the work. This essay is about treating the second one as an engineering artefact, because that is where reliability, portability, and most of the leverage actually live. Chapter 13Chapter 13 · 6 min LockedGovernance Was Built for Humans. Agents Need More.Access control is not action control. sets out the anatomy of an agentic system and why the instruction layer, not the model, is the part that carries your organisation's specificity.

Strip away the tooling debate and a skill is a short document with five parts. It is worth being pedantic about them, because teams that skip any one of the five end up with prompt fragments in a shared drive rather than an asset.

The first part is the trigger: when this skill applies, and just as importantly when it does not. Most bad agent behaviour is not bad reasoning inside a procedure, it is the wrong procedure selected for the request. A trigger written in the language of the business — the final five business days of the quarter, a ticket tagged as a billing dispute above a threshold — does more for reliability than another round of prompt tuning.

The second part is the sequence: the ordered steps a competent colleague would follow, including the checks that are easy to skip. This is the part experts find tedious to write, because they perform it without thinking. It is also the part that carries the value, since it is precisely the knowledge that has never been written down anywhere in the company.

The third part is the permitted surface: which tools this skill may use, at what scope, and which it may not. A skill that can only touch three tools is a smaller exam than one that can touch sixty, and the narrowing is what recovers accuracy. The fourth part is the sources of truth: the certified table, the current policy document, the definition that governs the term. The fifth part is the definition of done, stated so a machine can check it — the fields that must be populated, the citation that must be present, the reconciliation that must balance.

Add two pieces of metadata and the document becomes an artefact rather than a note: an owner, and a version. Everything in Chapter 15Chapter 15 · 6 min LockedGuardrails, Approvals, and Audit TrailsDesigning safe agent behavior in practice. about the control surface reduces, in practice, to those two fields being real. Chapter 4Chapter 4 · 7 min LockedThe 4 C's FrameworkA simple lens for designing trusted enterprise AI. makes the same argument on the meaning side: an instruction that references an undefined term inherits the ambiguity of the term.

The first objection is reasonable: this is just a system prompt with better hygiene. It is not, and the difference is structural rather than stylistic.

A system prompt is loaded for every request, which means every instruction competes with every other instruction for the model's attention on every single call. A skill is retrieved for the requests it applies to. That is the difference between one exhausting document that contains the union of everything the agent might ever need, and a small, specific document that contains what this job needs now. Attention is a budget, and the union spends it on irrelevance.

A system prompt also has no unit of change. When six teams contribute to one prompt, nobody can safely edit it, because there is no way to know which line another team depends on. A skill has a boundary, so it has an owner, a diff, a test, and a rollback. That is the whole argument for modularity, arriving in a new domain about forty years late.

Then there is the cost dimension, which is usually what moves the conversation with finance. Loading everything on every call inflates the input on requests that never needed it, and input tokens are the quiet majority of most agent bills. Retrieving one skill on demand keeps the working set small, and a small working set is both cheaper and more accurate — the rare case where the frugal option is also the correct one. Chapter 36Chapter 36 · 10 min LockedCompaction and the Token BudgetBudget tokens like money, compact history without dropping commitments, and detect degradation before a user does. covers compaction and the token budget in detail, and Chapter 18Chapter 18 · 6 min LockedThe Hidden Cost of Agentic AIWhere the dollars actually go. covers where agentic spend actually accumulates.

Finally, a prompt is a wall of text and a skill is a folder. Folders can carry things text cannot: a worked example, a query template, a checklist, a small script that performs the deterministic part rather than asking a language model to reason its way to arithmetic. That last move is underrated. Any step in a procedure that can be code should be code, and the skill is the natural place to keep it next to the instructions that call it.

The obvious worry about a skill library is that it becomes the thing it replaced. Two hundred skills cannot all be loaded, so a naive implementation reproduces tool sprawl with longer documents.

The answer is progressive disclosure, and it is a three-level pattern that any team can implement this quarter. Level one is the index: for every skill, a name and a one-line trigger, nothing more. Two hundred skills at twenty tokens each is a rounding error, and it is enough for the agent to decide which door to open. Level two is the skill body: retrieved only for the selected skill, containing the sequence, the permitted surface, and the definition of done. Level three is the attachments: the query template, the reference table, the long policy extract, each pulled only at the step that needs it.

This mirrors how a competent new joiner behaves. They do not memorise the operations manual. They remember that a manual exists, they know roughly where the chapter on quarter-end lives, and they open it when the quarter ends. The system that behaves this way is not a weaker system for holding less in mind. It is a better one, because everything it does hold is relevant.

There is an important discipline attached: the index is a product surface and it has to be curated. Two skills with overlapping triggers will be selected at random, which is the single most common failure in a young library. Triggers must be mutually exclusive, and when two genuinely overlap, the correct fix is one skill with a branch rather than two skills with a coin toss. Chapter 35Chapter 35 · 11 min LockedRetrieval Mechanics: Chunking, Hybrid Search, and RerankingThe engineering layer under every context strategy — chunking, hybrid search, reranking, and how to prove it works. covers the retrieval mechanics that make selection reliable, and Chapter 10Chapter 10 · 9 min LockedInstitutional Memory Is the MoatAs frontier models converge, the durable advantage is the accumulated why — decisions, definition history, and organizational logic. covers why institutional memory has to be indexed to be usable at all.

A skill library decays faster than code, because code fails loudly when its assumptions break and a skill simply keeps producing plausible output against a rule that changed in April.

So the governance is not optional overhead, it is the thing that keeps the asset an asset. Four practices carry most of the weight. Every skill has a named human owner, not a team alias — the person who would be asked in a review whether this is still how the work is done. Every skill has a version and a changelog, so a regression can be traced to a change rather than blamed on the model. Every skill has a review date, because a procedure tied to a pricing policy or a regulatory threshold is only true until that policy moves. And every skill records the incidents it was written in response to, which is how a library accumulates judgement rather than just instructions.

This is the same argument made in the agent org chart about named humans behind every piece of context, applied to the procedural layer. It also connects to something more strategic. Skills are the most portable form of institutional knowledge you will ever build: they are text, they belong to you, and they move to a new model or a new platform intact. A prompt tuned into one vendor's orchestration syntax does not travel. A written procedure does. Chapter 12Chapter 12 · 7 min LockedPortable Context: The Open Contract for AgentsContext is your IP — it must move across agents, models, and clouds through an open contract, not sit locked inside one runtime. makes the portability case, and Chapter 34Chapter 34 · 7 min LockedDesigning Multi-Agent Systems That Actually WorkWhen one agent is not enough — and how to make many cooperate without chaos. explains why optionality of this kind is architecture rather than procurement.

One warning from the field. The temptation is to generate the first hundred skills with a model, from documentation. The output reads well and encodes the documentation's assumptions rather than the organisation's practice, which is exactly the gap that makes enterprise agents fail. Generate the draft if you like, but the sequence and the definition of done have to be corrected by the person who does the work. That correction is the intellectual property. Chapter 11Chapter 11 · 7 min LockedContext Is a Living Layer, Not a DocumentDefinitions drift, macro conditions shift, agents relearn — treat context like code, with ownership, versioning, and continuous review. covers why a context layer that nobody reviews stops being a context layer.

A skill is a testable object, which is the main practical reason to prefer it over prose. Three questions define the tests, and all three can be answered in a pipeline.

Was the right skill selected? Take a set of real requests, label the skill a human expert would have used, and measure selection accuracy. This is the cheapest measurement in the entire stack and it catches the trigger collisions described above before they reach anyone.

Was the sequence followed? Score the trace, not the prose: did the required checks run, in order, against the permitted tools and the named sources? A procedure that reached a correct-looking answer while skipping the reconciliation step has not succeeded, it has been lucky, and luck does not survive a quarter.

Did the definition of done hold? Check the fields, the citation, the balance, the scope of the action taken. Deterministic checks first, judge models last — the same discipline set out in the evaluation gap and in Chapter 17Chapter 17 · 6 min LockedHuman in the Loop Still MattersWhen humans should approve, review, or fully own the decision., which treats evaluation as core infrastructure rather than a testing afterthought.

One more measurement that teams rarely take and always benefit from: the working set size per request. If the average request loads forty thousand tokens of instruction to perform a job a colleague would do from a one-page checklist, the library is not doing its job. Watch that number fall as the skills get sharper. It is the clearest available signal that the design is improving rather than merely growing.

It is worth being explicit about the mechanism, because the result looks like a paradox: a system that is allowed to do less becomes more useful.

Every step an agent takes is a decision under uncertainty, and the number of plausible wrong moves grows with the size of the choice set. A skill collapses that set. At the moment of execution the agent is not choosing among sixty tools and every possible order of operations. It is choosing among four permitted tools in a stated sequence, with named sources and a checkable finish line. Same model, same underlying systems, dramatically smaller space of ways to fail.

This is also why skills interact so well with smaller and cheaper models, which is the argument in small models, big context. A large fraction of the frontier-model premium in enterprise workloads is paid for figuring out procedure from insufficient instruction. Write the procedure down and much of that premium becomes optional. Chapter 19Chapter 19 · 6 min LockedNot Every Task Needs the Best ModelRouting, cascades, and right-sized intelligence. covers routing work to the cheapest model that can hold the standard, and a good skill is what makes that standard explicit enough to route against.

The final benefit is organisational rather than technical. Once procedures are written objects with owners, the conversation about AI stops being about model selection and starts being about how the company works. That conversation is uncomfortable in the first month and compounding thereafter, because the artefacts it produces are useful even in the parts of the business no agent touches yet. Chapter 22Chapter 22 · 5 min LockedThe Danger of AI Lock-InHow yesterday's choices limit tomorrow's options. and Chapter 26Chapter 26 · 6 min LockedThe Agentic Data ProfessionalHow your role evolves in the next five years. cover the operating model and the roles that carry it.

The failure pattern for this idea is a six-month cataloguing project that produces a beautiful library nobody uses. The successful pattern is narrow and fast.

Pick three procedures that are frequent, painful, and already contested — the ones where two people give different answers and both sound right. Frequency gives you data within a fortnight, pain gives you an owner who will actually review the draft, and contested definitions force the meaning work that would otherwise be deferred forever.

Write each one with the five parts and the two metadata fields. Restrict each skill to the smallest tool surface that can complete it. Build twenty labelled examples per skill from real requests, and measure selection accuracy, sequence adherence, and definition of done. Then run for two weeks and route every human correction back into the skill as a new example or a changed step.

At the end of a month you will not have an AI transformation. You will have three procedures that work, an instrument that tells you when they stop working, and a template the next team can copy. That is a considerably better position than sixty tools and a bending line, and it is the position from which every durable version of this programme has been built.