Agent Skills Over Prompts: Package Procedures So Agents Load Only What the Task Needs

Somewhere around the fourth incident postmortem, every agent team writes the same sentence into the system prompt: "ALWAYS verify the customer's plan tier before issuing a refund." Then another incident, another sentence. Eighteen months later the prompt is 9,000 tokens of accumulated scar tissue, the agent follows maybe 70% of it on any given run, and someone in a planning meeting proposes splitting the whole thing into five specialized agents. That proposal is usually a mistake. The problem is rarely that one agent cannot do the work. The problem is that the agent is forced to read the entire employee handbook before answering every ticket.

There is a better primitive for this, and in 2026 it has become boringly standard: the skill. A skill is a procedure packaged as a versioned folder that the agent loads only when the task calls for it. Getting this right is less glamorous than multi-agent orchestration and delivers more.

The evidence against the giant system prompt

The failure mode is well documented at this point, and it shows up in two places: tool selection and instruction following.

On tool selection, the numbers are stark. The RAG-MCP study stress-tested models against growing pools of MCP tool definitions and found selection accuracy collapsing as the pool grew, with prompt bloat as the direct cause. Retrieving only the relevant tool definitions instead of injecting all of them more than tripled selection accuracy in their benchmark, from roughly 14% to 43%. The Berkeley Function Calling Leaderboard shows the same shape in its multi-tool scenarios: models that look excellent choosing among five functions get noticeably worse choosing among fifty. We covered the tool side of this in our post on tool selection under MCP, and the instruction side behaves the same way.

On instruction following, Chroma's context rot research measured 18 models on tasks that stayed constant while input length grew, and found performance degrading with length even when the task was trivially simple. The older Lost in the Middle result explains part of the mechanism: models attend most reliably to the beginning and end of context, so instruction number 47 of 80, buried mid-prompt, is exactly the one your agent will skip.

Put those together and the picture is clear. Every procedure you add to an always-on prompt makes every other procedure slightly less reliable, whether or not the current task touches it. Your refund policy is degrading your shipping-label workflow. The teams hitting a quality ceiling around the 8,000-token system prompt are not hitting a model capability limit. They are hitting an instruction-loading limit.

What a skill actually is

Strip away the branding and a skill is three things: a folder, a trigger, and a payload.

Anthropic's engineering write-up on Agent Skills describes the structure that most runtimes have now converged on. A skill folder contains a SKILL.md file whose YAML frontmatter holds a name and a one-or-two-sentence description. That metadata, a few dozen tokens, is the only part that stays resident in the agent's context. The body of the file, which can run to thousands of words of procedure, loads only when the agent decides the current task matches the description. The folder can also hold additional reference files and executable scripts that load or run only when the procedure calls for them.

This is progressive disclosure, and it works in three levels:

The economics of that table are the whole argument. An agent with forty packaged procedures carries perhaps 2,500 tokens of skill index at rest. The same procedures inlined into a system prompt would cost 80,000 tokens on every single request, degrade every response, and blow past most context budgets before the conversation starts. Google Cloud's overview of agent skills makes the same point from the enterprise side: skills are how organizational knowledge gets attached to agents without being permanently loaded into them.

One detail that surprises people: the payload does not have to be instructions for the model to read. A skill can bundle a script the agent executes directly. If your invoice-formatting procedure is deterministic, the skill should contain a script that does it, and the instructions should just say to run it. Tokens spent making a language model imitate awk are wasted twice, once in cost and once in reliability.

The Model Context Protocol sits adjacent to all this and gets confused with it, so it is worth drawing the line. MCP standardizes how agents connect to tools and data, the verbs available to the agent. Skills standardize procedural knowledge, how and when to use those verbs for a specific business outcome. A well-built agent has a short list of MCP servers and a longer library of skills that reference them.

One skill per business procedure, with an owner and an eval set

Here is where most skill adoption goes wrong. Teams treat skills as a context-window optimization, chop their system prompt into files along arbitrary seams, and end up with the same mess distributed across a directory tree. The unit of packaging matters more than the mechanism.

The unit that works is the business procedure. "Process a refund request." "Triage an inbound RFP." "Generate the weekly pipeline report." Each of these gets one skill, and each skill gets three things a paragraph in a system prompt can never have:

• A version history. The skill lives in git. When refund behavior changes on a Tuesday, you can diff the skill and find the Tuesday commit. When it regresses, you can revert it without touching any other procedure.
• An owner. The person accountable for the refund process owns the refund skill, the way a service owner owns a microservice. Prompt paragraphs have no owner, which is why nobody ever deletes the stale ones and every prompt only grows.
• An eval set. A dozen or two representative cases with expected outcomes, run whenever the skill changes. This is the part that converts skills from "organized prompts" into testable software. You would not merge a code change without tests; a skill edit is a behavior change to a production system and deserves the same gate.

