Should this be
an agent?
A customer’s parcel is missing.
Does solving it need a checklist, an AI workflow,
or a system that decides its next move?
This is a scripted, executable demonstration. You’ll see the actual steps taken by each strategy in this small world.
Same customer. Same tools. Different control flow.
| Approach | Outcome | Tool calls | AI decision steps* |
|---|
*Scripted stand-ins for model decisions, not measured LLM calls or latency. Reading a tool result is different from issuing a refund.
Give the workflow another move.
A developer can add the photo check to the fixed workflow. Does the agent still resolve more cases?
This adds an explicit branch. It does not give the workflow autonomy.
Each lookup or refund uses one call. When the budget runs out, the request goes to a person. Try a limit of 3.
Now test all seven requests.
One run per synthetic case. No invented success percentages.
| Approach | Handled automatically | Human handoffs | Tool calls | AI decision steps* |
|---|
Inspect all seven outcomes +
| Request | Checklist | Workflow | Agent |
|---|
New to AI? Start with these three distinctions. +
Understanding words is not the same as choosing actions. A model can turn “it was due three days ago” into a late-delivery request. You can still let ordinary code decide what happens next.
A tool is a function the system can call. Here it can look up tracking, check prior refunds, inspect a photo, or request a refund. Looking something up does not authorize a payment.
An agent has a decision loop. It observes a result, chooses a next action, and repeats. That flexibility is useful when the path isn’t known in advance. A fixed workflow can also handle many paths if someone writes the branches.
Already building? Inspect the strategies and shared boundary. +
interpret request read tracking read refund history if already refunded: stop if late > 48h: request refund if photo branch enabled: if delivered: inspect photo if wrong door: request refund otherwise: human handoff
choose tracking tool observe delivery status choose history tool observe prior refunds if evidence conflicts: choose photo tool observe photo evidence choose refund or human handoff stop at tool budget
Shared authorization: the refund function only permits $8, requires observed eligibility evidence, and rejects a prior refund. Customer text cannot change that policy. We don’t make one design insecure just to make another look good.
Expert view: assumptions, confounders, and what to measure next. +
This is a control-flow illustration, not evidence that an agent performs better. The “AI” decisions and photo interpretation are authored annotations. There is no LLM, stochastic planner, actual visual recognition, measured latency, or dollar-cost benchmark. The agent policy is also code; real agents choose actions through a model.
The basic checklist deliberately accepts only a structured category. A better form or broader rules could close that gap. The basic workflow lacks the photo branch; adding it demonstrates that its limitation is the implemented path, not a fundamental inability of workflows.
These seven cases are illustrative, unweighted, and not representative evaluation data. “Handled automatically” includes issuing a permitted refund or confirming an existing one. A handoff can be the correct outcome. Planning steps cannot be converted directly to model cost, and the shared gate only enforces this toy policy.
A real comparison would need: held-out requests with adjudicated outcomes; identical tools and permissions; measured intent and planning errors; model/version/prompt disclosure; tool-failure and injection tests; cost, latency, and human workload; and a workflow with comparable engineering effort. This exercise provides a question to investigate, not a deployment recommendation.