Workflow or agent? Ask whether the next step changes

The useful question about an agent is not how capable it is. It is whether the next step in the work changes depending on what the last step found. If it does not, the work is a workflow, and a workflow is cheaper, easier to test, and easier to explain to a reviewer.

One widely cited engineering guide draws the line the same way. Workflows are systems where language models and tools are orchestrated through predefined code paths. Agents are systems where the model directs its own process and tool use. The difference is who chooses the route: your code or the model.

First: does it need a model at all?

Before choosing between a workflow and an agent, ask whether a rule, a lookup, or a calculation is enough. A threshold check, a date comparison, or a match against a list does not need a language model. Many processes that arrive labeled “agent” are a workflow with one or two model steps inside it, and some need no model at all.

That gives three options, in order of preference:

1. A rule or calculation, when the logic can be written down completely.
2. A workflow, when the steps are fixed but one of them needs judgment over unstructured input, such as reading a scanned invoice or classifying a complaint.
3. An agent, when the order and number of steps cannot be known until the work starts.

When the route never changes

Take invoice intake. Read the document, extract the fields, match them to the purchase order and the goods receipt, check tolerances, post the match or route the exception. Every invoice takes that route. A language model may do the reading and extraction, but the code decides what happens next.

That design has properties an operations head values. Each step can be tested on its own. Cost per invoice is predictable. When something goes wrong, the failing step is obvious. The exception queue holds exactly the cases a person should see.

Turning this into an agent would add cost and variance and remove nothing. The model would spend effort choosing a route that is the same every time.

When the next step depends on what is found

Now take a supplier due-diligence case. The documents the supplier sends decide what to check next. An ownership chain that does not match the registry leads to another lookup. A sanctions hit on a similar name leads to identity checks. A missing certificate leads to a request back to the supplier. Two cases from the same week can take very different paths, and the number of steps is not known in advance.

Here a fixed workflow needs a branch for every combination, and the branches become an agent written badly. This is the kind of work agents are for. ReAct, one of the early designs, interleaves reasoning and actions so the model can track and update its plan as it acts, and its trace of steps is readable afterward.

Even then, the agent prepares. A sanctions match is closed by a person. The agent gathers the evidence and writes the case up for them.

A test you can run on your own cases

1. Take a sample of recent closed cases from the desk, including the awkward ones.
2. Write down the steps the expert actually took, in order, with what each step found.
3. Compare the sequences. If they are the same, or differ only at a few known branch points, write a workflow. If the sequence keeps changing based on findings, an agent is a candidate.
4. Look for a mix. The common answer is a workflow with one bounded agentic step inside it, for example a fixed intake and decision path with an agent that investigates exceptions.

The harness comes with the agent

An agent is not just a model with tools. It comes with a written harness, and the harness is where the institution keeps control. It names:

• the tools the agent may call and the access each one has, read-only by default;
• whether it runs as a workflow or autonomous within written limits;
• its approval limits: which actions need a person, and who;
• its stop conditions: when it halts and hands the case over;
• the record of every step, input, tool result, and output.

The OWASP list of risks for language-model applications calls the failure here excessive agency, with three root causes: excessive functionality, excessive permissions, and excessive autonomy. Its mitigations match the harness: give tools the minimum permissions they need, and require a person to approve high-impact actions. An agent never grants itself a tool, a permission, or an approval. Automatic outcomes happen only inside the institution's written policy, through its own engine or process. Every other case goes to a named person.

The cost of choosing wrong

An agent where a workflow would do costs more per case, behaves less predictably, and is harder to test and audit. A workflow where an agent is needed grows branches until nobody can maintain it, and the cases it cannot handle reach people anyway, often without the evidence gathered.

Start with the simplest design that handles the real cases, and add the loop only where the cases show the route changes.