This structure also fixes an organizational problem that has nothing to do with tokens. In the monolithic-prompt world, every procedure change is a change to the one shared artifact, so every edit needs review from everyone and most edits just don't happen. With one skill per procedure, the finance team can iterate on the expense-audit skill weekly while the support skills sit untouched, and neither team's evals run against the other's changes. The blast radius of an edit shrinks from "the whole agent" to "one procedure."

The optimization loop follows naturally. Production transcripts where a skill fired but the outcome was wrong become new eval cases. The owner adjusts the procedure, the evals confirm the fix and catch regressions, and the skill improves along exactly the axis it failed on. Research groups have started automating this loop, with self-improving skill pipelines that rewrite procedure files based on outcome feedback, but you do not need automation to start. A human owner reviewing failures weekly gets you most of the value.

If the procedure cannot be written down crisply enough to package, that is a finding too. Skills are a forcing function for process documentation, and roughly a third of the value of building a skill library is discovering which of your "standard" procedures were never standard.

The multi-agent detour you can skip

The most expensive consequence of the giant-prompt ceiling is architectural. A team watches quality degrade as instructions accumulate, correctly diagnoses that the agent is drowning in context, and then reaches for the heaviest available fix: split into specialized agents, each with its own smaller prompt, coordinated by an orchestrator.

Sometimes that is right. We have written about where subagent boundaries genuinely earn their keep, and the honest cases involve parallelism or hard context isolation. But look at what the typical prompt-overflow-driven split buys you. Each specialist agent is the same model with a subset of the instructions loaded. The orchestrator's job is deciding which subset applies to the current task. That is a routing decision over instruction sets, and it is exactly what skill metadata plus progressive disclosure already does, without the new failure modes multi-agent brings: lossy handoffs between agents, state that must be serialized and passed around, doubled latency, and an orchestrator prompt that starts accumulating its own scar tissue.

A single agent with forty skills gets you the specialist behavior, one procedure loaded at a time against a clean context, while keeping one conversation state, one audit trail, and one deployment. The agent patterns in the Anthropic cookbook point the same direction: the published examples get their capability range from what the agent can load and execute, not from how many agents are in the room.

The test worth applying before any multi-agent proposal: would this split still make sense if instruction loading were free and perfectly reliable? If the answer is no, you are buying a distributed system to fix a packaging problem.

Migrating an overgrown prompt into skills

The migration is less work than teams expect because the prompt has already done the hard part of writing the procedures down. A sequence that works:

1. Inventory the prompt. Tag every paragraph as identity (who the agent is, tone, hard safety rules), procedure (how to do a specific task), or reference (product details, policy tables). Most 8,000-token prompts are 500 tokens of identity and 7,500 tokens of procedure and reference.
2. Keep only identity resident. Hard constraints that must hold on every turn stay in the system prompt. A rule that only matters during refunds is not a global rule, however nervous the last incident made everyone.
3. Extract procedures one at a time, highest-traffic first. Move each into a skill folder, write the trigger description carefully (it is the only thing the model sees at rest, so it should say when to use the skill, not just what it is), and demote bulky reference material to level-three files.
4. Build the eval set before the first edit. Pull 15-25 real transcripts per procedure from production. Baseline the skill against them so the first "improvement" has something to be measured against.
5. Watch trigger precision for two weeks. The new failure mode skills introduce is misfire: the wrong skill loading, or none. Log which skills fire on which requests. Misfires are almost always fixable in the description text, and they are far cheaper to fix than the mid-prompt instruction skips they replace.

Expect the first pass to take a week or two for a mature agent, most of it spent on eval sets, and expect the resident context to shrink by 60-80%.

Where this lands in a production build

OpenNash builds this structure into client agents by default now, because the alternative has a predictable lifecycle: the prompt grows, quality erodes, and eighteen months in the team is scoping a multi-agent rewrite to escape a problem that packaging would have prevented. In an engagement, the audit phase surfaces the procedures worth packaging, the design phase sets skill boundaries, owners, and the approval points where a human must sign off, and the handoff leaves the client with a skill library in their own repo, eval suites wired into CI, and the ability to edit a procedure without calling us. Skills make that ownership handoff real: a client operations lead can safely change a refund threshold in a Markdown file with tests behind it, which is not something you can say about a 9,000-token prompt.

To be fair about the boundaries: if your agent has fewer than a handful of procedures, a single well-edited prompt is fine and this machinery is overhead. If your procedures change hourly or live primarily in a platform vendor's config UI, adopt that vendor's native skill mechanism rather than building your own loader. The custom path pays off when procedures are numerous, owned by different teams, and need audit trails.

If you want to gauge the gap in your own system, book a call and bring your current system prompt. Working through the inventory in step one against a live prompt takes about thirty minutes and tells you precisely how much of your agent's context budget is being spent on procedures the current task will never touch.

Either way, run the inventory this week. Count the tokens in your system prompt that a typical request never uses. That number is the size of the tax you are paying on every call, and it is the strongest argument you will find for moving procedures into skills before you add a second agent.