Why Skills Are Replacing Static Tool Definitions in AI Agents

In late 2024, Anthropic introduced Skills for Claude. At first glance, they looked like rebranded tools. But they're fundamentally different.

Traditional tools are static function definitions. Skills are dynamic, contextual capabilities.

The difference matters. A lot.

If you're building agents in 2025, understanding Skills vs Tools is critical. Let me break down what's changed and why.

What Are Traditional Tools?

Traditional tools (in LangChain, MCP, AutoGen, etc.) are function definitions registered globally.

Example:

from langchain.agents import Tool

lookup_order_tool = Tool(
    name="lookup_order",
    description="Look up order details by order number",
    func=lookup_order_function,
    parameters={
        "order_id": {"type": "string", "required": True}
    }
)

# Register globally
agent = Agent(tools=[lookup_order_tool, refund_tool, shipping_tool, ...])

Characteristics:

• Registered at agent initialization
• Always available (all tools loaded in context)
• Static metadata (description doesn't change)
• Function-level granularity
• No internal state or context

What happens at runtime:

1. All tool definitions sent to LLM in every request
2. LLM decides which tool(s) to call
3. Tool executes, returns result
4. Result added to conversation context
5. Repeat

What Are Skills?

Skills are self-contained capability modules that bundle tools, context, and state.

Example:

class OrderManagementSkill:
    """Skill for managing customer orders"""

    def __init__(self):
        self.description = "Handle order inquiries, tracking, and updates"
        self.tools = [
            self.lookup_order,
            self.track_shipment,
            self.update_order
        ]
        self.context_manager = OrderContextManager()

    @tool(description="Look up order details")
    def lookup_order(self, order_id: str) -> OrderDetails:
        # Fetch order
        order = db.get_order(order_id)

        # Store in skill-specific context (not global)
        self.context_manager.set_current_order(order)

        # Return summarized data (not raw dump)
        return order.summarize()

    @tool(description="Track shipment status")
    def track_shipment(self, order_id: str = None) -> ShipmentStatus:
        # Can use previously loaded order from skill context
        if not order_id:
            order = self.context_manager.get_current_order()
            order_id = order.id

        return shipping_api.track(order_id)

Key differences:

1. Bundled functionality: Multiple related tools grouped together
2. Internal state: Skill manages its own context
3. Conditional loading: Loaded only when needed
4. Dynamic context: Context provided only when skill is active
5. Encapsulation: State and logic contained within skill

The Fundamental Shift

Old Model: Global Tool Registry

Architecture:

Agent Context Window:
├── System prompt
├── Conversation history
├── Tool 1 definition
├── Tool 2 definition
├── ... (all 30 tools)
└── Tool 30 definition

All tools always present → 4,500 tokens

Problem: Context bloat from unused tools

New Model: Dynamic Skill Loading

Architecture:

Agent Context Window:
├── System prompt
├── Conversation history
└── Active Skill: OrderManagement
    ├── Skill description (100 tokens)
    └── 3 relevant tools (400 tokens)

Only active skill present → 500 tokens (89% reduction)

Benefit: Lean context, focused capabilities

Why Skills Win: Technical Advantages

Advantage #1: Scoped Context

Tools: All tool metadata always in global context

Skills: Context loaded only when skill is active

Example:

With tools (30 tools loaded):

Context:
- lookup_order: "Look up order details..."
- process_refund: "Process refund for order..."
- track_shipment: "Track shipment status..."
- [27 more tools...]
- search_products: "Search product catalog..."
- update_inventory: "Update inventory levels..."

User asks: "Where's my order?"

• Agent sees 30 tool descriptions
• Must reason about which 1-2 are relevant
• Wasted attention on 28 irrelevant tools

With skills (1 skill loaded):

Context:
- OrderManagementSkill: "Handle order inquiries"
  - lookup_order
  - track_shipment
  - update_order

User asks: "Where's my order?"

• Agent sees 1 skill with 3 relevant tools
• Clear, focused options
• No irrelevant noise

Advantage #2: Stateful Operations

Tools: Stateless (no memory between calls)

Skills: Can maintain state across tool calls

Example scenario: Multi-step workflow

With tools:

# Call 1: Look up order
result1 = agent.call_tool("lookup_order", order_id="12345")
# Returns full order object (500 tokens added to context)

# Call 2: Check shipping
result2 = agent.call_tool("track_shipment", order_id="12345")
# Agent must send order_id again
# Previous order data still cluttering context

# Call 3: Update order
result3 = agent.call_tool("update_order", order_id="12345", status="shipped")
# Agent must send order_id again

Problems:

• Order data loaded 3 times
• Context grows with each call
• No shared state between tools

With skills:

# Skill loaded once
skill = OrderManagementSkill()

# Call 1: Look up order
order = skill.lookup_order(order_id="12345")
# Skill internally stores order in its state

# Call 2: Check shipping
shipping = skill.track_shipment()
# Skill uses previously loaded order (no need to pass order_id)
# Skill returns summary (not full data dump)

# Call 3: Update order
skill.update_order(status="shipped")
# Skill operates on current order in its state

Benefits:

• Order loaded once, reused
• Context stays lean
• Natural workflow (skill remembers what it's working on)

Advantage #3: Dynamic Tool Selection

Tools: All tool definitions sent to LLM upfront

Skills: Tools exposed only when skill is loaded

Example:

With tools:

• Agent always knows about bulk_export_orders tool
• Even for single-order inquiries
• LLM wastes reasoning considering irrelevant tools

With skills:

• OrderManagementSkill has basic tools (lookup, track, update)
• OrderBulkOperationsSkill has bulk tools (export, import)
• Only relevant skill loaded based on user intent

Advantage #4: Composability

Tools: Flat list of functions

Skills: Hierarchical, composable modules

Example:

Tool approach:

tools = [
    lookup_order,
    process_refund,
    check_refund_eligibility,
    calculate_refund_amount,
    issue_refund,
    send_refund_confirmation,
    # All flat, no organization
]

Skill approach:

class RefundSkill:
    def __init__(self):
        # Uses other skills internally
        self.order_skill = OrderManagementSkill()
        self.payment_skill = PaymentProcessingSkill()
        self.notification_skill = NotificationSkill()

    def process_refund(self, order_id):
        # Orchestrates other skills
        order = self.order_skill.lookup_order(order_id)

        if not self.check_eligibility(order):
            return "Not eligible"

        amount = self.calculate_refund(order)
        refund_id = self.payment_skill.issue_refund(order.payment_id, amount)
        self.notification_skill.send_refund_confirmation(order.customer_email, refund_id)

        return f"Refund {refund_id} processed"

Benefits:

• Clear dependencies
• Reusable components
• Easier testing and maintenance

Advantage #5: Progressive Disclosure

Tools: All capabilities visible upfront

Skills: Capabilities revealed progressively

Example conversation:

With tools:

User: "I have a question about my order"

Agent context includes:
- 30 tools (order, refund, products, inventory, reports, admin...)

Agent: "I can help! What's your order number?"

With skills:

User: "I have a question about my order"

Agent loads: OrderManagementSkill only (3 tools)

Agent: "I can help! What's your order number?"

User: "I'd like a refund"

Agent now loads: RefundSkill (5 tools)

Agent: "Let me check if your order is eligible for a refund"

Benefit: Context adapts to conversation flow

Real-World Architecture Comparison

Traditional Tool-Based Agent

Architecture:

class ToolBasedAgent:
    def __init__(self):
        # Load all tools upfront
        self.tools = [
            # Order tools
            lookup_order_tool,
            track_shipment_tool,
            update_order_tool,
            cancel_order_tool,

            # Refund tools
            check_refund_eligibility_tool,
            process_refund_tool,
            calculate_refund_tool,

            # Product tools
            search_products_tool,
            get_product_details_tool,

            # ... 20 more tools
        ]

    def run(self, message):
        # All tools always in context
        context = self.build_context(
            message=message,
            tools=self.tools  # All 30 tools
        )

        response = llm.generate(context)
        return response

Token usage per request: 6,000-8,000 tokens

Skills-Based Agent

Architecture:

class SkillBasedAgent:
    def __init__(self):
        # Register skills (not loaded into context yet)
        self.skills = {
            "order_management": OrderManagementSkill(),
            "refund_processing": RefundProcessingSkill(),
            "product_catalog": ProductCatalogSkill(),
            # ... more skills
        }

        self.active_skills = []

    def run(self, message):
        # Determine needed skills
        needed_skills = self.identify_skills(message)

        # Load only those skills
        self.active_skills = [self.skills[name] for name in needed_skills]

        # Build context with only active skills
        context = self.build_context(
            message=message,
            skills=self.active_skills  # 1-3 skills
        )

        response = llm.generate(context)
        return response

    def identify_skills(self, message):
        # Fast intent classification
        if "order" in message.lower():
            return ["order_management"]
        elif "refund" in message.lower():
            return ["order_management", "refund_processing"]
        # ... more logic

        return ["general"]

Token usage per request: 2,000-3,000 tokens (60% reduction)

Migration Path: Tools → Skills

If you have an existing tool-based agent, here's how to migrate:

Step 1: Group Related Tools

Identify clusters of related functionality:

# Before: 30 flat tools
tools = [t1, t2, t3, ..., t30]

# After: Group by domain
skill_groups = {
    "orders": [lookup_order, track_shipping, update_order, cancel_order],
    "refunds": [check_eligibility, calculate_refund, process_refund],
    "products": [search_products, get_details, check_inventory],
    "customer": [get_profile, update_profile, get_history],
}

Step 2: Convert Groups to Skills

class OrderManagementSkill:
    description = "Manage customer orders"

    def __init__(self):
        self.state = {}

    @tool
    def lookup_order(self, order_id: str):
        order = db.get_order(order_id)
        self.state['current_order'] = order
        return order.summarize()

    @tool
    def track_shipping(self, order_id: str = None):
        if not order_id:
            # Use order from state if available
            order_id = self.state.get('current_order', {}).get('id')

        return shipping_api.track(order_id)

    # ... more tools

Step 3: Implement Skill Loader

class SkillLoader:
    def __init__(self, skills):
        self.available_skills = skills

    def load_for_intent(self, intent):
        skill_map = {
            "order_inquiry": ["OrderManagementSkill"],
            "refund_request": ["OrderManagementSkill", "RefundProcessingSkill"],
            "product_question": ["ProductCatalogSkill"],
        }

        skill_names = skill_map.get(intent, [])
        return [self.available_skills[name] for name in skill_names]

Step 4: Update Agent Logic

# Before
agent = Agent(tools=all_tools)

# After
skill_loader = SkillLoader(all_skills)
intent = classify_intent(user_message)
active_skills = skill_loader.load_for_intent(intent)

agent = Agent(skills=active_skills)

Claude Skills: Anthropic's Implementation

Anthropic's Skills system adds additional features:

Feature #1: Extended Instructions

Skills can include detailed instructions loaded only when the skill is active:

class DataAnalysisSkill:
    extended_instructions = """
    When analyzing data:
    1. Always validate data quality first
    2. Look for outliers and handle appropriately
    3. Provide statistical summary before conclusions
    4. Suggest visualizations when relevant
    """

    # Tools...

Benefit: Detailed guidance without always cluttering context

Feature #2: Skill Chaining

Skills can call other skills:

class OrderFulfillmentSkill:
    def fulfill_order(self, order_id):
        # Use OrderManagementSkill
        order = self.order_skill.lookup_order(order_id)

        # Use InventorySkill
        if not self.inventory_skill.check_availability(order.items):
            return "Items not available"

        # Use PaymentSkill
        payment = self.payment_skill.process_payment(order.payment_info)

        # Use ShippingSkill
        shipment = self.shipping_skill.create_shipment(order)

        return f"Order {order_id} fulfilled, tracking: {shipment.tracking_id}"

Feature #3: Skill Metadata

Skills expose rich metadata:

class CustomerServiceSkill:
    metadata = {
        "name": "customer_service",
        "description": "Handle customer inquiries and support",
        "capabilities": ["order_lookup", "refund_processing", "complaint_handling"],
        "triggers": ["help", "support", "problem", "issue"],
        "confidence_threshold": 0.8,
    }

Benefit: Better skill selection, clear capabilities

Common Mistakes

Mistake #1: Making Everything a Skill

Wrong: Create a skill for every single function

Right: Create skills for coherent capability domains

Example:

• ✗ LookupOrderSkill, TrackShipmentSkill, UpdateOrderSkill (too granular)
• ✓ OrderManagementSkill (contains all three)

Mistake #2: Skills with No State

Wrong: Skill that's just a wrapper around stateless functions

Right: Use skills when state or context management adds value

If your skill doesn't need state, maybe it should stay a simple tool.

Mistake #3: Loading All Skills

Wrong: Load all skills into context (defeats the purpose)

Right: Load skills dynamically based on need

Mistake #4: No Skill Selection Logic

Wrong: Let the LLM choose which skills to load (costs tokens)

Right: Use fast intent classification to load appropriate skills

The Bottom Line

Traditional tools = Static function definitions, globally registered, always in context

Skills = Dynamic capability modules, conditionally loaded, stateful, composable

Why skills win:

• 60-80% context reduction
• Better tool organization
• Stateful workflows
• Composability
• Progressive capability disclosure

When to use skills:

• Agent has > 10 tools
• Tools cluster into logical groups
• Workflows require state
• Context efficiency matters

When tools are fine:

• < 5 simple tools
• All tools always relevant
• No state needed

Migration: Group related tools → Convert to skills → Add skill loader → Measure impact

Getting Started

Quick implementation:

1. Audit your tools: How many do you have? How are they related?
2. Group by domain: Orders, refunds, products, etc.
3. Create first skill: Start with your most-used tool cluster
4. Implement loader: Basic intent → skill mapping
5. Measure: Context size, accuracy, cost

Expected impact:

• 60%+ context reduction
• 40%+ cost savings
• Better tool selection accuracy

Need help migrating from tools to skills? We've helped teams reduce context bloat by 70% with skills-based architecture.

Get a skills migration consultation →

---

Related reading:

• Anthropic's Skills announcement: https://www.anthropic.com/news/equipping-agents-for-the-real-world-with-agent-skills
• Tool selection as a context problem (this blog)