Autonomy is seductive and expensive. The hard part of agent engineering is knowing when you don't need an agent at all.
"Should we build an agent?" is the wrong first question. The right one is: how much of this task is genuinely unpredictable? Most business processes are far more deterministic than they look, and a deterministic pipeline is cheaper to build, easier to debug, and far more reliable than an autonomous agent. Reach for autonomy only where the path truly can't be known in advance.
What a workflow is good at
A workflow is a fixed sequence of steps, some of which may call a model. Extract fields from this document, validate them, look up the customer, draft a reply, send it for approval. The steps don't change run to run. Workflows are predictable, testable, and observable — you always know what happened and why.
- The steps are known ahead of time.
- You need consistent, auditable behavior.
- Failure should be obvious and easy to trace.
What an agent is good at
An agent decides its own next step. Given a goal and a set of tools, it plans, acts, observes the result, and re-plans. That flexibility is exactly what you want when the path can't be enumerated — open-ended research, multi-step troubleshooting, tasks where the right sequence depends on what you find along the way.
- The path genuinely varies with the inputs.
- The task needs tool use and iteration to converge.
- You can define guardrails and a clear definition of done.
Use the least autonomy that solves the problem. Determinism is a feature, not a limitation.
The hybrid that usually wins
In real systems the answer is rarely all-or-nothing. The strongest designs are mostly deterministic workflow with a small agentic core for the genuinely open-ended step — and deterministic guardrails wrapped tightly around that core: scoped, least-privilege tools, budgets on steps and cost, human approval for irreversible actions, and a trace of every decision.
A simple decision rule
Start with a workflow. Promote a step to an agent only when you can't write down its sequence in advance — and when you do, constrain it hard and evaluate it on real tasks before rollout. The goal isn't the most impressive architecture; it's the simplest one that reliably gets the work done.
