A small simulation of success and cost as more of the inputs are unusual, and what it teaches.
What the trade-off looks like
The simulation uses made-up parameters: 95% success per step, a fixed 3-call workflow, an agent that needs 3 steps for an ordinary ticket and several more for a "novel" one, and a cap of 12 steps. It does not measure any real system. It shows the shape.
Success and calls per ticket as the share of novel tickets grows. Real output of the simulation with the stated assumptions.
Novel tickets
Workflow solved
Agent solved
Agent calls (mean / 95th percentile / max)
0%
86.0%
86.0%
3.0 / 3 / 3
20%
68.8%
82.0%
3.7 / 9 / 12
40%
51.5%
78.6%
4.3 / 12 / 12
60%
34.3%
75.0%
5.1 / 12 / 12
Four things to read from it:
With no novelty, they tie, and the workflow costs the same every time. (0.95 to the power 3 is 85.7%, which the 86.0% matches.) If your inputs are predictable, the agent buys nothing.
A workflow's success falls in a straight line as novelty grows, because it cannot adapt. It needs a human or a fallback for what it cannot handle.
An agent adapts, but its cost is a distribution. The mean is modest while the 95th percentile and the worst case are several times higher. Budget for the tail (Level 2, module 6) and cap the steps.
Mistakes compound with steps. Each extra step is another chance to go wrong. That is why success drops even for the agent, and why raising per-step reliability (better prompts, validation, tests) pays off more as runs get longer.
The simulation is a teaching toy
Real tasks are not just 'ordinary or novel', real steps are not independent, and real agents recover from some errors. Use the shape of the argument, then measure your own system with a test set (module 5).
Check yourself
The agent's mean cost at 20% novelty is 3.7 calls, but the 95th percentile is 9. Which number do you use to set a budget, and why? (The tail. A budget based on the mean is exceeded by every unusual ticket, and one runaway run can cost more than many ordinary ones.)
The hybrid is usually the answer
Build the workflow first. Where one stage truly needs flexibility, make that stage an agent with a step cap, tools limited to what it needs, and a code check after it. You keep a predictable cost and an audit trail everywhere else, and failures have a defined escape (retry, fallback, human).
The book-keeping reasons are the same three each time: contain complexity (the hard part is one small box), control cost (only that box has a variable bill), and degrade gracefully (when the agent fails, the surrounding workflow can fall back or ask a person).
Write the justification down
A good written argument for "this is a workflow" has four sentences: what varies, what does not, what a wrong step costs, and what would make you add an agent stage later.
What you will use daily at work
Practice
What it looks like
A short design note
Every new LLM feature starts with one paragraph saying why it is a workflow or an agent, and what evidence would change that.
Cost percentiles
Dashboards show the 95th and 99th percentile cost per run, not just the average.
Step and cost caps
Every agent loop has a maximum number of steps and a maximum spend.
Escalation paths
When the system cannot handle a case it hands over to a person with the work done so far.
Draft: confirm limits and escalation options in the framework or product you use before relying on this.
Interview angle
"When would you choose a fixed workflow over an agent?" Lead with predictability, cost, testability and auditability. Concede that an agent wins when steps depend on tool results you cannot enumerate. Then offer the hybrid and a plan to measure. Mention the 95th percentile cost of an agent, not just the average.