AI Agent Skills vs Plugins: What's Actually Different?

Here's a scenario that probably sounds familiar.

You're three hours into building an AI agent. You've got Semantic Kernel imported, you're staring at their "plugin" documentation, and suddenly you hit a wall. Wait—these aren't plugins like your WordPress ad blocker. These are... skills? But the page says plugins? And why does the code look nothing like the OpenAI function calling example you saw yesterday?

Yeah. The terminology is a mess.

Microsoft calls them "skills" and "plugins" interchangeably (sort of). OpenAI just says "functions." LangChain went with "tools." Half the tutorials online use these words like synonyms. The other half insist there's a crucial distinction.

So which is it?

Skills: The Specialist Model

When framework developers talk about skills, picture a home renovation. Your AI agent is the general contractor. Skills are the electricians, plumbers, and carpenters—specialists who show up when specific work needs doing, do exactly one thing well, and leave.

A proper skill has four parts:

• Metadata—what it does, what it needs, what it returns
• The actual code—the thing that does the work
• Registration hooks—how it plugs into your framework
• State management—so it remembers context across calls

Concrete example: you're building a travel agent. You've got a calculate_route skill that takes coordinates and spits out travel time. A check_weather skill that wants a location and date. Each is small. Focused. Does one job.

This pattern shows up everywhere: Microsoft's Semantic Kernel, LangChain's tools, OpenAI's function calling. Different words, same DNA.

Learn more about building your first skill →

Plugins: The Old Guard

Plugins aren't new. Your browser has extensions. Your IDE has plugins. WordPress has, what, sixty thousand of them?

Traditionally, plugins add functionality at runtime. They bundle features. They integrate services. They modify behavior. Classic example: a WordPress plugin. You install it, configure some settings, and it runs. Maybe it's an SEO optimizer. Maybe it's a contact form. Either way, you—the human—decide when to install it and what it should do.

Here's the thing: plugins are built for humans to manage. Install. Configure. Activate. They often lump multiple features together and need you to tell them what to do.

An ad blocker illustrates this perfectly. You install it once. Set your preferences. It runs forever. You don't ask it to block a specific ad on a specific page—it just operates. That's the plugin mindset.

Five Ways They're Actually Different

Skills: atomic, discoverable, AI-invoked. Plugins: bundled, configured, human-managed.

1. Size and Focus

Skills are tiny. send_email is a skill. check_calendar is a skill. Each handles exactly one specific task.

Plugins tend toward bloat. Your "productivity suite" plugin might handle email, calendar, tasks, notes, and reminders all at once. That bundling made sense when humans managed everything—but it creates friction when an AI tries to reason about what capabilities are available.

2. Discovery

Skills describe themselves semantically. The AI reads the description, understands what it does, decides whether to use it. No human required at decision time.

Plugins need you. You install them. Configure settings. Tell the system when to use them. They're not built for autonomous reasoning—they're built for explicit human control.

3. How They Run

Skills get called dynamically based on context. The agent analyzes the conversation, decides a capability fits, invokes it automatically. The agent is driving.

Plugins often just run continuously—or wait for explicit activation. They don't reason about whether they're needed right now. They do what they're told, when they're told.

4. Semantic Understanding

This one's subtle but critical. Skills describe not just what they do, but when to use them.

Example: "Send an HTML email to a recipient with subject and body. Use this when the user asks to email something or send information." That second sentence? Pure gold. It tells the agent enough to make smart decisions without explicit commands.

Plugins rely on triggers. Click a button. Run a command. Set up an automation rule. The human provides the context; the plugin just executes.

How to write semantic descriptions that actually work →

5. Chaining and Composition

Skills are built to chain. Your travel agent can string search_flights → calculate_route → book_hotel into one seamless workflow. The agent reasons about the sequence, not just the individual steps.

Plugins usually stand alone. They might expose APIs, but they're not designed to be dynamically composed by AI based on user intent. The composition happens in the plugin's code—or in the human's head.

What the Big Frameworks Actually Do

Let's cut through the marketing and look at the code.

Microsoft Semantic Kernel

Semantic Kernel actually tries to clarify this mess. Their "plugins" are containers. Their "functions"—which everyone else would call skills—are the atomic units inside. A plugin groups related skills together. It's clean. It mostly matches where the industry's heading.

OpenAI Function Calling

OpenAI keeps it ruthlessly simple: "functions" in their API are essentially skills. Discrete. Declarative. Semantically understood. When you define a function for GPT-4, you describe when it should be called—not just what it technically does. That's the skill mindset in practice.

LangChain

LangChain straddles both worlds, which creates its own confusion. "Tools" work like individual skills. "Toolkits" group them together, similar to Semantic Kernel's plugin containers. Different vocabulary. Same underlying patterns.

Where This Is All Heading

The industry's converging on something that takes the best from both approaches:

• Semantic descriptions aren't optional anymore—they're table stakes
• Dynamic discovery beats static configuration for agent-driven workflows
• Standards like OpenAPI and JSON Schema let skills work across frameworks
• Security boundaries keep third-party code contained

What we're seeing is plugins rebuilt for an AI-native world. The packaging and sharing model still works—developers want to distribute capabilities, users want one-click installs. But the execution model is shifting hard toward semantic, composable skills that agents reason about and chain together.

The old plugin model won't disappear overnight. There's too much infrastructure. But for new AI agent development? Skills are winning.

So What Should You Build?

Skills. Definitely skills.

Design small, composable capabilities with rich semantic descriptions. Make them discoverable. Build for dynamic invocation, not manual configuration.

Quick audit of what you've got now:

• Is it designed for humans to configure, or for AI to invoke dynamically?
• Does it have semantic descriptions the agent can actually reason about?
• Can it chain into workflows with other capabilities?

If any answer is no, you've found your next refactor target.

The future is AI-native architecture. Build skills.

---

Part of our series on AI agent architecture. Also check out: How to Create Your First AI Agent Skill, Semantic Descriptions That Actually Work, and Building Composable AI Workflows.