What's the difference between an AI skill, tool, plugin, and integration?

A skill is a recipe. A tool is a kitchen appliance. A plugin is a packaged kitchen kit shipped from a vendor. An integration is the gas line connecting your stove to the city.

If you only take one thing away from this article, take that. Most of what follows is footnotes and elaboration. The rest is a quick reference for when those four words start meaning the same thing in conversation.

I spend a lot of time in conversations where someone says “tool” and means three different things in the same paragraph. Or where “plugin” and “integration” are used interchangeably until a technical decision hangs on the difference and nobody can articulate what the difference actually is. Last month a team I was working with spent two days “fixing the agent” by adding more tools to it, when the actual problem was that no skill encoded which tool to use when. They were solving a skill problem at the tools layer. The agent already had everything it needed; what was missing was the recipe.

Defining four terms precisely (skill, tool, plugin, integration) doesn’t solve every team’s confusion, but it does mean you can name what’s actually broken when something goes wrong. These definitions are opinionated and other people will disagree. Having a clear mental model matters more than having the “correct” one.

For one-line definitions of each term in isolation (plus prompt, system prompt, agent, function calling, action, MCP, and the rest of the vocabulary), see the agent skills glossary. This article is the longer essay treatment.

Skills: the recipe

A skill is a markdown instruction file that tells an agent what to do. It’s the recipe. It encodes judgment: what steps to follow, in what order, under what conditions, with what tradeoffs.

A skill does not execute anything. It doesn’t call APIs. It doesn’t write files. It doesn’t send messages. It describes a process that an agent follows, and the agent uses other capabilities to actually carry out the steps.

What makes a skill different from a prompt: a skill is reusable, structured, and designed to produce consistent behavior across many invocations. A prompt is a one-off instruction. A skill is a codified workflow. For more on this distinction specifically, see prompt engineering vs skill design, and for the structural anatomy of a single skill file, how to design AI agent skills.

A concrete example: a code review skill might contain instructions like “read the diff, check for security issues, verify test coverage, check naming conventions, leave comments in a specific format.” The skill doesn’t read diffs or leave comments itself. It tells the agent to do those things, and the agent uses tools to execute each step.

Skills are the layer where domain knowledge lives. An experienced code reviewer’s judgment, a senior marketer’s editorial instinct, an ops engineer’s debugging process. These get encoded as skills. The tools are the same for everyone. The skills are what make the agent actually good at something.

A note on the word itself: “skill” as a markdown-recipe layer is this site’s framing for designing agent behavior. It’s not a documented product term in the public API surface of any major vendor (Anthropic, OpenAI, and Google all describe their feature set in terms of system prompts, tools, and assistants). The skill concept is a useful pedagogical construct; treat it as a layer in your mental model, not a vendor primitive you’ll find in their docs.

Tools: the hands

A tool is a function that an agent can call. It’s the hands. Read a file, search a codebase, make an HTTP request, run a shell command, query a database. A tool does one thing and returns a result.

Tools have no opinions. A file search tool doesn’t know whether you should be searching for TypeScript files or Python files. A database query tool doesn’t know which table contains the data you need. Tools execute. They don’t decide.

The relationship to skills is the recipe-and-knife relationship from the opening. The recipe says “chop the onions.” The knife does the chopping. The recipe encodes the judgment (which onions, how fine, when in the process). The knife just cuts.

In practice, tools are defined with a name, a description, and a parameter schema. The agent reads the tool descriptions, matches them against what the skill is asking it to do, and calls the appropriate tool with the appropriate parameters. The descriptions are doing more work than people realize: vague descriptions cause wrong-tool selection, and that’s expensive both in correctness and in compute. See the cost of bad descriptions for the longer treatment, and how skills use tools for the deeper mechanism.

Tools are the boundary between the agent’s reasoning and the outside world. Everything the agent “does” happens through tools. Without tools, an agent can only think and write text. Tools give it the ability to act.

Plugins: the bundle

A plugin is a platform-specific extension that bundles tools (and sometimes configuration, persona, or context) into a package that can be installed and used within a particular system.

The key word is “platform-specific.” A plugin is designed for one environment. A VS Code extension works in VS Code. A Slack app works in Slack. ChatGPT had plugins, then deprecated them in favor of GPTs (a packaged-agent format including system prompt + tools + knowledge files), and then introduced Custom Actions (OpenAPI-defined tool packages installable into a GPT). Anthropic’s Claude has desktop extensions. Each ecosystem has its own packaging format and its own marketplace.

A plugin typically includes several related tools grouped around a theme. A “GitHub plugin” might expose tools for reading issues, creating pull requests, searching code, and managing labels. Each of those is a separate tool. The plugin is the container that bundles them together, handles authentication, manages configuration, and presents them to the platform.

Plugins also carry metadata: icons, descriptions, permission scopes, pricing tiers. They’re products, not just capabilities. Someone built them, packaged them, and published them for others to install. This packaging layer is what separates a plugin from a raw collection of tools.

The limitation of plugins is portability. If you build for one platform, you’re coupled to that platform. If the platform changes its plugin API (which has happened repeatedly across the major vendors), your plugin breaks. Your investment in building for one ecosystem doesn’t transfer to another.

Plugins and skills are not the same layer. A plugin is something a vendor or third-party developer ships from a marketplace. A skill is something a user authors and copies into their own project. They don’t replace each other; they sit at different layers of the stack.

Integrations: the bridge

An integration is a connection between two systems. It’s the bridge. Where a tool is a single function call, an integration is the plumbing that makes that function call possible across system boundaries.

