How Claude Distinguishes Prompts, Skills, Tools, and Subagents
Claude's public guidance distinguishes a one-time prompt, a reusable skill, tool or MCP access, and a scoped subagent by the job each layer performs.
This article synthesizes public Anthropic and Claude engineering material with Gwarket's analysis of verifiable AI workflows. It is not Anthropic documentation or a product commitment.
“Build me an agent” is often an unfinished requirement. The person asking may need a one-time instruction, a reusable procedure, access to data, or an isolated worker for a bounded task. Calling every layer an agent makes it harder to solve the right problem.
| Building block | What it provides | When it helps |
|---|---|---|
| Prompt | What to do right now | A one-off task or immediate adjustment |
| Skill | A repeatable way of working | A stable method, format, or domain rule |
| Tool | A capability the AI can operate | Reading files, searching, writing, calling a system |
| MCP | A connection to external data and tools | Persistent access to a repository, database, or business system |
| Subagent | Independent execution in a separate context | Research branches, independent review, or parallel work |
Ask what is missing first
If you keep repeating “use this structure, show uncertainty, and do not overclaim,” you probably need a Skill rather than another agent. The work has become a repeatable procedure.
If the AI cannot access a folder, current database, or project tool, a longer prompt will not fix that. The missing layer is a tool or a connection such as MCP.
If the main task is being overwhelmed by a large research branch, or you need a clean perspective to review a result, then a subagent can be appropriate.
Anthropic makes the same distinction in its explanation of these building blocks: a Project provides background context; a Skill teaches a procedure; MCP connects to external systems; a subagent independently performs a scoped task.
Four common mismatches
Treating repeated prompts as personal discipline
Repeated instructions are often a signal that the procedure belongs in a reusable skill or project rule. Otherwise every new session begins with a fragile manual reminder.
Using a longer prompt to compensate for missing data
Prompting cannot grant access to information the model cannot see. First solve the data and permission boundary. Then decide how the model should use it.
Putting every procedure into a Project
A Project is useful for what a body of work is: its history, documents, readers, and shared context. It is not the best place for every operational rule. If every task must load every procedure, the context becomes heavy and less relevant.
Creating a subagent because the task feels important
A subagent needs a return contract: a specific question, bounded inputs, tool limits, and an output another worker can use. “Think again and find a better answer” is not a contract. It is a duplicate of an unclear task.
A practical sequence
Start with a prompt to prove that a task is useful. When the method repeats, capture it as a Skill. When manual data transfer becomes the constraint, add a tool or MCP connection. When the work genuinely needs isolation, specialization, or parallel execution, add a subagent.
This order keeps the system small enough to understand. It also makes it possible to remove a layer when it stops adding value. Especially for an individual or small team, that reversibility matters more than copying the architecture of a large organization.
Before adding anything, ask three questions: Is this one-time or repeatable? Is the missing piece method, background, or access? Can a delegated worker return a clearly usable deliverable? Most vague “agent” requests become much easier after those questions.