Agent vs Skill vs Extension
Learn the practical difference between AI agents, agent skills, extensions, apps, plugins, connectors, and MCP servers, plus a governance checklist for safe rollout.
AI teams get into trouble when they collapse three different ideas into one fuzzy word: agent.
An agent is not the same thing as a skill. A skill is not the same thing as an extension. A connector is not automatically an agent. The distinction matters because each layer has a different job, owner, and risk profile.
The clean mental model:
- Agent: decides and coordinates.
- Skill: teaches a repeatable method.
- Extension: connects the agent to systems, data, tools, or interfaces.
If you separate those layers, your AI stack becomes easier to buy, build, secure, and improve.
Quick answer
An AI agent is the orchestration layer. It plans, calls tools, keeps state, and tries to complete multi-step work.
An agent skill is a reusable capability package. It gives the agent task-specific instructions, references, templates, examples, or scripts so the work becomes consistent.
An extension is the access layer. It lets the agent reach an external system, use a product surface, expose an app UI, or operate inside another workflow.
The simplest stack model
| Layer | Primary job | What it controls | Failure mode |
|---|---|---|---|
| Agent | Coordinate work | Plan, state, tool choice, handoffs | Wrong plan or unsafe autonomy |
| Skill | Standardize expertise | Instructions, examples, templates, helper scripts | Stale or unsafe process |
| Extension | Provide access | Systems, data, APIs, UI surfaces | Excessive permissions or untrusted data flow |
The mistake is buying one layer and expecting it to solve the others. A strong connector will not fix a weak agent. A beautiful skill will not help if the agent cannot access the right system. A powerful agent becomes dangerous if every extension is over-permissioned.
When you need an agent
Use an agent when the workflow needs judgment across multiple steps. OpenAI's Agents SDK docs describe agents as applications that plan, call tools, collaborate across specialists, and keep enough state to complete multi-step work. OpenAI's practical guide to building agents also frames agents as systems that independently accomplish tasks on a user's behalf.
That matters because an agent is not just a chatbot with a task prompt. A production agent usually needs:
- A clear role and operating instructions.
- Tool access.
- State or memory for the active job.
- Guardrails around unsafe or low-confidence actions.
- Handoffs to humans or specialist agents.
- Logs that show what happened.
Good agent workflows include vendor research, support triage, code changes, report generation, sales operations, procurement review, data cleanup, and back-office workflows where the system must choose between paths.
Do not start with an agent if the workflow is deterministic. If the job is "when a form is submitted, create a ticket," use conventional automation. Add an agent when the work needs planning, branching, judgment, or recovery.
When you need a skill
Use a skill when the agent already has the right tools but keeps improvising the process.
Skills package repeatable expertise. Claude Code's skill docs describe skills as instruction-centered packages with a required SKILL.md plus optional supporting files such as templates, examples, scripts, or references. Codex uses the same broad idea: skills give the agent the right workflow and context for a specific kind of task.
Strong skills are narrow:
| Weak skill | Strong skill |
|---|---|
| "Write better blog posts" | "Create a sourced buyer guide with a comparison table, risk checklist, internal links, and publishing metadata" |
| "Review code" | "Review a React pricing page for accessibility, responsiveness, and conversion clarity" |
| "Make slides" | "Turn an executive brief into a 10-slide board deck with risks, tradeoffs, and speaker notes" |
The test is simple: if two people can use the skill and get the same kind of output, the skill is doing real work.
Skills should be treated like operational assets. Version them, review them, keep dependencies visible, and remove stale ones. A skill can shape what an agent reads, writes, and runs, so it deserves more scrutiny than a casual prompt.
When you need an extension, app, plugin, or MCP server
Use an extension when the agent needs access.
This layer has several names depending on the platform:
- MCP server: exposes tools, resources, or prompts through the Model Context Protocol.
- ChatGPT app: an app experience inside ChatGPT, built on MCP and the Apps SDK.
- Codex plugin: a bundle that can include skills, app integrations, and MCP servers.
- Browser or IDE extension: an integration inside a browser or code editor.
- Connector: a link to a data source or business system.
MCP's docs define it as an open standard for connecting AI applications to external systems such as files, databases, tools, and workflows. OpenAI's MCP docs describe remote MCP servers as a way to connect models over the internet to new data sources and capabilities. OpenAI's Apps SDK adds an interactive layer: developers can define both app logic and interface inside ChatGPT.
This is the layer that turns an assistant into an actor. Once connected, the system may be able to read private data, call APIs, submit forms, send messages, edit files, or surface app-specific UI.
So the safe pattern is not "connect everything." The safe pattern is:
- Connect the minimum system.
- Expose the minimum actions.
- Prefer read-only access first.
- Require approval for writes.
- Log every meaningful action.
- Verify the provider and server identity.
OpenAI's MCP guidance is explicit that teams should prefer official servers hosted by the service provider and carefully review how servers use data. ChatGPT workspace MCP apps also use an admin-approved frozen snapshot of tools and inputs until an update is reviewed, which is exactly the kind of change-control mindset teams should copy.
Build, buy, or govern: the decision table
| Situation | Best first move | Why |
|---|---|---|
| The task has multiple steps and uncertain paths | Build or buy an agent | The system needs planning and recovery |
| The output is inconsistent across runs | Create a skill | The agent needs a repeatable method |
| The agent cannot access the work system | Add an extension, connector, app, or MCP server | The missing layer is integration |
| The workflow is deterministic | Use conventional automation | Autonomy adds unnecessary risk |
| The workflow touches sensitive data | Design permissions before adding autonomy | External access changes the blast radius |
| The team wants reusable AI workflows | Package skills and plugins | Reuse needs distribution and ownership |
Governance checklist
Before rollout, answer these questions:
- Who owns the agent's system instructions?
- Who can install or edit skills?
- Are skills reviewed before they are shared?
- Which extensions can read private data?
- Which tools are read-only by default?
- Which actions require approval?
- Is every MCP server or extension from a trusted source?
- Are tool schemas and permissions versioned?
- Are runs logged with actions, timestamps, URLs, and outputs?
- Can access be revoked quickly?
- Does the agent stop when confidence is low?
- Is there a human owner for exceptions?
Recommended rollout path
Start small:
- Pick one workflow.
- Write the skill first.
- Give the agent read-only access to one system.
- Run the workflow with human approval.
- Review logs.
- Add write actions only after the process is stable.
- Package the workflow for reuse.
The goal is not maximum autonomy on day one. The goal is reliable delegation: a system that knows what to do, follows the right method, accesses only what it needs, and leaves a trail your team can inspect.
FAQ
Is a skill just a prompt?
Not in a serious agent workflow. A prompt can be a one-off instruction. A skill is a reusable package that can include task instructions, examples, templates, references, and helper scripts.
Is an extension the same thing as an MCP server?
Not always. MCP servers are one important extension pattern, but "extension" can also mean a browser extension, IDE extension, ChatGPT app, connector, or platform plugin. The shared idea is external access.
Do I need all three layers?
For simple workflows, no. For production AI work, usually yes: an agent to coordinate, skills to standardize work, and extensions to access the systems where work happens.
What should a team govern first?
Govern extensions first because they control data and actions. Then govern skills because they shape behavior. Then tune the agent's autonomy as the workflow proves reliable.
Sources
- OpenAI Agents SDK: https://developers.openai.com/api/docs/guides/agents
- OpenAI practical guide to building agents: https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
- OpenAI MCP server guide: https://developers.openai.com/api/docs/mcp
- OpenAI Apps SDK announcement: https://openai.com/index/introducing-apps-in-chatgpt/
- OpenAI Developer Mode and MCP apps in ChatGPT: https://help.openai.com/en/articles/12584461-developer-mode-and-mcp-apps-in-chatgpt
- OpenAI Codex Skills: https://developers.openai.com/codex/skills
- OpenAI Codex Plugins: https://developers.openai.com/codex/plugins
- Claude Code Skills: https://code.claude.com/docs/en/skills
- Model Context Protocol introduction: https://modelcontextprotocol.io/docs/getting-started/intro