Do you actually need an agent?

Two questions settle this, and the order matters. Does the task need a language model at all? If it does, can you write the steps down in advance?

Answering no to the first saves you a model. Answering yes to the second saves you an agent. Most teams skip both questions and build an agent because agents are interesting, which is how you end up paying ten times over for something a for loop did correctly.

Question one: does this need a model?

A language model earns its place when the input is unpredictable and unstructured. Free text, images, audio, a support email that could say anything. Ordinary code handles structured input with a known shape far faster, far cheaper, and with results you can reproduce exactly.

Two signals point toward a model:

The data has no schema. Someone typed a sentence, uploaded a photo, or recorded a voice note. Traditional code struggles to interpret meaning; a model was built for it.

The inputs vary widely. A small, fixed set of possible requests belongs in code, where you can enumerate them and test every branch. When you cannot list the cases in advance, a model handles the long tail that your enumeration would miss.

A form with six dropdowns and a date picker fails both tests. Route it to code.

Question two: workflow or agent?

Say the task genuinely needs a model. You still have two shapes available, and they differ in exactly one respect: who decides the order of the steps.

In a workflow, you decide. You write the sequence, the model fills in the parts that need judgement, and the path through your code is one you could draw on a whiteboard before it ran.

# A workflow. You wrote the steps; the model does the reading.
def handle_ticket(text: str) -> Ticket:
    ticket = classify(text)                    # model call 1
    if ticket.urgency >= 4:
        ticket.summary = summarise(text)       # model call 2, only sometimes
        page_on_call(ticket)
    return ticket

In an agent, the model decides. You supply a goal and a set of tools, and the model chooses which tool to use, in what order, and when the job is finished.

# An agent. You wrote the tools; the model decides the sequence.
def handle_request(goal: str) -> str:
    messages = [{"role": "user", "content": goal}]
    while True:
        reply = model(messages, tools=[search, read_file, calculate])
        if reply.is_final:
            return reply.content
        messages += [reply, run_tool(reply.tool_call)]   # feed the result back

Look at the difference in the code rather than the description. The workflow has an if. The agent has a while, and nothing in your source says how many times it goes round.

In a workflow you write the sequence. In an agent the model chooses it at runtime.

What an agent costs you

A while loop over a model has three prices attached, and all three are easy to overlook in a demo.

Money. Each pass round the loop is another call. A request a workflow settles in one call might take an agent ten, so a task costing a fraction of a cent becomes a task costing ten times that. At a thousand requests a day, the choice stops being architectural and starts being financial.

Time. Every step adds its own round trip. A workflow with two calls answers in about two calls' worth of waiting. An agent answers when it decides it is done.

Compounding errors. A mistake in step two travels into steps three through eight. The model reads its own earlier output as though it were established fact, so a small early error arrives at the end looking like a confident conclusion.

Three tests for reaching for an agent

Can you predict the number of steps? "Look up the population of a region" takes one step, every time. "Work out whether we should open an office there" takes as many as the evidence demands. When the step count depends on what gets discovered along the way, you have found the case an agent suits.

Is the task worth the extra cost? An agent is slower and more expensive per task. The output has to be worth more than the difference. Answering a routine password-reset email does not clear that bar. Assembling a research brief a person would spend two hours on clears it easily.

How expensive is a wrong answer, and would you notice? Both halves matter. A wrong answer that costs little and shows up immediately is a fine risk. A wrong answer inside a specialist domain, where neither the user nor you would spot it, is the case where extra autonomy makes things worse. Detection is the part people forget.

Predictable steps, low value or undetectable errors all point back to a workflow.

One question we will carry through the rest of this series

Here is a task that fails the workflow test on every count, and it is the example the rest of these posts will keep returning to:

Our support team closed 412 tickets last quarter. If we route the routine ones to an agent, how many staff-hours would that free, and does the saving cover what the model calls cost?

Try writing that as a workflow and the problem becomes obvious. Answering it needs the ticket export read and categorised, current model pricing looked up, an average handling time found or estimated, and arithmetic over all of it. The number of steps depends on what the export turns out to contain. The order depends on what the first look reveals.

You cannot draw that path in advance, which is the whole signal. Hold on to this question: it is the one we will use to build something that can actually answer it.

What to take from this

• Ask whether the task needs a model before asking what kind. Structured, predictable input belongs in ordinary code.
• A workflow means you order the steps; an agent means the model does. That single difference brings cost, latency and compounding errors with it.
• Reach for an agent when you genuinely cannot predict the steps, the task is worth the overhead, and a wrong answer would be caught.

Most systems worth building are workflows, and choosing one is an engineering decision rather than a lack of ambition. For the tasks that do need an agent, the next question is how you would ever know whether the thing works.