A few years ago I sat with a team that had spent six weeks building an "agent" to pull totals and due dates off vendor invoices. It had a planning loop, a tool for reading PDFs, a memory of past invoices, and a retry policy for when it got confused. It got confused often. The fix took one afternoon: a regex and a date parser. There was no judgment to make. The agent hadn't failed because the model was weak. It failed because nobody had asked, before writing a single prompt, what kind of task this actually was.
That question is the first real skill of applied AI, and it is the one most practitioners skip. Not prompt engineering, not model selection, not tool orchestration. Classification. Before you build anything, you need to know whether the job in front of you is a script, a bounded prompt, or a genuine agent. Get that wrong and everything downstream — cost, speed, reliability, and how much you can trust the output unsupervised — gets wrong with it.
In my work I've come to treat these as three distinct categories, not three points on a spectrum. Each has a different build, a different price, and a different failure mode.
1. The Deterministic Task — a script
Some tasks have no judgment in them at all. The rules are complete, the inputs are structured enough to parse, and the acceptance criteria never branch. Pulling a total and a due date off an invoice is one. Renaming files by a fixed pattern is another. Routing a webhook payload based on a status field is a third.
The one-line test: if the acceptance criteria fit in a single sentence and the steps never branch, it's a script. No exceptions, no "usually," no edge case that needs a human read.
An LLM here doesn't add capability. It adds latency, cost, and a new way to be wrong. A regular expression does not hallucinate a due date. It either matches the pattern or it fails loudly, which is exactly the behavior you want from something you're about to automate. The craft skill isn't resisting AI out of purity — it's recognizing that some problems were already solved, cheaply and completely, before generative models existed.
2. The Bounded Judgment Task — a prompt
The next tier is where language models genuinely earn their place. The task requires judgment — real interpretation, not rule-matching — but the shape of the work is still fixed. One input arrives, one output is produced, and the job is done. No memory carried forward, no tool calls, no loop deciding what to do next.
Sorting an inbound support ticket into a fixed set of categories is the clean example. A human reading the ticket would use judgment — urgency, tone, intent aren't always explicit — but the decision space is closed. There are five categories, or eight, and the ticket lands in exactly one of them. Drafting a first-pass reply from a template, scoring a lead against fixed criteria, extracting sentiment from a review: all bounded judgment, all a single LLM call.
The one-line test: if the call takes one input, returns one fixed-shape output, and never loops back on itself, it's a prompt, not an agent.
This is the category most teams either underuse or over-build. Underuse it by writing brittle rule trees to approximate judgment a model handles cleanly in one call. Over-build it by wrapping a simple classification in an agent framework with tools it never uses and memory it never needs. Both mistakes come from the same root cause: not naming the task correctly first.
3. The Open-Ended Judgment Task — an agent
The last category is the one everyone reaches for first, and it's the one that should be earned last. A genuine agent is warranted when the work has multiple steps that aren't known in advance, when the next action depends on what the last one turned up, and when the task involves real tool use — searching, reading, comparing, deciding what's even worth looking at.
Researching a competitor's pricing across their site, their app store listing, and a few review threads, then deciding what's relevant and drafting a follow-up recommendation — that's an agent-shaped problem. Nobody can specify the exact sequence of searches in advance. The work branches based on what it finds. And critically, it's the kind of task a competent human would supervise anyway rather than trust blindly, which tells you something important: agents aren't for tasks where you want to remove oversight. They're for tasks that never had unsupervised, single-pass answers to begin with.
The one-line test: reserve "agent" for work that is genuinely multi-step, branches on intermediate results, and uses tools — not for anything that merely feels sophisticated.
The tradeoff that should decide your default
Once you can name the three types, the build decision mostly makes itself, because the categories carry a strict cost and reliability ordering. Scripts are nearly free and fully predictable — the output today will match the output next year, given the same input. Prompts are cheap and mostly reliable — a single well-specified call, evaluated against a rubric, will be right the overwhelming majority of the time, and wrong in ways you can measure. Agents are the slowest, the most expensive, and the least predictable of the three, by nature of what makes them useful: they make sequential decisions you didn't fully specify in advance.
None of that makes agents bad. It makes them a tool you reach for deliberately, not by default. The actual craft — the part that separates a practitioner from someone who's simply comfortable typing into a chat window — is resisting the agent until the task has genuinely earned it. Most of what crosses your desk hasn't. It's a script wearing an agent's clothes, or a prompt someone was afraid to call a prompt.
Classify first. Build second. The model was never the hard part.
