Workflow vs agent: use the simplest thing that works

A workflow follows fixed steps

Here is the whole decision in one line: if you can write the exact steps down and they never change, build a workflow; if the right step depends on reading and judging messy input, reach for an agent. Everything below is just that rule, tested from different angles.

Use ordinary automation when the inputs are structured and the path is predictable—copy a form response, rename a file, calculate a total, send a standard confirmation. It matters because a workflow does the same thing every run, so it is fast, cheap, and easy to trust; there is nothing to review, because there was never a decision. How to judge it: could a new hire follow the steps from a checklist without using any judgment? If yes, it is a workflow.

The failure case is wrapping a settled task—“move paid invoices to the Done tab”—inside an agent, which then reinvents a slightly different rule each run and turns a solved problem into something you supervise. The trade-off is real, though: a workflow is rigid. Change the form and it breaks until you update it, and it will not quietly absorb an input it was never told about.

An agent handles judgment within boundaries

Use an agent when the work involves messy language, comparing sources, choosing among several acceptable paths, or drafting something that needs context. These tasks have no fixed steps to write down, because the right action depends on what the input actually says—not on a rule you set in advance.

How to judge it: if two sensible people would handle the same input two acceptable ways, that variability is exactly what an agent is for. Give it named sources and a clear boundary so its judgment stays inside a fence. The failure case is the unbounded agent asked to “handle support,” which wanders past its sources and answers a refund question it was never meant to touch.

The trade-off: flexibility comes with variability. An agent's output needs a glance before you rely on it, which is why a first job stays in draft rather than sending on its own. You are trading a guaranteed-identical result for one that fits the situation—useful, but never free of review.

Sort the task by its input, not its label

When you are unsure, do not argue about whether something “feels like AI.” Look at the input. Structured and fixed points to a workflow; messy and variable points to an agent. The same job often contains both.

The failure case here is mislabeling “summarize customer themes” as a workflow and building keyword rules for it—rules that miss sarcasm, new phrasing, and the complaint nobody predicted. The trade-off is that these categories blur at the edges: “draft a reply from policy” is an agent job for the wording but a workflow job for the sending, which is the whole reason to combine them rather than pick one.

Combine them deliberately

The strongest designs are rarely either/or. Let a workflow validate the inputs and deliver the outputs; let the agent handle only the uncertain middle. This keeps flexible reasoning away from the steps that must stay deterministic—money moving, records changing, messages leaving the building.

How to judge it: draw the task as capture → interpret → act. The first and last steps should be fixed rules; only the middle needs judgment. The failure case is letting the agent both decide and send, so a wrong judgment leaves the building before anyone sees it—the single most common way a helpful agent becomes an expensive one.

The trade-off lives in the seams. Every hand-off between the fixed steps and the agent needs a defined format—one of six lesson names, a category from a short list, a yes or no—so the workflow can trust what the agent produced. Loose hand-offs are where the bugs hide.

The maintenance test

When it is genuinely a toss-up, decide by the version you will have to maintain. If every “smart” agent step becomes a growing list of exceptions you keep patching, a plain workflow is probably clearer. If a fixed workflow breaks every time the wording shifts and you rewrite its rules weekly, an agent may reduce that upkeep.

This matters because the cheapest system to run is usually the cheapest to keep running, and maintenance is where the real cost hides. How to judge it: after a month, count how often you edited each part. The version you touch less is the right call, regardless of which sounded more impressive on day one.

The failure case is choosing the ambitious option and inheriting a black box you cannot debug when it drifts. The trade-off worth naming: simple workflows fail loudly—they stop, and you notice. Agents fail quietly—they keep going with a slightly wrong answer. So an agent's time savings must be large enough to cover the cost of watching it.