Most AI build decisions go wrong in one of two directions. Teams build an app for something a saved prompt would handle, or they hand a one-line prompt a job that needs permissions, an audit trail and an approval step. The tool below sorts a task onto the cheapest rung that fits, and shows you which answer forced it higher.
How the tool decides
Each answer can set a floor: the lowest rung the task can live on. The verdict is the highest floor any answer sets, and the rules that set it are the ones marked as deciding in your result. Two answers can override the ladder entirely and return "don't build it". There's no weighting, no scoring and no model call, so you can check every verdict against the table.
| If you answer | The floor becomes | Because |
|---|---|---|
| It happens once | Prompt | Packaging a one-off costs more than it saves |
| It repeats at all | Saved prompt | The wording is worth keeping |
| Weekly or more, stable steps, shared or daily | Skill | A written procedure with examples loads on demand |
| Reference material, used daily or by others | Skill | Instructions and files stay together and versioned |
| Reference material, just you, occasionally | Saved prompt | Attach it once to a project or custom instructions |
| Produces files, repeatedly | Skill | Templates and scripts keep the format identical |
| A team or many teams use it | Skill | One owned definition, shareable by admins |
| Needs live or private data | MCP server / connector | The model can't see it without a tool |
| Must change things in other systems | MCP server / connector | Actions need tools with real credentials |
| Many teams plus live data or actions | MCP server / connector | One managed connector, not personal keys |
| Runs on its own and touches data, or varies | Agent | Plan, call tools, check, repeat, unattended |
| Open-ended, repeats, works across systems | Agent | It must act and verify over several steps |
| Open-ended, repeats, only needs the web | Skill | Method plus a research-capable assistant |
| Needs its own screens, records or audit trail | App / system | That's software with the model inside it |
| Customers or the public use it | App / system | They need auth, limits and support |
| Hundreds of runs a day or real time | App / system | Queues, retries, cost control, monitoring |
| High cost of error, and it acts or runs unattended on live data | App / system | Approvals, logs, tests and rollback |
| A tool you already pay for does it | Don't build | Configure what you have first |
| One-off, high-stakes change to another system | Don't build | Do it by hand with a checklist |
Some answers add a note without moving the rung. High-stakes work always gets a reminder to keep a person approving outputs until you have a test set and know the error rate. A scheduled task with fixed steps gets told that a plain scheduled workflow (cron, n8n, Zapier, Make) with one model call is cheaper and more predictable than an agent. "Partly covered by a tool I have" tells you to check that tool's own AI features before you build the gap.
Why the ladder starts so low
I run a studio that builds web and AI products for clients, and the most useful thing I do on a first call is often talk someone down a rung or two. A request arrives as "we need an AI app for our proposals" and turns out to be a skill: a template, a rate card, three good past proposals and a page of instructions, which takes an afternoon and costs nothing to run beyond the assistant subscription the team already pays for. The app version would have taken weeks, and nobody would have kept the prompts inside it up to date.
The pull upward is real, though, and the tool respects it. If the inputs live in your CRM, copying them into a chat every time is how mistakes and stale data get in, so the floor rises to a connector. If a person shouldn't have to press go, it's an agent. If customers touch it, or a wrong answer moves money, you're building software whether you meant to or not, and pretending otherwise just means building it badly.
The rungs in order, with what each one costs to build and keep alive, are laid out in prompt vs skill vs MCP server vs agent vs app. The pattern library runs 38 common tasks through these same rules, so you can see the reasoning on cases like yours before you answer for your own.
What the tool can't tell you
It doesn't know your stack. A verdict of "MCP server" assumes a connector exists or can be built for the system you named; the registry comparison shows where to look. It doesn't price anything, because the cost of a skill or an agent depends far more on how often it runs and which model it uses than on the rung. And it says nothing about whether the idea is defensible if you're building it to sell. For that half of the question, read the Moat Line.
Questions people ask
Does the decision tool use AI to make its verdict?
No. It applies a fixed set of rules, published on this page, to your eight answers. The same answers always give the same verdict, and nothing you enter leaves your browser.
Why does the tool prefer the cheapest option?
Every rung up the ladder adds build time and, more importantly, upkeep. A skill needs an owner, a connector needs credentials managed, an agent needs logs and evals, an app needs a team. The tool climbs only when one of your answers makes the cheaper rung fail.
What's the difference between a skill and an MCP server?
A skill is instructions and files that tell the assistant how to do a task. An MCP server gives the assistant tools to reach another system, such as reading your CRM or writing to your tracker. Many good setups use both, a connector for access and a skill for the method.
When should I build an agent instead of a skill?
When nobody should have to press go. If the task must run on a schedule or an event and pull data or take actions on its own, it's an agent. If a person starts each run, a skill plus a connector usually does the same work with less risk.