One Prompt or an Agent? A Test That Holds Up

"Should this be an agent?" is the most over-answered question in applied AI right now, and the answer is usually no. Agents are genuinely powerful for a specific class of problem and a liability everywhere else. The trouble is that they demo beautifully, so teams reach for them reflexively and then spend a quarter making something reliable that a single prompt would have done on the first try.

Let me define terms, because the word "agent" has been stretched to mean almost anything. A single prompt is one model call: input in, output out, done. It can be sophisticated, using tools or structured output, but it runs once and the control flow is yours. An agent is a loop where the model decides what to do next: it picks a tool, sees the result, and chooses the following step, repeating until it judges the task complete. The defining feature is that the model, not your code, controls the sequence.

The test

Here is the question that actually separates the two cases. Do you know the steps in advance?

If you can write down the sequence of operations before the task runs, you don't need an agent. You need a prompt, or a chain of prompts wired together by your own code. Extracting fields from a contract, summarizing a document, classifying a ticket, translating text, drafting a reply: the steps are fixed. You know exactly what happens and in what order. Encoding that as an agent hands control of a deterministic process to a nondeterministic decision-maker, which buys you unpredictability for nothing.

If the steps genuinely depend on what earlier steps discover, and you can't enumerate them ahead of time, that's where an agent earns its keep. "Investigate why this deploy is failing" might need to read logs, then check a config, then query a service, then read different logs, in an order that depends entirely on what each step reveals. You cannot write that flow in advance. A coding assistant like Claude Code or Cursor's agent mode is exactly this: it explores a codebase, and what it reads next depends on what it just found.

Try the boring version first, always

Before building an agent, spend an hour seeing how far one well-constructed prompt gets you. People consistently underestimate this because their first prompt was lazy. A prompt with a clear role, explicit rules, a few examples of the exact output you want, and the relevant context inlined will solve a surprising share of tasks that people assume need orchestration.

system: |
  You are a code reviewer. Given a diff, return findings as JSON.
  Only flag: security issues, obvious bugs, and broken error handling.
  Do NOT flag style, naming, or opinions. If nothing qualifies,
  return an empty array. Each finding: {file, line, severity, issue}.

# one call, deterministic output shape, trivially testable

This is not an agent and it doesn't need to be. It runs once, returns a validated structure, and you can write a test for it. If it handles 85% of your cases, you're done, and the 15% might be better sent to a human than to a loop you'll spend weeks hardening.

What a chain buys you over an agent

There's a middle ground people skip: multiple model calls that you sequence in code. This is different from an agent because you own the control flow. Say you're building a feature that answers questions over a knowledge base and then drafts an email. That's two steps, and you know both:

// You control the sequence. Each step is testable in isolation.
const facts = await retrieveAndSummarize(question);   // call 1
const draft = await composeEmail(facts, tone);        // call 2
// no loop, no model deciding what happens next

You get most of the benefit people want from agents (breaking a hard task into focused steps) with none of the cost (unpredictable paths, runaway loops, opaque failures). Reach for a real agent only when the branching is data-dependent in a way you can't pre-wire.

What agents actually cost

Every property that makes agents flexible also makes them harder to run. Be honest about the bill before you sign up.

• Cost and latency multiply. An agent that takes eight steps makes eight or more model calls, each carrying the growing conversation, and long-running tasks can burn a lot of tokens. A single prompt has one predictable cost. Agent cost varies per run and can spike when the model gets confused and thrashes.
• Debugging is genuinely hard. When a single prompt fails, you read the input and output. When an agent fails on step six of ten, you reconstruct the whole trajectory to find where it went off the rails, and it may not fail the same way twice. Invest in tracing before you need it.
• Errors compound. If each step is 95% reliable, ten steps is around 60% end-to-end. Small per-step error rates become large task-failure rates as the chain lengthens. This math is unforgiving and it's why long agent runs feel flaky.
• They need guardrails you have to build. Maximum step counts, timeouts, budget caps, tool-permission scoping, and a way for a human to intervene. A loop that can call tools needs a hard stop, or a confused agent will keep spending until something breaks.

The cases where an agent is right

None of that means avoid agents. When the shape of the problem is exploratory and open-ended, they do things no single prompt can. Debugging across an unfamiliar codebase. Research that follows leads it turns up. Multi-system operations where each result changes the next action. In these, the whole value is that the model adapts the plan as it learns, and hard-coding a flow would just be wrong. The 2026 coding agents are the clearest proof: they succeed precisely because the task is unknowable in advance.

The tell is honest uncertainty about the steps. If you find yourself writing "and then, depending on what it finds, it might need to..." and the branches keep multiplying, that's an agent. If you can draw the flowchart, that's a chain, and you should build the chain because you'll be able to test it, cost it, and sleep through its on-call rotation.

A practical default

Start with one prompt. If one prompt can't do it, decompose into a chain of prompts you sequence yourself. Only when the sequence genuinely can't be known ahead of time do you graduate to an agent, and when you do, scope its tools tightly, cap its steps, trace every run, and keep a human able to intervene. Most "agent" features in production would be simpler, cheaper, and more reliable as a chain. The engineering skill here isn't building agents. It's recognizing the far more common case where you don't need one.