Stop reaching for an agent when a workflow will do

At our last Eng All Hands, Brandon Shar (Staff AI Engineer, Registry AI) and Drew Morris (AI Solutions Architect, Business Operations) walked through one of the most consequential decisions in AI engineering: should a given feature be an agent or a workflow? It's a decision more of us will be making as AI shows up in more of what we build.

This post is my summary of their framework: how to tell which kind of problem you have, and why the answer changes almost everything about how you build it.

The short version, if you read nothing else: default to a workflow. Reach for an agent only when a workflow genuinely can't describe the problem.

AI engineering isn't harder, it's different

Before getting to agents and workflows, it's worth clearing up a misconception. Building with LLMs isn't more complex engineering — it's still API calls, loops, and the same security and abuse-prevention work you already do. The difference is that three properties show up here that don't show up in a normal service:

• Non-determinism. The same input can produce two different outputs on two different runs. Your test suites and retry logic need to account for that.
• It's a user, not a client. An LLM reasons and improvises the way a person would, not the way a deterministic front-end does. You have to design responses, context, and tools for a reader, not a caller.
• Agency vs. control. Every design decision you make trades one for the other. More agency (the model deciding what to do) means less control (you predicting what it'll do). This tradeoff runs through everything below.

What actually makes something an agent

An agent has a goal, not just a prompt. It reasons about what to do next, calls tools, watches what comes back, and loops until it decides it's done. This is usually described as a Reason → Act → Observe loop: the model reasons about the next step, acts by calling a tool, observes the result, and repeats until the task is finished.

Three signals tell you a problem is genuinely agent-shaped:

1. The problem space is unbounded. You can't list all the inputs or edge cases ahead of time. "Recommend a product based on what this user needs" looks bounded (there's a finite catalog) but the reasoning path to get there isn't.
2. The steps aren't knowable in advance. "Figure out why our error reporting stopped working" is open-ended discovery — the path depends on what you find along the way.
3. It has to reach outside the LLM. Searching, reading, writing, or calling something in the outside world, not just producing text.

Claude Code is a real example of all three: even a coding agent is just the same Reason → Act → Observe loop, reasoning about what to do next, acting by running a tool, observing the result, and looping until the task is done. It's powerful because you hand the model the steering wheel — but that also means giving up the ability to predict exactly what a given run will do. Agents are slower and more expensive than deterministic code, and they can solve a problem in a way you didn't intend. High agency means low control. An agent is a tradeoff, not a shortcut — don't reach for one just because it sounds more sophisticated.

What a workflow buys you instead

A workflow is "LLMs on rails." You define the sequence, the branches, and the loops in code, and the model fills in only the parts that genuinely require judgment. Three signals tell you a workflow will work:

• You can describe it in plain English. "First do this, then that, and if X is true, do Y." If you can walk a teammate through the steps, the model can run them.
• The branches are knowable in advance. There may be several paths, but you can enumerate them. The model picks among the options you defined — it doesn't invent new ones.
• Success is checkable at each step. A schema validates, a value falls in range, a label comes from a known set. If you can't check a step, you can't reliably build past it.

Building a workflow that survives contact with reality

Five steps turn a rough sketch into something you can trust:

1. Gather a golden dataset. A handful of real inputs with known-correct outputs, so you can tell if you're winning before, during, and after shipping.
2. List the steps, in the order a person would do them, one unit of work per step.
3. For each step, ask if it actually needs an LLM. Lookups, math, and retrieval are things code already does reliably — save the model for the fuzzy parts only it can handle.
4. Mark the branches, loops, and parallel opportunities. Where does the path fork? Where do you retry, or have a critic check a writer? What can run concurrently?
5. Make every step observable. Log inputs, outputs, and the model's reasoning. If you can't inspect a run, you can't debug or improve it.

Babylist's BizOps ticket tagger is a good illustration. It's three steps, and only two involve an LLM call at all: an LLM call extracts the customer's intent from a support transcript, a plain vector search (no model call) retrieves the closest matching categories, and a second, smaller LLM call picks the right category from that shortlist. Letting code do what code is good at — retrieval — keeps the prompt small, the cost down, and the accuracy up.

You'll mix four patterns to build almost any workflow: sequential (each step feeds the next), parallel (fan out, then fan in), branching (an LLM call chooses between code-defined paths), and loops (an actor writes, a critic reviews, and the loop exits when the critic is satisfied).

The default: workflow until proven otherwise

Picture a line with full control on one end (a single LLM call with a structured, schema-validated output) and full agency on the other (a fully autonomous, open-ended agent). Most real systems sit somewhere in between, but for production work, start as far toward the control end as the problem allows.

Building the workflow first pays off even if you eventually need an agent: working through the five steps above surfaces exactly what information and tools an agent would need, so you're not guessing. And if you do end up needing a genuinely autonomous agent, those same workflows can become tools themselves so you can keep control where it fits and provide power where it can't.

Let the problem tell you how much agency it needs

Underneath the whole decision is a single tradeoff: control against complexity. Agency lets you handle problems you couldn't spell out in advance — but you pay for it in control, in your ability to predict what a given run will do. So the goal isn't to pick a camp. It's to take on only as much agency as the problem actually demands, and not a notch more.

That's the real case for starting with a workflow. When you first pick up a task you usually can't enumerate everything it will throw at you; the edge cases surface as you go. Rails let you meet that complexity in a controlled way — you know, call by call, how the model will fire — and, crucially, the workflow itself shows you exactly where the rails aren't enough. That's where you raise agency, and only there. Often you find you barely need to: a well-defined workflow gets you surprisingly far. And where you do hand over control, the same visibility tells you where to put the guards — the checks that confirm the model's answer is right before the workflow trusts it.

None of this means you never start with an agent. Sometimes you can see from the outset that the input space is too large to enumerate — you genuinely can't list the ways the thing will be asked — and the honest move is to accept the loss of control and start agentic. Eyes open, not by default.

The napkin test

If you're scoping an AI feature this quarter, start with the napkin test: can you sketch the steps in plain English, and check success at each one? If yes, build a workflow. If you genuinely can't — the problem space is unbounded, the steps aren't knowable, or it has to improvise its way through outside systems — that's your signal to reach for an agent, eyes open to the tradeoff you're making.