When Not to Use an Agent: Prefer Workflows Over Autonomy

Not every automation problem is an agent problem. I say that in rooms where people are excited, because excitement is expensive when it funds the wrong pattern.

Agents shine when the path is variable and judgment-ish within bounds. Plenty of work is not like that. It is the same steps, same systems, same validations, every Tuesday. For that, a fixed workflow, a rules engine, or classic RPA can be clearer, cheaper, and easier to audit than a model that re-plans from scratch on every run.

Autonomy has a cost even when it works

An agent that re-plans each time pays for flexibility with variance. Two runs on similar inputs may take different tool paths. That can be fine for researchy tasks. It is awkward when finance asks why invoice matching took seven steps on Monday and three on Tuesday, and whether both were correct.

Costs that show up after the demo:

• Harder regression testing (paths are not fixed)
• Heavier logging and explanation needs
• More tokens, more tool calls, more spend variance
• Training and ops burden for a system that is partly non-deterministic

If your main requirement is "same steps, every time, prove it," start with a workflow. You can still use an LLM inside a step for drafting or classification without handing the whole process to an autonomous planner.

Cases where fixed process usually wins

Prefer a defined workflow when:

• The path is stable. Same sequence for most cases, with known branches.
• Audit wants determinism. Regulators or internal audit need a repeatable trail more than creative problem solving.
• Errors are expensive and similar. You need the same validation every time, not a novel approach.
• Systems are screen-driven and brittle. Classic RPA may already fit, with clear exception queues.
• Throughput is the goal. High volume, low variation work often likes simple automation better than multi-step agents.

Example: every new vendor must pass the same five checks, write the same fields, and land in the same approval queue. A BPM-style flow or even a well-built form with rules may beat an agent that "figures out" vendor onboarding differently each week.

Where rules engines and RPA still earn their keep

Rules engines encode decisions you can inspect: if amount > X and country in list Y, route to team Z. People can read them. Tests can cover them. Changes go through change control.

RPA (robotic process automation) mimics UI steps when APIs are missing. It is not glamorous. It can still be the right hammer when the UI is stable, volume is high, and you do not want a model improvising clicks.

LLMs can sit beside these tools: classify a document, extract fields, draft an exception note. The orchestration stays fixed. That hybrid often beats an all-agent design for operational work. For mapping those processes clearly before you automate, a simple swimlane still helps; I keep a free option on the site for that kind of thinking in the process map studio.

When an agent is still the better fit

Use agent-style autonomy when the work product is clear but the path varies: gathering context from several tools, drafting a pack, reconciling messy lists, exploring a codebase, assembling a first-pass analysis for human review. I describe that loop more in what agentic AI actually is, and the sponsor tradeoffs in chatbots, copilots, and agents.

Even then, many "agents" in production are really workflows with LLM steps and a few tool calls, not free-roaming planners. That is fine. Marketing language should not force architecture.

A decision sketch you can run in one meeting

For a candidate process, answer these quickly:

1. Can a competent new hire follow a written SOP for most cases without inventing steps?
2. Do we need the same path for audit, or only the same outcome?
3. Are exceptions rare and classifiable, or constant and novel?
4. Is the expensive part judgment and synthesis, or clicking the same path?
5. What happens if two runs take different routes? Is that acceptable?

If (1) is yes, (2) is "same path," (3) is rare, (4) is clicking, and (5) is "not acceptable," you probably want workflow/RPA/rules first. If the expensive part is synthesis across messy inputs and different routes are fine as long as a human reviews the artifact, an agent (with gates) may earn its complexity.

How this saves money and credibility

Teams lose credibility when they put an agent on a problem that a queue and a rules table would solve. Sponsors notice. Ops notices when the "smart" path is harder to support than the boring one.

Prefer the simplest mechanism that meets the control and quality bar. Add LLM or agent behaviour where variability and language understanding actually pay rent. Keep human approval where impact is high, as in production human-in-the-loop design. Invest in tool safety when you do automate with models, because tool use is usually the hard part.

The practical takeaway: not using an agent is a valid AI strategy. Fixed workflows, rules, and RPA still carry a lot of operational load, often with better audit stories. Reach for autonomy when the path must flex and the finished work still needs judgment. Reach for a defined process when sameness is the feature, not the bug. If you only remember one filter, use this: if you would be unhappy that two runs took different routes, do not start with a free-planning agent.