What is context engineering?
Context engineering is the practice of deciding which information loads into an AI model's context window, when it loads, and what stays out until actually needed. Anthropic has published formal guidance titled "The new rules of context engineering for Claude 5 generation models," establishing context engineering as a defined discipline distinct from prompt writing or retrieval optimization. The fix for context bloat is not smarter retrieval. It is deliberate architectural control over what enters the window and when.
TL;DR: Progressive disclosure, a context engineering technique where detailed tool instructions load only at invocation rather than upfront, outperforms always-in-context RAG for tool and skill library design. Claude's Skills format embodies this pattern, keeping baseline context lean and injecting full guidance on demand. This deferred loading preserves attention capacity, reduces noise, and scales cleanly as skill libraries grow.
Key Takeaways
- Context engineering is its own discipline: loading the right information at the right moment is a deliberate architectural decision, not a side effect of writing better prompts.
- Progressive disclosure defers instruction loading: Skills load full instructions only at invocation; everything else stays out until needed.
- RAG retrieves chunks; Skills load full instructions: RAG surfaces text fragments; Skills deliver complete, self-contained operating instructions at task start.
- Context window bloat is a design failure: packing unused tool instructions into every session wastes token budget and degrades long-running agent performance.
- Modular skill libraries change how teams build: invocation-bounded skills can be added, updated, or swapped without rewriting the entire system prompt.
- The community has already voted: Agent Skills repositories for Claude Code attracted roughly 2,300 GitHub stars within a week of release.
What exactly is progressive disclosure as a context engineering technique?
Progressive disclosure loads a tool's full instructions into the context window only at invocation, keeping everything else out until it is needed.
The invocation boundary is the core idea. A skill sits dormant until the orchestrating agent calls it; at that moment its full instruction set enters the window, and when the task ends, it exits. Always-in-context loading does the opposite, consuming token budget upfront on content that may never be used in a given session. The gap between these two approaches compounds as tool libraries grow larger and sessions run longer.
How does the Claude Skills format implement deferred instruction loading differently from RAG retrieval?
Claude Skills package each capability as a self-contained, invocation-triggered instruction block, whereas RAG retrieves fragmented chunks the model must interpret and assemble at inference time.
A RAG pipeline runs: query, then embedding search, then top-k chunk retrieval, then fragments injected, then the model interprets. A Skills pipeline runs: agent identifies task, invokes named skill, complete operating instructions load, model executes against a coherent specification. These are not variations on the same process.
RAG surfaces evidence; Skills deliver instructions. A RAG chunk might tell the model a tool exists, while a skill tells the model exactly how to use it, what parameters matter, what edge cases to handle, and what success looks like, authored once and loaded precisely.
Table 1: Progressive Disclosure vs. Always-in-Context RAG, Six Dimensions
| Dimension | Always-in-Context RAG | Progressive Disclosure (Skills) |
|---|---|---|
| When instructions load | Session start (always) | Invocation time (on-demand) |
| Information type | Retrieved text fragments | Complete instruction blocks |
| Token cost | Paid upfront, every session | Paid only when capability is used |
| Authoring requirement | Chunking and embedding pipeline | Self-contained skill definition |
| Modularity | Low (retrieval-dependent) | High (invocation-bounded) |
| Update surface | Re-embedding required | Edit single skill file |
What does context window bloat reveal about the actual quality of your tool library design?
Context window bloat is almost always a symptom of tool instructions that were never designed to be modular, and progressive disclosure forces teams to confront that design debt immediately.
The leverage in context engineering is not only in what goes into the window but in what gets deliberately kept out. When teams attempt to implement deferred loading, they frequently hit a consistent wall: their instructions were never modular enough to defer in the first place.
Consider, as a practical illustration, a code review agent whose "security scan" instructions reference variables set by "dependency check." Two capabilities, secretly coupled: extracting either breaks the other. That is not a retrieval problem; it is an architecture problem. Teams wrote prompts, not specifications, designed to be read once in order rather than loaded on demand. If a tool's instructions cannot be isolated into a self-contained block, better retrieval will not fix it.
How should teams redesign their tool libraries around invocation-bounded skills?
Audit each capability for hidden dependencies, rewrite each as a self-contained specification that assumes zero prior context, and define an explicit invocation contract.
The following three-move sequence is a practical rule of thumb for moving from a monolithic prompt to a modular agent tool library:
1. The dependency audit List every instruction and ask: does this reference anything outside itself? If yes, it is coupled. Name the coupling explicitly before attempting to resolve it.
2. The self-containment rewrite Rewrite each capability assuming it loads into a cold context with no session history. It needs to include what the skill does, what inputs it expects, what decisions it owns, and what done looks like. If the rewrite requires more than one document, there are likely two skills pretending to be one; split them.
3. The invocation contract Define the trigger condition for each skill. A skill without a clear trigger either never loads, creating a missing capability, or always loads, which defeats deferred loading entirely. The contract makes invocation deterministic.
Frequently Asked Questions
What is the difference between RAG retrieval and progressive disclosure in context engineering? RAG retrieves relevant text chunks at query time; progressive disclosure defers loading an entire skill's instructions until that capability is invoked. RAG answers "what do I know about this?" Skills answer "how exactly do I execute this task right now?"
How do Claude Skills load instructions only when invoked rather than at session start? Each skill packages its full instructions as a self-contained block. The orchestrator holds a registry of available skills but loads a skill's instructions into active context only when the agent determines that skill is needed for the current task.
What architectural changes do teams need when moving from RAG pipelines to Skills-based context engineering? Audit existing tool instructions for hidden dependencies, rewrite each as a self-contained specification assuming no prior context, and define explicit invocation contracts. The shift is less about tooling and more about writing instructions as machine-loadable specifications rather than human-readable prose.
How does progressive disclosure improve token efficiency in long-running agent sessions? By loading skill instructions only at invocation, agents pay context costs proportional to the capabilities actually used in a session rather than the full size of the tool library. That gap widens as sessions grow longer and libraries grow larger.
Conclusion
Context engineering is not about getting more into the window. It is about being deliberate about what stays out. RAG is the right tool for knowledge retrieval; Skills-based progressive disclosure solves something different, delivering complete capability instructions exactly when needed and nowhere else. Anthropic's formal guidance, has made this a codified practice for the Claude 5 generation.
The 2,300-star reception for Agent Skills repositories confirms that practitioners are already building around this model in production.
The uncomfortable discovery most teams will make is that their problem was never retrieval quality. Their instructions were written as prose, not specifications.
Pick one tool from your current agent's system prompt and try to rewrite it as a self-contained, invocation-bounded skill. If it cannot be isolated cleanly, you have found the real architectural problem.
Learn from me
Claude Code in Practice, my Maven cohort. Master Claude Code from fundamentals to advanced orchestration: skills, subagents, hooks, MCP, and production automation. Join the next cohort →
Hire us
Traversaal.ai. We're a team of forward deployed engineers solving the toughest AI problems for Fortune 100 companies: document intelligence, agentic data platforms, and real-time web intelligence, deployed in production. Work with our team to deploy your next agentic ecosystem. Talk to Traversaal.ai →
Join us
Want to solve these problems with us? We're always looking for forward deployed engineers who want to ship production AI. jobs@traversaal.ai
