Do you need an AI agent, or a workflow with a few model calls?

A team wants to automate its supplier inbox. One engineer proposes an agent: give a model the mailbox, the ERP and some tools, and let it work out what each email needs. Another proposes a pipeline: classify, extract the fields, look up the order, draft a reply for a buyer to approve. Both demos work on the dozen emails picked for the demo.

The difference shows up later: in testing, in the monthly bill and in the first incident review. For most business processes the fixed workflow wins, because each known step can be tested, priced and explained. An agent earns its place where the path can’t be known in advance, and it costs more to test, run and explain.

What is the difference, concretely?

In a workflow, your code decides the sequence and calls a language model at fixed steps to do what code can’t, such as reading an email or drafting a reply. Each call has one job and a known output format. In an agent, the model decides the sequence: given a goal and a set of tools, it loops, choosing a tool, reading the result and deciding what to do next.

Take an illustrative supplier inbox that receives order confirmations, delivery-date changes, invoice queries and price-change notices, plus the odd email that fits nowhere.

• As a workflow: a classifier sorts each email into one of those four types, or “other”. Each type has a fixed path: extract the order number and dates, look up the purchase order, compare, draft an update for a buyer to approve. “Other” goes to a person.
• As an agent: the model gets the email and tools to search orders, read supplier records, update delivery dates and draft replies, and decides which to call, in which order, and when to stop.

The differences after launch:

• Testability. The workflow is tested step by step: the classifier on labeled emails, extraction field by field, lookups with unit tests. A failure points to a step. The agent can take a different route through the same email on each run, so a failure can sit anywhere in a chain of choices.
• Cost. The workflow makes a known number of calls per email, most of them cheap. The agent makes as many as it decides to, each carrying the task’s growing history, so cost per email has a long tail.
• Failure modes. The workflow fails loudly and locally: an unknown email lands in “other”, a failed extraction goes to a person. The agent fails quietly: it loops, calls the wrong tool, or finishes confidently with an update nobody asked for.

When is a fixed workflow the better design?

Choose a workflow when these hold:

• You can draw the process. The steps are known, even if the inputs are messy.
• The variety is in the input, not the procedure. Emails and documents vary; what happens to them doesn’t.
• Results must be repeatable and auditable. Finance, compliance, anything that commits the company.
• Volume is high. A predictable cost per task matters more than automating every exotic case.

Invoice handling, returns, order updates and ticket routing usually pass all four. Build the flowchart and call a model only in the boxes that read or write language; some boxes need no model at all, because a rule or a lookup does them better.

If you can draw the process as a flowchart, build the flowchart.

When does an agent earn its place?

When three conditions hold together:

1. The path depends on what each step finds. Working out why a delivery is late may mean checking the order, then the carrier record, then an old thread, then a different order the supplier confused it with. The combinations are too many to draw.
2. The actions are safe. Most of the work is reading and searching; anything that changes a record is a draft for a person.
3. The long tail is worth handling. Cases that don’t fit a fixed path are frequent or valuable enough to pay for the variability.

Even then, keep the agent narrow: one goal, a short list of tools, a step budget and a defined way to stop and hand over. How much it may do without asking is a separate decision, covered in where agents should and shouldn’t act on their own.

What do agents cost in testing and operations?

Operations add their own costs: step limits, loop detection, logs detailed enough to replay a run, repeated evaluation runs, and time spent explaining to an auditor why the system did what it did.

Do multi-agent designs help?

Rarely at first. A planner, a researcher, a writer and a checker look tidy on a diagram, but every hand-off loses context and compounds errors, and coordination adds calls, cost and latency. When the output is wrong, you first have to find which agent went wrong and why the others didn’t notice.

Before adding a second agent, ask whether one agent with better tools would do, or a workflow that calls the model once per role in a fixed order. A “checker agent” usually works better as validation in code, or as a person at an approval point. Several agents can make sense for independent sub-tasks, each with its own evaluation set, but that is a design to reach with evidence, not a place to begin.

Can you combine the two?

Yes, and it is often the best design: a fixed workflow with one bounded agentic step inside it.

In the illustrative inbox, the workflow runs as before. When a date change matches no open order, or an email lands in “other”, a bounded agent takes that one case, with read-only tools (order search, supplier history, earlier threads) and a step limit. It returns a structured finding to a buyer (likely order, evidence, suggested action) and never writes to the ERP.

The workflow handles the common cases predictably; the agent works the awkward ones inside a box you can test and afford. The four guardrail questions set the limits of that box: who can access what, and when a person decides.

Mark the unknown steps

Draw the process as a flowchart and mark the boxes where the next step can’t be known in advance. If there are none, build a workflow. If there are one or two, put a bounded agent in those boxes and design its tools with care, as described in how to design the tools an agent may use. A second opinion on that design is everyday work in our custom AI software projects.