Short answer. Use an agent when the steps cannot be known in advance. Use a workflow when they can. Most business processes are of the second kind, and giving them an agent buys unpredictability at a higher price.
Every project brief that arrives now asks for agents. Some of them should. The rest describe a process that runs the same way every time, has three branches, and would be finished by Thursday if nobody had said the word "agent" out loud.
The distinction matters because the two are not the same kind of software. A workflow does the same thing given the same input, forever. An agent decides what to do, which means the same input can produce a different sequence tomorrow. That is the whole point of an agent, and it is also the entire cost.
When is a workflow the better answer?
A workflow wins whenever you can write the steps down.
If someone in the business can describe the process as a numbered list, with the conditions spelled out, then the list is the specification. Encoding it takes less time than writing the prompt would, it runs in milliseconds instead of seconds, it costs nothing per execution, and when it breaks you get a stack trace pointing at a line number.
This covers more ground than people expect. Routing an enquiry by source and value. Creating an invoice when a deal closes. Chasing a document that has not arrived after three days. Syncing two systems that disagree about a customer record. Reminding someone that a licence expires next month. All of these have known steps, and none of them improve when a model gets to choose.
The useful test: if the process were handed to a competent new hire with a one-page checklist, would they do it correctly every time? If yes, you have a workflow.
What are the three signs the job does not need an agent?
The output has a fixed shape. An invoice, a calendar entry, a CRM field, a row in a ledger. When the answer must fit a schema, a model is being asked to produce something a template already produces, with a chance of getting it wrong.
Being wrong is expensive and quiet. Some failures announce themselves. Others sit in the database for six weeks. A workflow that breaks stops; an agent that misjudges keeps going and writes plausible garbage into a system nobody re- reads. The quieter the failure mode, the stronger the case for determinism.
The volume is high and the value per run is low. Ten thousand executions a month at two cents each is two hundred dollars for something a function does for free. That arithmetic is the same every month, and it gets worse as you grow.
What does an agent actually cost?
Not the tokens. The tokens are the cheapest part.
The real cost is that you can no longer reason about the system by reading it. A workflow's behaviour is in the code. An agent's behaviour is in the interaction between a prompt, a model version, a tool set, and whatever the input happened to be that day. When it does something unexpected, reproducing the fault is itself a project.
Then there is the evaluation cost. Any agent going near a customer or a financial record needs a test suite that checks judgement rather than output shape. That suite has to be written, maintained, and rerun on every model change you do not control. Teams routinely budget for building the agent and not for the harness that proves it still works.
And there is the human cost. Someone has to review what the agent did. If the review takes as long as the task, the automation moved the work rather than removed it.
None of this argues against agents. It argues for deploying them where they earn their keep.
Where does an agent earn its keep?
When the steps genuinely cannot be enumerated in advance.
Reading a document nobody has seen before and pulling out what matters. Qualifying an enquiry written in prose, where the useful information arrives in whatever order the person felt like typing it. Deciding which of forty knowledge base articles answers a question that does not match any of their titles. Investigating something, where the second step depends on what the first one found.
These share a shape: the input space is open, and the correct sequence is a function of the input rather than of the rules. A decision tree covering all of it would be longer than the model, and wrong at the edges.
The strongest architecture is usually neither one nor the other. Put the agent where the judgement is and the workflow everywhere else. An enquiry arrives, a model reads it and extracts structured fields, and from that point deterministic code does the routing, the scheduling, the notification, and the CRM write. Judgement stays in the one step that needs it, and everything around it can be tested.
How do you decide before you build?
Ask three questions about the process, in this order.
| Workflow | Agent | |
|---|---|---|
| Can you write the steps down? | Yes | No |
| Does the output fit a fixed schema? | Yes | Not reliably |
| What does a failure look like? | It stops | It continues, plausibly wrong |
| Cost per run | Effectively zero | Cents, every time, forever |
| How you know it still works | A test | A test suite plus a human reading a sample |
Can you write the steps down? If yes, write them down and stop reading. Nothing below applies.
Which single step is the one you cannot specify? Usually exactly one, and it is usually a reading or classification problem. That step is your agent. Everything on either side of it is a workflow.
How would you know if it were wrong? If you cannot answer this, you are not ready to deploy either kind of automation. For a workflow the answer is a test. For an agent it is a test suite plus a human reviewing a sample. If neither exists, the thing you are about to ship has no failure detection, and the failure mode of an unattended agent is not an outage. It is quiet, confident, accumulating error.
The systems that work in production are boring in most places and clever in one. The ones that get rebuilt after six months are clever everywhere.
Danil Ivanov
Founder, KAIVIX
Builds AI systems for companies in the UAE and beyond.