![\"\"](\"https:\/\/www.newsbeep.com\/au\/wp-content\/uploads\/2026\/03\/skill_levels_diagram-1024x597.webp.webp\")
Skills load context progressively across three levels, skill summary (metadata), body (detailed instructions), and referenced files (additional context), each triggered only when needed.<\/p>\nThis post reflects the state of Claude Skills, MCP, and subagents as of February 2026. AI moves fast, so some details may be outdated by the time you read this. The concepts this post focuses on, however, are timeless.<\/p>\n
If you\u2019ve been building with LLMs for a while, you\u2019ve probably lived through this loop over and over: you take your time crafting a great prompt that leads to excellent results, and then a few days later you need the same behavior again, so you start prompting from scratch again. After some repetitions you maybe realize the inefficiencies, so you\u2019re going to store the prompt\u2019s template somewhere so that you can retrieve it for later, but even then you need to find your prompt, paste it in, and tweak it for this particular conversation. It\u2019s so tedious.<\/p>\n
This is what I call the prompt engineering hamster wheel. And it\u2019s a fundamentally broken workflow.<\/p>\n
Claude Skills are Anthropic\u2019s answer to this \u201creusable prompt\u201d problem, and more. Beyond just saving you from repetitive prompting, they introduce a fundamentally different approach to context management, token economics, and the architecture of AI-powered development workflows.<\/p>\n
In this post, I\u2019ll unpack what skills and subagents actually are, how they differ from traditional MCP, and where the skill \/ MCP \/ subagent mix is heading.<\/p>\n
What are Skills?<\/p>\n
At their core, skills are reusable instruction sets that AI Agents, like Claude, can automatically access when they\u2019re relevant to a conversation. You write a skill.md file with some metadata and a body of instructions, drop it into a .claude\/skills\/ directory, and Claude takes it from there.<\/p>\n
Their looks<\/p>\n
In its simplest form, a skill is a markdown file with a name, description, and body of instructions, like this:<\/p>\n
—<\/p>\n
name: <\/p>\n
description: <\/p>\n
—<\/p>\n
Their strengths<\/p>\n
The main strength of skills lies in the auto-invocation. When starting a new conversation, the agent only reads each skill\u2019s name and description, to save on tokens. When it determines a skill is relevant, it loads the body. If the body references additional files or folders, the agent reads those too, but only when it decides they are needed. In essence, skills are lazy-loaded context. The agent doesn\u2019t consume the full instruction set upfront. It progressively discloses information to itself, pulling in only what\u2019s needed for the current step.<\/p>\n
This progressive disclosure operates across three levels, each with its own context budget:<\/p>\n
Metadata (loaded at startup): The skill\u2019s name (max 64 characters) and description (max 1,024 characters). This costs roughly ~100 tokens per skill, negligible overhead even with hundreds of skills registered.<\/p>\n
Skill body (loaded on invocation): The full instruction set inside skill.md, up to ~5,000 tokens. This only enters the context window when the agent determines the skill is relevant.<\/p>\n
Referenced files (loaded on demand): Additional markdown files, folders, or scripts within the skill directory. There\u2019s practically no limit here, and the agent reads these on demand, only when the instructions reference them and the current task requires it.<\/p>\n
Skills load context progressively across three levels, skill summary (metadata), body (detailed instructions), and referenced files (additional context), each triggered only when needed.<\/p>\n
Insight: Skills are reusable, lazy-loaded, and auto-invoked instruction sets that use progressive disclosure across three levels: metadata, body, and referenced files. This minimizes the upfront cost by preventing to dump everything into the context window (looking at you, MCP \ud83d\udc40).<\/p>\n
The problem in token economics<\/p>\n
Cost factors<\/p>\n
It\u2019s no secret; an agent\u2019s context window space isn\u2019t free, and filling it has compounding costs. Every token in your context window costs you in three ways:<\/p>\n
Actual cost: the obvious one is that you\u2019re paying per token. This can be directly through API usage, or indirectly through usage limits.<\/p>\n
Latency: you\u2019re also paying with your time, since more input tokens means slower responses. Something that doesn\u2019t scale well with the length of the context window (~attention mechanism).<\/p>\n
Quality: finally, there\u2019s also a degradation in quality due to long context windows. LLMs demonstrably perform worse when their context is cluttered with irrelevant information.<\/p>\n
The costly overhead of MCPs<\/p>\n
Let\u2019s put this into perspective, through a quick back-of-the-envelope calculation. My go-to MCP picks for programming are:<\/p>\n
AWS for infrastructure deployment. Three servers (aws-mcp, aws-official, aws-docs) combined yield a cost of around ~8,500 tokens (13 tools).<\/p>\n
Context7 for documentation. Metadata is around ~750 tokens (2 tools).<\/p>\n
Figma for bringing design to frontend development. Metadata is around ~500 tokens (2 tools).<\/p>\n
GitHub for searching code in other repositories. Metadata is around ~2,000 tokens (26 tools).<\/p>\n
Linear for project management. Metadata is around ~3,250 tokens (33 tools).<\/p>\n
Serena for code search. Metadata is around ~4,500 tokens (26 tools).<\/p>\n
Sentry for error tracking. Metadata is around ~12,500 tokens (22 tools).<\/p>\n
That\u2019s a total of roughly ~32,000 tokens of tool metadata, loaded into every single message, whether you\u2019re interacting with the tool or not.<\/p>\n
To put a dollar figure on this: Claude Opus 4.6 charges $5 per million input tokens. Those 32K tokens of idle MCP metadata add $0.16 to every message you send. That sounds small, until you realize that even a simple 5-message conversation already adds $0.8 in pure overhead. And most developers don\u2019t send just 5 messages; add some short clarifications and context-gathering questions and you quickly reach 10s if not 100s of messages. Let\u2019s say on average you send 50 messages a day over a 20-day work month, that\u2019s $8\/day, ~$160\/month* in pure overhead, just for tool descriptions sitting in context. And that\u2019s before you account for the latency and quality impact.<\/p>\n
*A small asterisk: most models charge significantly less for cached input tokens (90% discount). An asterisk to this asterisk is that some of them charge extra when enabling caching, and they don\u2019t always enable (API) caching by default (cough Claude cough).<\/p>\n
The cost-effective approach of skills<\/p>\n
The loading patttern of Skills fundamentally change all three cost factors. At the outset, the agent only sees each skill\u2019s name and a short description, roughly ~100 tokens per skill. Like this, I could register 300 skills and still consume fewer tokens than my MCP setup does. The full instruction body (~5,000 tokens) only loads when the agent decides it\u2019s relevant, and referenced files will only load when the current step needs them.<\/p>\n
In practice, a typical conversation might invoke one or two skills while the rest remain invisible to the context window. That\u2019s the key difference: MCP cost scales with the number of registered tools (across all servers), while skills\u2019 cost scales more closely with actual usage.<\/p>\n
![\"\"](\"https:\/\/www.newsbeep.com\/au\/wp-content\/uploads\/2026\/03\/mcp_eager_vs_skills_lazy-1024x529.webp.webp\")
MCP loads all metadata upfront. Skills load context only when relevant, a difference that compounds with every message.<\/p>\n
Insight: MCP is \u201ceager\u201d and loads all tool metadata upfront regardless of whether it\u2019s used. Skills are \u201clazy\u201d and load context progressively and only when relevant. The difference matters for cost, latency, and output quality.<\/p>\n
Wait, that\u2019s misleading? Skills and MCP are two completely different things!<\/p>\n
If the above reads like skills are the new and better MCPs, then allow me to correct that framing. The intent was to zoom in on their loading patterns and the impact they have on token consumption. Functionally, they are quite different.<\/p>\n
MCP (Model Context Protocol) is an open standard that gives any LLM the ability to interact with external applications. Before MCP, connecting M models to N tools required M * N custom integrations. MCP collapses that to M + N: each model implements the protocol once, each tool exposes it once, and they all interoperate. It\u2019s a simple infrastructural change, but it\u2019s genuinely powerful (no wonder it took the world by storm).<\/p>\n
Skills, on the other hand, are somewhat \u201cglorified prompts\u201d, and I mean that in the best possible way. They give an agent expertise and direction on how to approach a task, what conventions to follow, when to use which tool, and how to structure its output. They\u2019re reusable instruction sets fetched on-demand when relevant, nothing more, nothing less.<\/p>\n
Insight: MCP gives an agent capabilities (the \u201cwhat\u201d). Skills give it expertise (the \u201chow\u201d) and thus they\u2019re complementary.<\/p>\n
Here\u2019s an example to make this concrete. Say you connect GitHub\u2019s MCP server to your agent. MCP gives the agent the ability to create pull requests, list issues, and search repositories. But it doesn\u2019t tell the agent, for example, how your team structures PRs, that you always include a testing section, that you tag by change type, that you reference the Linear ticket in the title. That\u2019s what a skill does. The MCP provides the tools, the skill provides the playbook.<\/p>\n
So, when earlier I showed that skills load context more efficiently than MCP, the real takeaway isn\u2019t \u201cuse skills instead of MCP\u201d, it\u2019s that lazy-loading as a pattern works. Hence, it\u2019s worth asking: why can\u2019t MCP tool access be lazy-loaded too? That\u2019s where subagents come in.<\/p>\n
Subagents: best of both worlds<\/p>\n
Subagents are specialized child agents with their own isolated context window and tools connected. Two properties make them powerful:<\/p>\n
Isolated context: A subagent starts with a clean context window, pre-loaded with its own system prompt and only the tools assigned to it. Everything it reads, processes, and generates stays in its own context, the main agent only sees the final result.<\/p>\n
Isolated tools: Each subagent can be equipped with its own set of MCP servers and skills. The main agent doesn\u2019t need to know about (or pay for) tools it never directly uses.<\/p>\n
Once a subagent finishes its task, its entire context is discarded. The tool metadata, the intermediate reasoning, the API responses: all gone. Only the result flows back to the main agent. This is actually a great thing. Not only do we avoid bloating the main agent\u2019s context with unnecessary tool metadata, we also prevent unnecessary reasoning tokens from polluting the context. As an illustrative example, imagine a subagent that researches a library\u2019s API. It might search across multiple documentation sources, read through dozens of pages, and try several queries before finding the right answer. You still pay for the subagent\u2019s own token usage, but all of that intermediate work, the dead ends, the irrelevant pages, the search queries, gets discarded once the subagent finishes. The key benefit is that none of it compounds into the main agent\u2019s context, so every subsequent message in your conversation stays clean and cheap.<\/p>\n
This means you can design your setup so that MCP servers are only accessible through specific subagents, never loaded on the main agent at all. Instead of carrying ~32,000 tokens of tool metadata in every message, the main agent carries nearly zero. When it needs to open a pull request, it spins up a GitHub subagent, creates the PR, and returns the link. Similar to skills being lazy-loaded context, subagents are lazy-loaded workers: the main agent knows what specialists it can call on, and only spins one up when a task demands it.<\/p>\n
A practical example<\/p>\n
Let\u2019s make this tangible. One workflow I use daily is a \u201cfeature branch wrap-up\u201d that automates most of a very tedious part of my development cycle: opening a pull request. Here\u2019s how skills, MCP, and subagents play together.<\/p>\n
After the main agent and I finish the coding work, I ask it to wrap up the feature branch. The main agent doesn\u2019t handle this itself; it delegates the entire PR workflow to a dedicated subagent. This subagent is equipped with the GitHub MCP server and a change-report skill that defines how my team structures PRs. Its skill.md looks roughly like this:<\/p>\n
—
\nname: change-report
\ndescription: Use when generating a change report for a PR.
\n Defines the team’s PR structure, categorization rules, and formatting
\n conventions.
\n—<\/p>\n
1. Make sure there are no staging changes left, otherwise report back to
\n the main agent
\n2. Run `git diff dev…HEAD –stat` and `git log dev..HEAD –oneline`
\n to gather all changes on this feature branch.
\n3. Analyze the diff and categorize the most crucial changes by their type
\n (new features, refactors, bug fixes, or config changes).
\n4. Generate a structured change report following the template
\n in `pr-template.md`.
\n5. Open the PR via GitHub MCP, populating the title and body from
\n the generated report.
\n6. Answer with the PR link.<\/p>\n
The pr-template.md file in the same directory defines my team\u2019s PR structure: sections for summary, changes breakdown, and testing notes. This is level 3 of progressive disclosure: the subagent only reads it when step 4 tells it to.<\/p>\n
Here\u2019s what makes this setup work. The skill provides the expertise on how my team reports on changes, the GitHub MCP provides the capability to actually create the PR, and the subagent provides the context boundary to perform all of this work. The main agent, on the other hand, only calls the subagent, waits for it to complete, and gets either a confirmation back or a message of what went wrong.<\/p>\n
![\"\"](\"https:\/\/www.newsbeep.com\/au\/wp-content\/uploads\/2026\/03\/skills_mcp_subagents_architecture-1024x666.webp.webp\")
The PR workflow in action: the main agent delegates the entire PR process to a subagent equipped with a change-report skill and GitHub MCP access.<\/p>\n
Insight: skills, MCPs, and subagents work in harmony. The skill provides expertise and instruction, MCP provides the capability, the subagent provides the context boundary (keeping the main agent\u2019s context clean).<\/p>\n
The bigger picture<\/p>\n
In the early days of LLMs, the race was about better models: fewer hallucinations, sharper reasoning, more creative output. That race hasn\u2019t stopped completely, but the center of gravity has certainly shifted. MCP and Claude Code were genuinely revolutionary. Upgrading Claude Sonnet from 3.5 to 3.7 honestly was not. The incremental model improvements we\u2019re getting today matter far less than the infrastructure we build around them. Skills, subagents, and multi-agent orchestration are all part of this shift: from \u201chow do we make the model smarter\u201d to \u201chow do we get the most value out of what\u2019s already here\u201d.<\/p>\n
Insight: the value in AI development has shifted from better models to better infrastructure. Skills, subagents, and multi-agent orchestration aren\u2019t just developer experience improvements; they\u2019re the architecture that makes agentic AI economically and operationally viable at scale.<\/p>\n
Where we are today<\/p>\n
Skills solve the prompt engineering hamster wheel by turning your best prompts into reusable, auto-invoked instruction sets. Subagents solve the context bloat problem by isolating tool access and intermediate reasoning into dedicated workers. Together, they make it possible to codify your expertise once and have it automatically applied across every future interaction. This is what engineering teams following the state-of-the-practice already do with documentation, style guides, and runbooks. Skills and subagents just make those artifacts machine-readable.<\/p>\n
The subagent pattern is also unlocking multi-agent parallelism. Instead of one agent working through tasks sequentially, you can spin up multiple subagents concurrently, have them work independently, and collect their results. Anthropic\u2019s own multi-agent research system<\/a> already does this: Claude Opus 4.6 orchestrates while Claude Sonnet 4.6 subagents execute in parallel. This naturally leads to heterogeneous model routing, where an expensive frontier model orchestrates and plans, while smaller, cheaper models handle execution. The orchestrator reasons, the workers execute. This can dramatically reduce costs while maintaining output quality.<\/p>\n There\u2019s an important caveat here. Where parallelism works well for read tasks, it gets much harder for write tasks that touch shared state. Say, for example, you\u2019re spinning up a backend and a frontend subagent in parallel. The backend agent refactors an API endpoint, while the frontend agent, working from a snapshot taken before that change, generates code that calls the old endpoint. Neither agent is wrong in isolation, but together they produce an inconsistent result. This is a classic concurrency problem, coming from the AI workflows of the near-future, which to date remains an open problem.<\/p>\n Where it\u2019s heading<\/p>\n I expect skill composition to become more sophisticated. Today, skills are relatively flat: a markdown file with optional references. But the architecture naturally supports layered skills that reference other skills, creating something like an inheritance hierarchy of expertise. Think a base \u201ccode review\u201d skill extended by language-specific variants, further extended by team-specific conventions.<\/p>\n Most multi-agent systems today are strictly hierarchical: a main agent delegates to a subagent, the subagent finishes, and control returns. There\u2019s currently not much peer-to-peer collaboration between subagents yet. Anthropic\u2019s recently launched \u201cagent teams\u201d feature for Opus 4.6<\/a> is an early step towards this, allowing multiple agents to coordinate directly rather than routing everything through an orchestrator. On the protocol side, Google\u2019s A2A (Agent-to-Agent Protocol) could standardize this pattern across providers; where MCP handles agent-to-tool communication, A2A would handle agent-to-agent communication. That said, A2A\u2019s adoption has been slow compared to MCP\u2019s explosive growth. One to watch, not one to bet on yet.<\/p>\n Agents will become the new functions<\/p>\n There\u2019s a broader abstraction emerging here that\u2019s worth stepping back to appreciate. Andrej Karpathy\u2019s famous tweet \u201cThe hottest new programming language is English\u201d captured something real about how we interact with LLMs. But skills and subagents take this abstraction one level further: agents are becoming the new functions.<\/p>\n A subagent is a self-contained unit of work: it takes an input (a task description), has its own internal state (context window), uses specific tools (MCP servers), follows specific instructions (skills), and returns an output. It can be called from multiple places, it\u2019s reusable, and it\u2019s composable. That\u2019s a function. The main agent becomes the execution thread: orchestrating, branching, delegating, and synthesizing results from specialized workers.<\/p>\n Aside from the analogy, it can have the same practical implications that functions had for software engineering. Isolation limits the blast radius when an agent fails, rather than corrupting the entire system, and failures can be caught through try-except mechanisms. Specialization means each agent can be optimized for its specific task. Composability means you can build increasingly complex workflows from simple, testable parts. And observability follows naturally; since each agent is a discrete unit with clear inputs and outputs, tracing \u201cwhy did the system do X\u201d becomes inspecting a call stack rather than staring at a 200K-token context dump.<\/p>\n Conclusion<\/p>\n Skills look like simple \u201creusable prompts\u201d on the surface, but they actually represent a thoughtful answer to some of the hardest problems in AI tooling: context management, token efficiency, and the gap between raw capability and domain expertise.<\/p>\n If you haven\u2019t experimented with skills yet, start small. Pick your most-repeated prompting pattern, extract it into a skill.md, and see how it changes your workflow. Once that clicks, take the next step: identify which MCP tools don\u2019t need to live on your main agent, or which subprocesses require a lot of reasoning that\u2019s used after you find the answer, and scope them to dedicated subagents instead. You\u2019ll be surprised how much cleaner your setup becomes when each agent only carries what it actually needs.<\/p>\n Key insights from this post<\/p>\n Skills are reusable, lazy-loaded, and auto-invoked instruction sets that use progressive disclosure across three levels: metadata, body, and referenced files. This minimizes the upfront cost by preventing to dump everything into the context window (looking at you, MCP \ud83d\udc40).<\/p>\n MCP is \u201ceager\u201d and loads all tool metadata upfront regardless of whether it\u2019s used. Skills are \u201clazy\u201d and load context progressively and only when relevant. The difference matters for cost, latency, and output quality.<\/p>\n MCP gives an agent capabilities (the \u201cwhat\u201d). Skills give it expertise (the \u201chow\u201d) and thus they\u2019re complementary.<\/p>\n Skills, MCPs, and subagents work in harmony. The skill provides expertise and instruction, MCP provides the capability, the subagent provides the context boundary (keeping the main agent\u2019s context clean).<\/p>\n The value in AI development has shifted from better models to better infrastructure. Skills, subagents, and multi-agent orchestration aren\u2019t just developer experience improvements; they\u2019re the architecture that makes agentic AI economically and operationally viable at scale.<\/p>\n Final insight: The prompt engineering hamster wheel is optional. It\u2019s time to step off.<\/p>\n Found this useful? Follow me on LinkedIn<\/a>, TDS<\/a>, or Medium<\/a> to see my next explorations!<\/p>\n","protected":false},"excerpt":{"rendered":"This post reflects the state of Claude Skills, MCP, and subagents as of February 2026. AI moves fast,…\n","protected":false},"author":2,"featured_media":512197,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[20],"tags":[256,8667,254,255,64,63,10885,32773,8393,29133,105],"class_list":["post-512196","post","type-post","status-publish","format-standard","has-post-thumbnail","category-artificial-intelligence","tag-ai","tag-ai-agent","tag-artificial-intelligence","tag-artificialintelligence","tag-au","tag-australia","tag-editors-pick","tag-genai","tag-llm","tag-mcp","tag-technology"],"_links":{"self":[{"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/posts\/512196","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/comments?post=512196"}],"version-history":[{"count":0,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/posts\/512196\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/media\/512197"}],"wp:attachment":[{"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/media?parent=512196"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/categories?post=512196"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.newsbeep.com\/au\/wp-json\/wp\/v2\/tags?post=512196"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}![\"\"](\"https:\/\/www.newsbeep.com\/au\/wp-content\/uploads\/2026\/03\/agents_as_functions-1024x563.webp.webp\")
A subagent maps directly to a function: input, internal state, tools, instructions, and output. The main agent is the execution thread.<\/p>\n