Choosing between a workflow and an agent comes down to one question.
The rule of thumb#
Can you name all the steps upfront?
- Yes: write a workflow.
- No: the task is open-ended, and the right steps depend on what comes back at each stage. Then consider an agent.
An agent is not the default#
"Consider" is the right word. Most production systems that look like agents are really workflows with a few conditional branches. A branch like "if the order is late, check the shipping status" is still your code deciding.
Two signals that you need an agent#
| Signal | Example |
|---|---|
| The number of steps varies a lot with the input | One bug report needs a single search. Another needs ten searches across several files. |
| The model must decide whether to keep going or stop, based on intermediate results | A research task that stops only when the sources found so far answer the question. |
If neither signal is there, a workflow will be cheaper, faster and easier to debug. See The trade-off.
Two examples#
| Task | Choice | Why |
|---|---|---|
| Turn a complaint into a support ticket | Workflow | The steps are always extract, classify, write. |
| Find the root cause of a failing test in a large codebase | Agent | Which files to read next depends on what each search returns. |
Short line#
If you can name every step upfront, write a workflow. Consider an agent only when the number of steps varies a lot with the input, or the model must decide when to stop from intermediate results. Most systems that look like agents are workflows with branches.
Key takeaways#
- Ask: can you name all the steps upfront? If yes, write a workflow.
- If the steps depend on what comes back, consider an agent.
- An agent is not the default. Most "agents" in production are workflows with conditional branches.
- Signal 1: the number of steps varies a lot with the input.
- Signal 2: the model must decide whether to continue or stop based on intermediate results.