Skills: packaging reusable capabilities
How skills package instructions + tools + knowledge into a capability the agent invokes.
5 min read
You've seen how tools give the agent actions and how MCP standardizes access to those tools. But when an agent needs to execute a complete capability — like 'analyze a contract' or 'answer support questions' — loading everything into the main prompt becomes a mess. That's where skills come in: a cohesive package of instructions, tools, and knowledge that the agent loads only when needed.
What a skill actually is
Think of a skill as a software module — but for agent behavior. It packages three things together:
- Instructions / procedure: what to do, in what order, how to reason about the problem.
- Tools: which tools (or MCP servers) this capability needs to act in the world.
- Knowledge: domain-specific context — documents, examples, business rules — that only makes sense for this capability.
When the agent decides it needs the contract-analysis skill, it loads it: instructions enter the context, tools become available, relevant knowledge is injected. When done, all of that is released. The main prompt doesn't carry the weight of capabilities that aren't needed at that moment.
This maps directly to code: you don't import every library in the project into every function. You import what the function needs. Skills apply the same principle to agent behavior — separation of concerns, but for reasoning and action.
Anatomy of a skill
A skill is invoked by the agent orchestrator and composes instructions, tools, and knowledge into a single cohesive package.
- Orquestrador · loop ReAct
- Instruções · procedimento + raciocínio
- Ferramentas · extract-clauses, flag-risk
- Conhecimento · regras jurídicas, exemplos
- Servidor MCP · contract-tools
- Vector Store · embeddings jurídicos
Skills vs Tools vs MCP: where each one lives
This distinction trips up a lot of people, so I'll be direct:
Tool is an atomic action: fetch-document, send-email, run-query. It does one thing and knows nothing about the larger problem.
MCP is a transport and discovery protocol: it standardizes how the agent finds and calls tools, regardless of where they're hosted. It's the integration layer.
Skill is the level above both. It orchestrates: defines the procedure (first extract clauses, then classify risks, then generate summary), declares which tools are needed (potentially using MCP underneath to access them), and injects the relevant domain knowledge. A skill can call multiple tools. A tool doesn't know a skill exists.
The analogy I use: a tool is a function, MCP is the HTTP protocol between services, a skill is the use case — the domain service that orchestrates calls and loads the right context to solve a specific problem. You can have a skill without MCP (local tools), but a well-designed skill uses MCP to keep tools decoupled and reusable.
Tool vs MCP vs Skill — clear boundaries
| Dimension | Tool | MCP | Skill | |
|---|---|---|---|---|
| Abstraction level | Atomic action | Protocol / transport | Domain capability | — |
| Contains instructions? | No | No | Yes | — |
| Contains knowledge? | No | No | Yes | — |
| Who calls it? | Skill or agent directly | Tool or skill (transport) | Agent orchestrator | — |
| Reusable across agents? | Yes, but granular | Yes (protocol) | Yes, at capability level | — |
In practice, I create a skill when I notice a set of instructions + tools starting to repeat across more than one agent or flow. If two different agents both need to 'analyze customer feedback sentiment,' that's a skill — I don't duplicate the instructions in each prompt. The clearest signal to create a skill is when you're copy-pasting instructions between agents. Another signal: when a sub-problem has its own knowledge domain (legal, financial, technical) that shouldn't leak into the agent's general context.
Skills in daily work and modern platforms
Concrete examples of skills that make sense in real systems:
technical-support: triage instructions, knowledge base search and ticket creation tools, product documentation injected as context.financial-analysis: balance sheet reading procedure, historical data access tools via MCP, accounting rules as knowledge.code-generation: best practices instructions, sandbox code execution tool, company internal pattern examples.
In modern platforms, the concept appears under different names but with the same structure. Amazon Bedrock AgentCore (which we'll see in lesson 17) treats skills as capability units the agent can activate dynamically. Microsoft Copilot Studio names them skills explicitly. Microsoft's Semantic Kernel has the concept of plugins that package functions + semantic descriptions — same idea. AutoGen uses AssistantAgent with agent-specific system prompts and tools — implicit skills.
The pattern is converging: the industry recognizes that scalable agents need modular capabilities, not monolithic prompts. The bigger the agent, the more important this separation becomes. An agent with 15 skills loaded simultaneously is an agent with 15 context and focus problems.
What to remember about skills
Frequent questions about skills
Can a skill call another skill?
Yes, and this is a legitimate pattern in more complex agents — a 'complete customer analysis' skill can orchestrate smaller skills for 'financial analysis' and 'risk analysis'. But be careful with excessive depth: two levels of composition already require attention to tracing and context cost.
Is a skill the same as a sub-agent?
Not exactly. A sub-agent has its own reasoning loop and can make independent decisions. A skill is more deterministic: it follows a defined procedure. In practice, the boundary is thin — some platforms implement skills as lightweight sub-agents. What matters is the intent: skill is packaged capability, sub-agent is delegated autonomy.
Do I need a specific framework to use skills?
No. You can implement the concept manually: a dictionary of skills with instructions, tool lists, and context documents, loaded dynamically into the prompt based on detected intent. Frameworks like Semantic Kernel, LangGraph, and Bedrock AgentCore just formalize and automate this pattern.
Checkpoint — Module 3
1. What's the best distinction between skill, tool and MCP?
2. Why do skills help scale an agent?
Closing Module 3
We've reached the end of the agents module. You now have the complete map: the ReAct loop that gives the agent autonomy, short and long-term memory so it doesn't forget, orchestration patterns for complex problems, MCP to integrate tools in a standardized way, and skills to package capabilities without inflating context. These aren't isolated concepts — they compose. A real agent uses all of them simultaneously. In the next module, we go to AWS: how Amazon Bedrock and Bedrock AgentCore turn these concepts into managed, production-ready infrastructure. Before moving on, take the checkpoint below — it covers all of Module 3.