Do Not Blame Yourself for Forgetting. These Terms Really Are Too Similar#
After using AI tools for a while, many people run into the same confusion: what is the difference between a Prompt, MCP, Skills, Commands, Agent, and Subagent? They all seem to “tell AI what to do,” but in real workflows they solve different layers of the problem.
The simplest way to remember them is this: Prompt tells the model what to do right now; Skill teaches it how to do a repeated task; MCP lets it touch the outside world; Command turns a frequent prompt into a shortcut; Agent closes the loop and executes; Subagent splits work away from the main context.
1. Prompt: The Temporary Instruction We Use Most Often, but It Is Naturally Unstable#
A Prompt is the most direct form of instruction. You type a requirement into the chat box, such as “summarize this paper,” “write a script,” or “revise this paragraph.” It is flexible and has almost no engineering cost.
The weakness is also obvious: a prompt is temporary. It depends on the current conversation context, your wording, the model’s interpretation, and any forgotten constraints. If you use the same prompt today and tomorrow, the result may still vary.
Use prompts when the task is one-off, lightweight, exploratory, or not yet worth turning into a stable workflow.
2. MCP: It Does Not Teach the Model How to Work; It Lets the Model Reach External Tools#
MCP is not a prompt library and not a workflow rule. It is a tool bridge. Through MCP, a model can access external capabilities such as browsers, file systems, databases, GitHub, search, documents, or custom APIs.
Its role is closer to “connecting hands and eyes” for the model. Without MCP, the model can only reason from context. With MCP, it can inspect a page, call an API, read a file, or operate a browser if the environment allows it.
Use MCP when the task requires external state, live data, UI operation, repository inspection, or tool execution. Do not use MCP to describe process discipline; that belongs to Skills or workflow instructions.
3. Skills: Preserve the Correct Way of Doing Things and Make Team Output More Consistent#
A Skill is a reusable workflow package. It usually contains trigger conditions, constraints, step order, evidence requirements, and sometimes scripts or reference files. Its purpose is not merely to say “do X,” but to define how X should be done correctly.
For example, a paper-review skill can require source-grounded summaries, methodology critique, novelty checks, and reproducibility notes. A browser-QA skill can require DOM inspection, console checks, network checks, and screenshots. These rules make output more consistent across sessions and agents.
Use Skills when a task appears repeatedly, has a standard process, and can fail if the process is skipped.
💡 One-Glance Difference: Skills vs MCP#
| Dimension | Skills | MCP |
|---|---|---|
| Main role | Workflow and method | Tool access and external capability |
| Solves | How to do the task | What the model can touch |
| Typical content | Steps, constraints, evidence rules | Tool endpoints, commands, resources |
| Reuse value | High for repeated workflows | High for external integrations |
| Failure mode | Wrong method or skipped checks | Missing capability or bad tool call |
4. Custom Commands: Turn Frequent Prompts into Shortcuts#
A custom command is usually a named shortcut for a high-frequency instruction. Instead of typing the same long prompt every time, you trigger a command such as /review, /build, or /summarize.
Commands are convenient, but they are not automatically the same as Skills. A command may only expand into a prompt, or it may route to a deeper workflow. The key difference is that a command is an entry point, while a Skill is the method behind the task.
Use custom commands when a repeated instruction needs a quick invocation path. If the command becomes complex and needs strict behavior, turn the logic behind it into a Skill.
5. Agent: The Closed Loop That Actually Starts Working, Not a Larger Prompt#
An Agent is not just a long prompt. It has a loop: understand the goal, plan actions, call tools, observe results, revise the plan, and continue until done or blocked. This is why agents are useful for coding, research, debugging, testing, and multi-step operations.
The value of an agent is autonomy. The risk is drift. If the goal, scope, verification, and stop conditions are unclear, an agent may confidently do the wrong thing for a long time.
Use an Agent when the task requires multi-step execution, tool use, adaptation, or verification. Keep constraints explicit, especially edit scope, acceptance criteria, and evidence requirements.
6. Subagent: Save the Main Conversation from Becoming an Information Dump#
A Subagent is a separate worker used to isolate a task from the main context. It can investigate a code area, run a review lane, inspect a test failure, or perform a bounded research task without filling the main conversation with every detail.
Its biggest value is context isolation. The main agent receives a compact evidence summary instead of raw exploration noise. This is especially useful when several independent tasks can run in parallel or when one research path may be long.
Use Subagents for bounded, separable work. Do not use them when the task is small enough to handle directly, or when the main agent must personally inspect the final files before editing.
Quick Decision Matrix#
| If you need… | Use… |
|---|---|
| A one-time instruction | Prompt |
| A stable repeated workflow | Skill |
| Access to external tools or data | MCP |
| A shortcut for frequent operations | Custom Command |
| Autonomous multi-step execution | Agent |
| Isolated parallel or delegated work | Subagent |
The Relationship Between Them#
These concepts are not mutually exclusive. A command can trigger a skill. A skill can instruct an agent. An agent can call MCP tools. A main agent can dispatch subagents. A prompt can still be used inside any of these layers.
The problem starts when we use the wrong layer for the wrong job. If a task only needs a one-time answer, a prompt is enough. If the task requires repeatable quality, use a Skill. If the task requires external data, add MCP. If the task needs autonomous execution, use an Agent. If the context becomes too large or tasks can be separated, use Subagents.
My Practical Rule#
- If I only need to say something once, I write a Prompt.
- If I will do it many times and care about consistency, I make it a Skill.
- If the model needs to touch something outside the chat, I configure MCP.
- If I type the same instruction often, I make a Command.
- If the task needs a loop of action and verification, I use an Agent.
- If the task would pollute the main context, I split it into a Subagent.
Once you separate these layers, the whole AI tool ecosystem becomes much easier to understand. They are not competing buzzwords. They are different parts of the same workflow stack.
