Blog ·
How to reduce active skills in your agent — without shrinking your library
The trick is progressive disclosure: preload only a small set of favourite skills into the agent’s context, and keep the rest of your big library one search away — loaded on demand. You get a tiny “active” footprint (which keeps the agent sharp) and an unlimited catalogue (which keeps it capable). You don’t have to choose between “few skills” and “many skills.”
Why “just add everything” backfires
Loading a lot of tools/skills up front actively degrades agents. The evidence is consistent:
- Accuracy falls off a cliff past ~20 active tools. It’s not a gentle slope — selection quality drops sharply once the list gets long (EclipseSource).
- Definitions eat the context window before you type. A standard handful of MCP servers can consume 20–30% of the context window on tool definitions alone (Junia).
- “Context rot.” As the prompt fills with options, the model gets “lost in the middle,” ignores instructions, over- or under-calls tools, and generally seems dumber mid-task (kvg.dev).
More skills loaded ≠ more capable. Past a point, it’s the opposite.
But you still want a big library
The answer isn’t to keep only a few skills total. Your organization has dozens or hundreds of legitimate procedures — deploys, reports, CRM workflows, doc generation. You want all of them available; you just don’t want all of them resident in the prompt at once.
The pattern: preload favourites, search the rest
Agent skills are self-describing and load on demand, which makes this clean:
- Preload a short favourites list. Only your starred skills (and team-enforced ones) go into context at session start — a handful of names + one-line descriptions, not full bodies.
- Discover the rest on demand. When a task needs something else, the agent searches the library and loads just that skill’s content — then it’s gone again.
- Bodies load only when used. A 100-skill library costs almost nothing in context until a specific skill is actually pulled in.
How to set it up
With a governed skill library this is just configuration:
- Favourites = the active set. Star the few skills each person uses constantly. Those are preloaded; everything else stays searchable.
- Team-enforced favourites. Admins can star a skill for a whole team, so the right defaults are active for everyone without bloating the list.
- Scoped tokens. A connection can be scoped to a subset of skills, so a given agent only ever sees what’s relevant to its job.
- On-demand load. The full catalogue is reachable via search; the agent reads a skill’s instructions only when it picks it.
The result
| Everything loaded | Favourites + on-demand | |
|---|---|---|
| Skills available | Many | Many (whole library) |
| In context at start | All definitions (heavy) | A few favourites (light) |
| Selection accuracy | Degrades past ~20 | Stays high |
| Context spent before work | 20–30%+ | Minimal |
Related: why skills, not just MCP, managing skills across your org, and enforcing favourite-loading so the active set is always present.
Keep a huge library, stay sharp. Start free and preload only what matters.
Last updated: June 9, 2026