When not to use an agent

Most "agent" problems I see are workflow problems wearing an agent's clothes — a fixed sequence of steps, dressed up with an LLM in the loop because the sequence involves text. The tell isn't the technology. It's whether the steps were ever actually in doubt.

Who this is for: an engineer about to build an agent for a process that, on reflection, always does the same five things in the same order.

The question that decides it

Before reaching for an agent: write down the steps your process takes, in order, for ten real examples. If all ten produce the same sequence — even if the content at each step differs — that's a workflow. If the sequence itself genuinely varies based on what happens at each step, and you can't write the branches down in advance because there are too many or they're not knowable yet, that's the actual case for an agent.

Most teams skip this exercise and build the agent first, which is how a fixed five-step pipeline ends up implemented as an LLM deciding, from scratch, on every single run, to do the same five things in the same order. It works. It's also strictly worse than the workflow on every axis that matters: slower, more expensive, and — per the five failure modes agents actually have — carrying failure modes a deterministic pipeline doesn't.

What a workflow gets you that an agent doesn't

A state machine with fixed transitions is faster, because there's no model call deciding what happens next — the next step is just the next step. It's cheaper, for the same reason. It's testable in the ordinary sense: given this input, assert this output, no eval harness required because there's no judgment being exercised to evaluate. And it fails loudly — a workflow that hits an unhandled case throws, where an agent that hits one improvises something plausible-looking and wrong.

None of that means the LLM disappears. It means the LLM gets called for the one step that actually needs judgment — classifying an ambiguous input, drafting text, extracting structure from something unstructured — inside a pipeline that's deterministic everywhere else. That's not a downgrade from "agent" to "workflow with an LLM step." For most of what gets built as an agent today, it's the correct architecture that was available the whole time.

Where an agent is the right call

Genuine agent territory: the next action depends on a result you can't predict before you see it, across enough distinct paths that hand-coding the branches isn't practical. A support triage system where the right escalation path depends on what the user says and what a lookup returns, and where the combination of the two has too many meaningful branches to enumerate — that's real. A five-step data pipeline that always ingests, validates, transforms, loads, and notifies, in that order, regardless of what's in the data, is not, no matter how much natural language touches it along the way.

The overhead an agent brings — the failure modes, the audit trail it now needs if it takes real actions, the added latency and cost of a model deciding rather than a rule dispatching — has to be worth paying for. It's worth paying for when the branching is real. It's a tax with no return when it isn't.

The honest check

If you've already built the agent and want to know whether it should have been a workflow: look at your own logs for a week. If the sequence of steps taken is the same sequence, every time, regardless of input — you built a slow, expensive, harder-to-debug version of a state machine, and simplifying it isn't a downgrade, it's a fix.

If the sequence genuinely varies in ways you couldn't have enumerated in advance, you built the right thing, and the next investment is making its actions accountable, not questioning whether it should exist. And if the real question isn't one agent versus a workflow but one agent versus several coordinating ones, the same discipline applies one level up.

Telling these two cases apart before building — not after — is usually the first conversation worth having.