A latticework reading of Anthropic Engineering's Agent Skills — how progressive disclosure and the onboarding-guide metaphor reshape our understanding of capability, specialisation, and composable AI.
Illustration: Anthropic Engineering · Oct 2025
The fundamental question in deploying an AI agent is not "what model should I use?" It is "how do I give the model the knowledge it needs, only when it needs it?" Anthropic's Agent Skills post answers that question with a format so simple it is easy to underestimate: a directory, a markdown file, and a principle. The principle is progressive disclosure. The format is a skill.
A skill is an organised folder that an agent can load dynamically. At startup, it reads the name and description of every installed skill — just enough to know when each is relevant. When a skill is triggered, the agent reads its full SKILL.md. If deeper detail is needed, linked files are there. Three levels, loaded on demand. The post frames this as a response to a specific scaling problem: as agents become more capable, giving them everything they need via a monolithic system prompt becomes untenable. Skills are the architecture that replaces the monolith.
Three latticework edits follow. Some existing models come out sharper — composability, abstraction layers, progressive disclosure. Others get quietly contradicted or bent — the assumption that specialisation requires different models, the idea that code and prose are categorically different artifacts. And a small set of new structural observations earns a place in the toolkit.
Composability is the clearest amplification. The design principle that a system built from independent, interchangeable components is more robust and adaptable than a monolithic equivalent gets a precise realisation in skills. Each skill is a self-contained unit of expertise. You can add a new skill without touching the harness; you can share a skill across projects; you can retire a skill without breaking others. The unit of composition is not a tool call or a prompt fragment — it is a named, versioned folder of knowledge.
Abstraction layers get a fresh illustration, particularly the principle that the right abstraction boundary is where things change at different rates. The harness — the core execution loop — changes slowly. The skill content changes often, in response to what agents actually do in practice. Keeping them separate means the fast-changing layer (the knowledge) can be updated without touching the slow-changing layer (the loop). The skill format is essentially a formalisation of this boundary.
Progressive disclosure is the most elaborated model in the post. Like a good manual — table of contents, then chapters, then appendices — skills reveal information only as it becomes relevant. The first level is a name and description in the system prompt. The second level is the full SKILL.md body. The third level and beyond consists of linked files, loaded only when the agent navigates to them. This is context engineering as architectural principle, not as prompt-writing craft.
The most significant casualty is the assumption that specialisation requires different models. The standard framing for deploying AI in different domains has been to fine-tune or otherwise distinguish the underlying model — a legal model, a medical model, a code model. Agent Skills quietly proposes an alternative: keep the same general-purpose model and specialise via context. The model stays general; the skill makes it specific. This doesn't refute fine-tuning as a technique, but it does question when it is the right level to intervene.
The strict separation of code and prose as different artifacts also comes under pressure. The post is explicit that a skill can contain both instructions (markdown prose) and executable scripts (code) within the same directory. The agent decides which to read for context and which to run as a tool. This blurs the line between documentation and capability. A script in a skill directory is simultaneously code and part of the knowledge structure — its presence in the manifest tells the agent something about what is possible, even before the script is executed.
Finally, the big design up front heuristic takes a hit. The post's advice for skill development is iterative and observational: run the agent on representative tasks, watch where it struggles, build skills to address the gaps. Evaluate first, design second. The canonical skill isn't written at the start of a project; it's extracted from a running system after you've watched what the agent actually needs. This inverts the conventional product-requirements-before-implementation sequence that most engineering processes assume.
The most portable new model is the onboarding-guide metaphor for AI capability packaging. "Building a skill is like creating an onboarding guide for a new hire." This framing is not merely illustrative — it is structurally precise. A new hire is a general-purpose reasoner. The onboarding guide doesn't change what they know how to do in the abstract; it gives them the specific procedural knowledge and organisational context they need for this role. Skills do the same for agents. The metaphor generalises: any time you are deciding how to equip an AI system with knowledge, ask yourself whether you are writing a policy (code) or an onboarding guide (skill).
Second is three-level progressive loading as a context-management pattern. The insight is that context consumption should be proportional to relevance, not determined by completeness. Most prompting architectures load everything upfront and hope it fits. The skill architecture inverts this: load nothing upfront except the registry, load the summary on trigger, load the detail only when the detail is needed. This is a transferable pattern for any system that must manage a large knowledge base against a finite context window.
Third, the post introduces determinism-boundary thinking: the explicit question of which operations should be deterministic code and which should be handled by language model reasoning. Code is reliable but brittle; it cannot handle special cases it wasn't written for. Language model reasoning is flexible but probabilistic. The skill architecture lets you embed both in the same unit of expertise — scripts for the deterministic parts, prose instructions for the parts that require judgment. The valuable new habit is asking, for each operation: does this need zeros-and-ones determinism, or does it need the model's fuzzy contextual judgment?
Finally, agent-legible documentation: the emerging practice of writing documentation not just for human readers but for AI agents that will consume it as working instructions. The name and description in SKILL.md frontmatter are not marketing copy; they are what the agent uses to decide when to load the skill. The prose in the body is not background reading; it is the executable onboarding sequence. This suggests that the distinction between "documentation" and "system prompt" is collapsing — any sufficiently precise documentation is already a kind of prompt.
The most durable contribution of the Agent Skills post may be the simplest: it treats the problem of equipping an AI agent as a knowledge-management problem, not a model problem. The model is assumed to be capable. The question is what it needs to know, in what form, and at what moment. The skill file is an answer to that question — not the only answer, but a particularly clean one.
Building a skill is like creating an onboarding guide for a new hire. — Anthropic Engineering, Oct 2025
What the latticework gains is a new way to think about the relationship between knowledge and action in an AI system. Skills locate procedural knowledge in a format that is inspectable, editable, and composable — and those three properties are precisely what the monolithic-system-prompt approach sacrifices. The skill file is the onboarding guide for the agent. And if you have ever written a good onboarding guide for a human colleague, you already know most of what you need to know to write a good skill.