An integration with Slack means your system can read Slack messages, post to channels, manage users. An integration with GitHub means your system can access repositories, trigger workflows, read commit history. The integration handles authentication, API versioning, rate limiting, error recovery, and data transformation.

Integrations are lower-level than plugins. A plugin uses integrations under the hood. The “GitHub plugin” relies on a GitHub integration (OAuth tokens, API client, webhook handling) to actually talk to GitHub’s API.

You can have an integration without a plugin. Many production systems connect to external services through direct integrations without any plugin layer. You can also have a plugin without building the integration yourself, because the plugin author already built it and packaged it for you.

The distinction matters when you’re deciding what to build. If you need your agent to access a specific API, you need an integration. If you want to package that access for others to use on a specific platform, you need a plugin. If you want the agent to use that access intelligently as part of a workflow, you need a skill.

How the layers relate

The four concepts form a stack. Not a rigid hierarchy, but a set of layers that build on each other.

At the bottom is the integration: the connection to an external system, handling auth, API calls, and data formats. On top of that sits the tool: a specific capability from the integration (or from the local environment) wrapped into a function the agent can call. The plugin layer above that bundles related tools together with metadata and configuration for a specific platform; not every system needs a plugin layer, but it’s where ecosystem packaging lives. The skill is at the top, orchestrating tools (whether they come from plugins, integrations, or the local environment) into a coherent workflow that encodes domain judgment.

A real example: you want your agent to review pull requests and post comments on GitHub.

• The integration is the GitHub API connection: OAuth token, REST client, webhook listener.
• The tools are individual functions: get_pull_request, list_changed_files, read_file_contents, post_review_comment. (These names are illustrative; your tool registry’s actual names will vary.)
• The plugin (if one exists for your platform) bundles those tools and handles GitHub auth configuration.
• The skill is the markdown file that says: “When reviewing a PR, first read the description, then examine each changed file, check for security issues and style violations, and post comments using a specific format with severity levels.”

The skill is useless without the tools. The tools are useless without the integration. But the skill is where the value is, because two different skills using the same tools will produce completely different reviews. The tools don’t change. The judgment changes.

Why the industry can’t agree on names (as of mid-2026)

The vocabulary is fragmented because every vendor introduced their own term before anything stabilized. As of mid-2026, here’s the rough state of play; expect it to drift.

OpenAI shipped ChatGPT plugins in 2023, deprecated them in favor of GPTs (a packaged-agent format) in 2024, and now positions Custom Actions (OpenAPI-defined tool packages installable into a GPT) as the way to add capabilities. A GPT is closer to a packaged agent than to a skill: it bundles a system prompt, tool access, and optional knowledge files into a configurable persona. The skill layer in this site’s framing maps roughly to the system-prompt portion of a GPT, not to the GPT as a whole.

Anthropic’s API surfaces tools (via the tool_use mechanism), system prompts, and projects. There’s no documented “skills” concept in their public docs; the markdown-recipe layer this site calls a skill is a pedagogical construct, not a vendor primitive.

Google calls them “extensions” in Gemini. Microsoft calls them “plugins” in Copilot but means something different from what OpenAI meant by “plugins.” LangChain calls them “tools” and uses the word to cover everything from simple functions to complex integrations.

MCP, the Model Context Protocol, is an open protocol originally developed by Anthropic and increasingly adopted by other platforms. It standardizes the tool layer by defining a common format for tool descriptions and invocations, but it’s one of several standards (alongside OpenAPI specs, custom function schemas, and vendor-specific formats), not the canonical one. MCP doesn’t have opinions about skills, plugins, or integrations; it defines the tool contract and leaves the rest to each platform. For practical use, see building skills with MCP.

Each company has incentives to use terminology that makes their platform sound unique. “We have plugins” sounds more product-shaped than “we have tool definitions,” even when the underlying capability is similar.

Why the distinction matters in practice

When the terminology is fuzzy, real problems follow.

I’ve watched teams try to solve a skill problem by building more tools. Their agent had access to every API it needed, but it used the APIs poorly because nobody wrote the skill that encodes the judgment about when and how to use them. More tools didn’t help. Better instructions would have.

I’ve also watched teams try to solve a tool problem by writing better skills. Their skill instructions were perfect, but the agent couldn’t execute them because the underlying tools were missing, broken, or poorly described. No amount of workflow design fixes a missing capability.

Knowing which layer is broken saves you from building the wrong thing. If the agent does the right steps in the wrong order, that’s a skill problem. If the agent tries to do the right thing but the API call fails, that’s an integration problem. If the agent picks the wrong function to call, that’s a tool description problem (read the cost of bad descriptions). If you can’t install the capability you need in your platform, that’s a plugin problem.

The terms matter less than the layers

I don’t care if you call a skill a “prompt template” or a “workflow definition” or a “system instruction.” I don’t care if you call a tool a “function” or an “action” or a “capability.” The words are less important than understanding that these are separate concerns operating at different levels.

The instruction layer (skills) tells the agent what to do and why. The execution layer (tools) gives the agent the ability to act. The packaging layer (plugins) makes tools installable and configurable on a platform. The connection layer (integrations) handles communication between systems.

When you’re building an AI system, thinking in these layers helps you decompose problems, divide work, and debug failures. When you’re evaluating someone else’s AI system, understanding these layers helps you see past the marketing terminology and understand what’s actually happening.

The next time someone tells you about their amazing new AI plugin, ask them: is it a plugin, a tool, a skill, or an integration? If they can’t answer clearly, they probably haven’t separated the concerns. And systems with muddled layers are systems that are hard to maintain, hard to debug, and hard to extend.

Clarity in terminology is clarity in thinking. Even if the industry never agrees on the words, you can have a clear mental model. That’s enough.