A prompt is a request you type. A saved prompt is that request kept for reuse, often with a few files. A skill is a packaged procedure (instructions, examples, scripts) the assistant loads only when a task matches it. An MCP server gives the assistant tools to read or change another system. An agent is a loop that plans and uses tools with nobody steering each step. An app is software with its own interface, data and users, where the model is one component. Use the lowest one that works, because each step up costs more to build and far more to keep alive.
The words get used loosely, which is how teams end up building an agent for a job a saved prompt would do. Below is each rung of the ladder with a working definition, what it costs, what breaks, and the signal that you've outgrown it. If you'd rather answer questions about your own task, the decision tool runs these definitions as rules.
1 Prompt2 Saved prompt3 Skill4 MCP / connector5 Agent6 App / system× Don't build
A prompt
A prompt is a single request to a chat assistant, with everything it needs pasted in. It costs nothing and takes minutes, and for a surprising share of work it's the right answer: summarising a document you'll read once, rewriting a paragraph, explaining an error, cleaning up one messy spreadsheet. Current assistants read files and images, run code and produce documents directly, so "one prompt" now covers jobs that needed a script two years ago.
The weakness is that a prompt lives in your head. Quality depends on how well you phrase it on the day, nobody else benefits from your wording, and if you notice yourself retyping the same instructions every week, you've found the signal to climb. A good prompt names the role, the task, the full input, the exact output shape you'll use, and one example of a good answer.
A saved prompt or custom instructions
A saved prompt is the same request kept somewhere you can reuse it, from a text snippet to a Claude Project, a custom GPT or a Gemini Gem with a few reference files attached. It takes under an hour and its whole value is consistency: the format you settled on, the style guide that always applies, the example that shows what good looks like.
It's still tied to one product and usually one person. A custom GPT can hold up to 20 knowledge files according to OpenAI's help centre, and a Claude Project keeps its files loaded in every chat inside it, but neither travels to another tool, and both drift without someone owning them. Google is also moving the ground under one of these: its help centre says Gems on personal accounts become read-only and convert to Gemini skills on November 17, 2026, and Workspace accounts follow in March 2027.
A skill
A skill is a folder with a SKILL.md file (a name, a one-line description of when to use it, then the instructions), plus whatever templates, examples or scripts the task needs. The assistant sees only the name and description of each installed skill until a request matches, then reads the instructions, and opens the extra files only if the instructions call for them. Anthropic's documentation describes that three-stage loading, and it's why skills scale where giant custom instructions don't: twenty skills cost almost nothing until one is needed.
Skills follow the open Agent Skills specification, so a skill written for Claude also works in other tools that adopt it. OpenAI says its ChatGPT skills follow the same standard, and Gemini now has skills of its own. That portability is the main reason to prefer a skill over a saved prompt once more than one person, or more than one tool, is involved.
A skill takes an afternoon: write the steps, add three examples, test it on real past cases, give it an owner. Where it runs out is reach, because it runs inside an assistant someone has opened, and it can only see what's pasted in, attached, or reachable through a connector. On Claude, skills run in the code sandbox, so code execution has to be on for them to work.
An MCP server or connector
The Model Context Protocol is an open standard for giving AI applications tools and data from other systems. An MCP server wraps a system (a CRM, a database, a ticket tracker, a file store) as a set of named tools the assistant can call, using that system's own permissions. "Connector" is what most assistants call an MCP server once it's installed in their interface.
You need one when the answer depends on data that changes, or when the task has to change something somewhere else. Copying CRM records into a chat works for a week and then someone pastes last month's export. The cost depends almost entirely on whether one already exists: turning on an official connector takes minutes, while writing your own server means designing tools, handling auth and keeping up with the other system's API. The official MCP Registry listed 52,715 active servers when we counted its public API on October 31, 2026, so check before you build.
What's new here is the risk, since a connector with write access can do damage at the speed of a prompt, and the person typing may not realise which tool will fire. Start read-only, use a service account with narrow scopes, and pair the connector with a skill that says how to use the tools for this particular task.
An agent
An agent is a loop: it gets a goal, plans, calls a tool, reads the result, decides the next step and keeps going until it's done or has to ask. What makes it an agent is that nobody steers each step. Most useful agents also start by themselves, on a schedule or an event: a lead arrives, a ticket is filed, it's Monday at 9am.
That autonomy is the point and the cost. Errors compound across steps, the cost per run varies, and when something goes wrong at 3am you need logs to find out what it did. Building one well takes days to weeks, mostly spent on limits (spend, steps, which actions always need approval), on a test set of past cases, and on observability. If the steps never change, you don't need an agent at all: a scheduled workflow with one model call does the same job more predictably.
Coding agents are the most mature example. Claude Code, Codex and Cursor's agents plan changes, run tests and iterate in a repository, which is why so many "should we build an agent" conversations end with "can a coding agent run this in CI?"
An app or system
An app is software with its own screens, data model, users, permissions and tests, where the model is one component. You need one when people outside the team use it, when it needs records and an audit trail, when it runs hundreds of times a day, or when a wrong answer moves money with nobody reviewing it. None of the lower rungs can give customers a login, rate limits, billing and support.
It's also the most expensive rung by a distance, mostly in upkeep: once it exists, someone maintains it forever. Prototype the interface with an AI app builder to test it with users before you commit, and check whether a vendor already sells 80% of it.
When not to build anything
Sometimes the right rung is off the ladder. If a tool you already pay for ships the feature (accounting software that learns expense categories, an email client that drafts replies, a help desk with AI answers), turning it on beats building anything. If the task is a one-off, high-stakes change to another system, do it by hand with a checklist and use an assistant to review your plan. Three of the 38 tasks in our pattern library land here.
Side by side
| Prompt | Saved prompt | Skill | MCP server | Agent | App | |
|---|---|---|---|---|---|---|
| What it is | One request | A reusable request plus a few files | A packaged procedure, loaded on demand | Tools that reach another system | A loop that plans and acts | Software with the model inside |
| First version | Minutes | Under an hour | An afternoon | Minutes if one exists, days if not | Days to weeks | Weeks to months |
| Who maintains it | Nobody | You | A named owner | Whoever owns the credentials | An owner with logs and evals | A team or a vendor |
| Sees live data | Only what you paste | Only attached files | Only what's attached or connected | Yes | Yes, through tools | Yes |
| Takes actions | No | No | Through connectors or code | Yes | Yes, unattended | Yes |
| Shareable | Copy and paste | Within one product | Across a team, and across tools that read the format | Across a workspace | Runs for everyone | Anyone you give access |
| Typical failure | Inconsistent wording | Goes stale | Loads when it shouldn't, or doesn't load | Wrong permissions, API changes | Compounding errors, runaway cost | Built when a skill would do |
| Example | Explain this clause | Weekly status update | Brand-voice rewriter | Read-only warehouse connector | Inbound lead triage | Invoice matching with approvals |
Effort ranges are our estimates from building these for clients, not measurements, and they assume the first working version, not a hardened one.
The combinations that work
Real setups mix rungs, and the strongest pattern is a connector plus a skill. The connector answers "can the model see it", the skill answers "does it know what to do with it", and together they cover most of what teams first describe as an agent. Anthropic packages the two as plugins, and a sales call brief, a weekly KPI report or a support reply draft all fit that shape.
The next most common is a skill run on a trigger, which turns a person-started procedure into an agent without rewriting it. And at the top, the best apps keep their prompts in skills too, so the people who know the domain can improve the instructions without a deploy.
The question none of this answers is whether the thing you're building is worth anything to someone who could build it too. The Moat Line is about that.
Questions people ask
Is a Claude skill the same as a custom GPT?
They overlap but work differently. A custom GPT is a configured assistant you open and chat with, with instructions and up to 20 knowledge files. A skill is a folder of instructions, files and optional scripts that the assistant loads by itself when a task matches its description, inside whatever conversation you're already in, and it follows an open format that other tools also read.
Do I need an MCP server to use my own data with AI?
Only if the data changes or lives in another system. Static reference material (a style guide, a policy, templates) can be attached to a project or packed into a skill. Data that changes, like CRM records, tickets or a database, needs a connector or MCP server so the model reads the current version with the right permissions.
What makes something an agent rather than a workflow?
An agent decides its own next step. It plans, calls a tool, looks at the result and chooses what to do next until it's done or stuck. A workflow runs fixed steps in a fixed order, even if one step calls a model. If your steps never change, a workflow is cheaper and easier to trust.
Can a skill and an MCP server work together?
Yes, and that's the most common good setup. The connector gives access (read the CRM), and the skill gives the method (how to turn account history into a one-page call brief). Anthropic's plugins bundle the two for exactly this reason.