When Not to Use AI Agents: Simpler Options

What you pay for with an agent

An agent lets a model decide its next step at run time. That flexibility is useful, and it is also the source of every cost that comes with it. If the model chooses the path, then the path varies between runs. Testing has to cover behaviour rather than fixed steps, failures are harder to reproduce, the number of model calls is unpredictable, and each tool becomes something that may be called at the wrong moment with the wrong arguments.

So the useful question is not "could an agent do this?", because it often could. The question is whether this task needs a decision made at run time, and whether that benefit outweighs those costs. What is agentic AI? sets out the definitions and the positive case. This guide examines the other side, with concrete replacements.

Start at the bottom of the ladder

It helps to think of the options as a ladder, and to climb only as far as a test shows you need to:

Ordinary software. Rules, queries, forms and scheduled jobs, with no model at all.
Traditional machine learning. A classifier or forecasting model, trained for one narrow prediction.
A single LLM call. One prompt with validated output, placed inside normal code.
Retrieval plus an LLM. The same call, supplied with relevant documents.
A fixed workflow with several LLM steps. Your code sets the order, and the model does the language work within each step.
An agent. The model chooses tools and steps in a loop, within limits.
Several agents. Separate agents with their own tools or permissions, coordinating with one another.

Each rung adds variability and operating work. Moving up is usually straightforward once you have evidence of the need, and the simpler version leaves you with a test set and a baseline to compare against.

Seven situations where simpler software wins

You can draw the flowchart

If you can write down the steps, including the branches, then write them in code. An invoice process that reads a document, extracts fields, checks them against a purchase order and sends exceptions to a person has an LLM-shaped step in the middle, but the order of operations never needs to be reinvented. Asking a model to rediscover the same sequence on each run adds risk and gains nothing.

Results must be exact or repeatable

Tax calculations, pricing, eligibility and compliance checks need one correct outcome and an explanation that holds up later. Put those rules in code that you can test and version. A model can help to collect the inputs or explain the outcome in plain language, while code makes the decision.

It is really one transformation

Summarising a document, drafting a reply, classifying a ticket and extracting fields are each one input and one output. They contain no decision about what to do next, so a loop has nothing to add. A single call with structured output is often the entire feature. If the task is classification on plentiful labelled data, compare it first with a traditional NLP model.

It is really a question over documents

If users want answers from a known body of content, a retrieval pipeline with one generation step is usually enough. Add a loop only when you can point to questions that a fixed pipeline fails on and that a second search would solve.

Nobody can tell whether it worked

An agent needs a way to judge success, and so do you. If there is no reliable check of a result, and no one has time to review it, then errors will accumulate unseen. Automating the task may not be sensible yet, whatever the implementation. How to scope an AI project covers defining that measure before building.

Mistakes are costly and hard to undo

Payments, deletions, messages to customers and changes to live systems raise the stakes on each decision. If a review step would have to cover every action anyway, consider whether the model should only draft a proposal, with a normal application handling the approved action. This keeps the useful part and removes most of the risk.

Time or budget limits are tight

Interactive features with a strict response time do not sit well with a variable number of model and tool calls. The same is true of very high-volume, low-value tasks, where even a small per-item cost multiplies. A fixed path has a predictable upper limit, which you can design around.

One task, built without an agent

Take a hypothetical support inbox. The goal is to label each email, look up the related order and prepare a draft reply for a person to send. It is tempting to give an agent tools called lookup_order, classify and draft_reply and let it get on with things. But the sequence is the same every time, so code can own it:

# Illustrative only. Helpers are placeholders; the labels are examples.
LABELS = {"refund", "delivery", "account", "other"}

def handle_email(email):
    label = classify_email(email.text)      # one LLM call
    if label not in LABELS:
        label = "other"

    order = None
    order_id = find_order_number(email.text)  # a regular expression
    if order_id:
        order = get_order(order_id, email.sender)  # a normal query

    if label == "other":
        return send_to_person(email)

    draft = draft_reply(email.text, label, order)  # one LLM call
    return queue_for_review(email, label, draft)

This version makes at most two model calls per email, so its cost has a clear upper limit. Each step can be tested alone, and a failure points to one line. The order lookup is an ordinary query that cannot wander, and sending stays with a person. The model still provides the two things that code handles poorly, which are reading language and writing it.

The trade-off is real, however. Should a new kind of request need a step this flow lacks, someone has to change the code. That is usually acceptable, and if such requests become common and varied, you will have evidence for adding some flexibility.

Warning signs in a proposal

Some phrases suggest that an agent has been chosen before the problem was understood:

"Let's make it agentic" with no named decision. Ask which specific choice the model will make at run time. If nobody can say, the design has no need for one.
Every run makes the same tool calls. Check your traces. If the path barely changes, the loop is doing no useful work and can be written out as a workflow. LLM observability and tracing shows how to capture those runs.
Prompts that spell out the steps. A system prompt saying "first do A, then B, then C" is a program written in a language that does not guarantee execution.
Multiple agents for tidiness. Dividing work into a team of named roles may look organised, while adding coordination that a function call would not need. The comparison of single agent vs multi-agent systems covers when a split is justified.
A demo as evidence. A run that succeeded once says little about how often it succeeds across varied inputs.

When an agent is the right answer

None of this means agents are a mistake. They suit work where the next step really does follow from the last result, such as investigating a problem across several systems, where listing all the paths in advance is impractical, mistakes can be caught and a slower response is acceptable. Even then, an agent can be one bounded step inside a larger fixed workflow rather than the whole system, and graph-based tools described in building an orchestrator with LangGraph make that combination practical.

A quick way to decide

Take twenty or thirty real examples of the task, and write out by hand the steps each one needed. If nearly all follow one path, or a few known paths, build a workflow. If the paths truly differ and depend on what was found, try a small agent, and compare it with the simpler baseline on the same examples, including cost and time. Keep the agent only if it wins by enough to justify running it.

If you are weighing up an agent for a specific task, the multi-agent systems page describes how I can help, including when the honest recommendation is a simpler design.

Frequently asked questions

What is the difference between an AI agent and a workflow?

In a workflow, your code sets the order of steps, and a model may perform some of them. In an agent, the model chooses the next step at run time. Workflows are more predictable, while agents handle paths that cannot be planned in advance.

Are AI agents overkill for a chatbot?

Often, yes. A chatbot that answers from documents or calls one known service can usually be built with retrieval or a single tool call. A loop becomes useful only when a request needs several steps that cannot be predicted in advance.

Can I start with a workflow and move to an agent later?

Yes, and it is often the sensible order. A workflow gives you a test set, tools and a baseline for comparison. If you later find requests it cannot handle, you can add a bounded agent step for those cases.

How do I know if my agent should be a workflow?

Review traces from real runs. If most of them make the same tool calls in the same order, the model is not making a useful decision, and fixed code will probably serve you better at lower cost and with easier testing.

When not to use AI agents, and what to build instead