Agent vs script vs chat: when to use which

The itch to reach for an agent shows up early. The task has more than one step, so multi-step reads in your head as "agent territory." Most of the time it isn't. A large share of real work fits one of three shapes, and only the smallest slice of it needs a model that decides its own next move. Getting the level right up front saves you from shipping the slower, pricier, harder-to-debug version of something a plain script would have handled just as well, and it saves you from underbuilding a task that genuinely can't be pinned down in advance.

Three levels, and what actually separates them

Chat, script, and agent get treated as points on the same scale of "how smart," but the more useful split, especially when you're deciding what to build, is about who decides the next step, not how capable the model underneath is. There are three levels worth naming clearly:

• Chat / one-shot: a single request and a single reply. You read the output, decide what happens next, and type a new prompt if you want another step. The model never sees its own last action; you're the loop.
• Script / workflow: a fixed, predetermined sequence of model calls, wired by code you wrote ahead of time. The code owns the order of operations, the branches, and the stopping point. The model fills in a bounded slot at each step, classify this, draft that, summarize this, but it never decides what step comes next.
• Agent: a loop where the model decides its own next step, based on what the last step actually returned, and decides for itself when the goal is met or it should stop. Nobody wrote the path down in advance, because nobody could.

Level 2 in practice: the workflow patterns that cover most cases

Anthropic's own engineering guidance names the two categories plainly: workflows are "systems where LLMs and tools are orchestrated through predefined code paths," while agents are "systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks."¹ Almost every real workflow is built from a small set of recurring shapes:

• Prompt chaining: break a task into sequential steps, each model call working on the previous step's output.
• Routing: classify the input first, then send it down one of several specialized, predefined paths.
• Parallelization: run several model calls at once, either splitting independent pieces of the task or having a few calls vote on the same one.
• Orchestrator-workers: one central model call looks at the input, decides how to split the task into subtasks at runtime, and hands each to a worker call. Here the split is chosen by the orchestrator, not laid out in advance by your code, which makes it the most flexible of the five.
• Evaluator-optimizer: one call generates a draft, a second call checks it against a rubric, and the two iterate until the evaluator accepts the result, with a round cap so it cannot run forever.

A support-ticket pipeline is a workflow even though it might touch a model four separate times: classify the ticket, route it to the right queue, draft a reply, check the reply against policy before it sends. Every one of those is a separate, predictable call, wired in a fixed order by code you wrote. None of it needs a model deciding what happens next, because you already know what happens next.

ticket = classify(text)
queue  = route(ticket)
draft  = write_reply(ticket, queue)

if passes_policy(draft):
    send(draft)
else:
    escalate(ticket)

Level 3 in practice: when the path can't be written down

Fixing a failing test suite is the clean example of the other case. You don't know which file is broken until you run the tests. You don't know what the fix is until you read the failure. You don't know whether the fix worked until you run the tests again. Nobody can write that sequence down in advance, because each step depends entirely on what the one before it turned up. That's the real bar for reaching for an agent: not "this involves several steps," but "the steps depend on results that only exist once you start."

The core teaching: most problems don't need the loop

Anthropic's own guidance on this is blunt: find "the simplest solution possible, and only increasing complexity when needed." For a large share of applications, "optimizing single LLM calls with retrieval and in-context examples is usually enough."¹ That is not a hedge. It is the default recommendation from the team that put a name to the workflow-versus-agent split in the first place.

The reasoning holds up once you think about what a workflow buys you that an agent doesn't. Anthropic frames the trade directly: "workflows offer predictability and consistency for well-defined tasks, whereas agents are the better option when flexibility and model-driven decision-making are needed at scale."¹ If the path is knowable, hardcoding it beats asking the model to re-derive that same plan on every run. It's cheaper, because there's no extra reasoning pass spent figuring out what you already know. It's faster, for the same reason. And when it breaks, it breaks inside one specific, readable step of code, not somewhere inside a transcript you have to reconstruct after the fact.

The flip side is just as direct: "agentic systems often trade latency and cost for better task performance," and that trade only pays off when the task genuinely needs the flexibility.¹ The rule Anthropic gives for when to spend that cost is simple to state and easy to forget under deadline pressure: add the complexity of a loop "only when it demonstrably improves outcomes," measured against the fixed workflow, not against a blank page.¹

Four questions before you reach for a loop

• Is the path known today, and will it stay known? If you can write the sequence of steps down right now and nothing about tomorrow's input would change it, that's a workflow. Writing it down in code isn't a limitation, it's the entire point.
• Does the next step genuinely depend on what the last one returns? Not "could," genuinely does, in a way you can't enumerate as a fixed set of branches. A handful of known branches is still routing, a workflow pattern. An open-ended set of possible next moves is the agent case.
• How bad is a wrong autonomous action? A wrong guess in a chat reply costs a re-read. A wrong step inside a loop that can send a message, spend money, or delete something costs real damage before anyone notices. The worse that number gets, the more it argues for a workflow with a mandatory checkpoint, or an agent that stops and asks before anything irreversible, not a fully autonomous one.
• What's your budget for cost, latency, and debugging? Every extra pass through a loop is another full model call, replaying the conversation so far, so a five-step agent task doesn't just cost five times a one-shot call, it costs more than that. And because the same input can take a different number of steps on two different runs, a bug report from an agent doesn't always reproduce the same way twice, which a fixed workflow never has to deal with.

Honest trade-offs

Neither level is free, and neither is strictly better. Picking the right one means being honest about what each one costs you.

• A workflow is cheap, fast, and repeatable. The same input takes the same path every time, so a bug is one step in one script, not a transcript you have to replay to understand. The cost is rigidity: the moment reality throws a case outside the paths you wired, the workflow either force-fits it into the wrong branch or fails outright, and adding a new case means a code change, not a prompt edit.
• An agent handles cases you never enumerated. It can recover mid-task when something unexpected shows up, without you having predicted that exact situation in advance. The cost is real: more model calls per completed task, slower responses because each pass replays what came before, and a debugging story that's genuinely harder, since the same input can take a different route on different runs, and an early wrong observation can compound because every later step reasons from it.
• Neither one forgives a badly scoped task. A workflow executes a bad plan exactly as specified, every time. An agent just executes the bad plan in more steps, more expensively, with more places along the way for it to go sideways.