When to use a workflow and when to use an agent: the decision that determines everything else

A workflow is deterministic. An agent is not, and that single property cascades into every difference that matters. A chatbot is a brain in a jar: you type, it answers, the conversation ends. An agent is that same brain bolted into a body.

Start with the definitions, because the whole argument hangs on them. A workflow runs the same way every time: a trigger fires, an action follows, an output delivers. It does not hallucinate a step or skip a node because it got confused. It costs a fraction of a cent to run, and it breaks loudly and predictably the instant its assumptions fail.

The fixedness is the feature, not the limitation.

An agent is the same reasoning model with four things bolted on, and it is non-deterministic by design: it reasons, plans, chooses tools conditionally, and carries context across steps. That adaptability is its superpower and its failure mode in the same breath. Agents hallucinate, loop, call the wrong tool, and burn tokens fast when left unsupervised.

The four bolt-ons recur across nearly every teardown in the field, and the consistency is itself the signal. When many unrelated teardowns independently teach the same anatomy, you're looking at genuine consensus, not one creator's pet framing:

Put plainly: a chatbot is the brain alone, an agent is the same brain with four things bolted on. A chatbot can tell you how to do something. An agent just does it.

The cleanest way to feel the difference is an email agent, walked as an actual call sequence. Give both a chatbot and an agent the same instruction: send an email to Bob letting him know the report is ready.

The chatbot describes the task

The chatbot writes the text, "Hi Bob, the report is ready, best regards," prints it in the chat window, and stops. It produced a description of the task. Nothing was sent. It doesn't know Bob's address, and it would invent one if pressed.

The agent completes it

The agent runs the loop instead. It starts with one instruction and two tools, a contact-database lookup and an email sender. It reasons that it doesn't have Bob's address and has to look it up first, so it calls contact_database.lookup("Bob") and gets back bob@acme.com. Now it has everything it needs, so it calls email_sender.send(to="bob@acme.com", subject="Report ready", body="…"), sees the call succeed, hits its definition of done, and reports back: sent.

sequenceDiagram
    participant A as Agent
    participant C as Contact database
    participant E as Email sender
    A->>C: look up Bob's address
    C-->>A: bob@acme.com
    A->>E: send the report-ready email
    E-->>A: success
    Note over A: definition of done met

The shift isn't capability for its own sake. It's the move from generating text about a task to executing a plan that completes it, one tool call at a time, each call chosen from what the previous result revealed. Most failed "agents" are really the first behavior dressed as the second: a chatbot wired to an email API with no lookup step, no loop, and no definition of done, firing a message off to an address it hallucinated.

The engine under every agent is a three-step cycle that repeats until the agent decides it's done, and that last clause is where most builds quietly break.

• Observe: read all available context: files, prior tool outputs, the system prompt, research data, multimodal input, the current state of the world.
• Think: weigh that context against the goal and plan the next step based on what is true right now, not on what the model memorized in training.
• Act: call a tool, edit a file, run a command, hit an API. The result feeds straight back into the next Observe step.

The loop runs until the agent hits its definition of done, the explicit completion criterion most builders leave out. Without it the agent has no way to know it's finished, so it either stops too early or loops forever, burning tokens on a problem it already solved.

flowchart LR
  O["Observe"] --> T["Think"]
  T --> Ac["Act"]
  Ac --> D{"Definition of done met?"}
  D -->|no| O
  D -->|yes| Done["Stop"]

This loop is also what separates an agent from a workflow. In a workflow the path is fixed in advance. In an agent it emerges from reasoning at each turn. That emergence is the source of an agent's power and all of its problems, which is the next decision.

Use a workflow for anything where the same steps happen in the same order every time. Reach for an agent only when the task genuinely requires one of three things, and most tasks that feel agentic don't. This is where beginners light money on fire, and the operators who've shipped the most production systems are unusually unanimous about it.

The three conditions that actually justify an agent:

1. Multi-step reasoning across ambiguous data: the input shape varies and the model has to interpret it.
2. Tool use that can't be predicted in advance: which tool to call depends on what an earlier step returned.
3. Long-context retention: step eleven depends on what happened at step one.

If none of those hold, you have a workflow. Part of the field sells agents as the future and workflows as obsolete. That framing is wrong, and the people with the most shipped systems say so plainly: some of the most valuable automations ever built were purely rule-based. No models, no prompts, just clean logic moving data from A to B.

flowchart TD
  S[A task to automate] --> Q{Can you write the full decision logic in advance}
  Q -->|yes| W[Workflow]
  Q -->|mostly, except one judgment step| WM[Workflow with a single model node]
  Q -->|no, judgment on inputs you cannot enumerate| A[Agent, definition of done written first]

Two worked examples make the boundary concrete.

Competitor monitoring

To scrape a rival's pricing page every hour and email yourself the HTML diff is a pure workflow: a cron trigger, an HTTP node to fetch the page, a diff node against the last version, an email node to send the result. Zero reasoning. It costs a fraction of a cent a run and it breaks the instant the competitor renames a CSS class. But a system that reads which changes are strategically meaningful (a 20% price drop on a flagship product versus a typo fix on a terms page), drafts a response, and routes it to the right person needs an agent. That one pays roughly $0.15–$0.50 per run in tokens (reported). The first system shatters on novelty, the second adapts to it.

Lead handling

If the process is "new lead arrives, research them, draft an email, send it," that's a fixed path, and building an agent for it is a mistake. The better pattern is a linear retrieval workflow: an email trigger hits a vector-store search, a filter drops the low-relevance results, the survivors are aggregated, and a single model node gets exactly one job, all it has to do now is write the email. That cuts cost, minimizes hallucination, and gives you tight control over what data the model ever sees.

The rule under all of this: before you reach for a model at all, find the low-hanging fruit a plain logic gate already solves. If you can route it with if budget > 10000 or if inquiry_type == "sales", do not pay a model to classify text a rule already handles. That just adds cost and latency for nothing.

The sequencing that follows is the field's contrarian consensus: start with workflows, graduate to agents. Prove the linear flow first, add autonomous decision-making only once the deterministic version works and you've hit a real wall that reasoning is needed to cross.

The bet isn't that agents are bad. It's that most tasks that look agentic are well-specified enough for a workflow, and the cost, reliability, and debuggability trade-offs all point the same direction. Two of those are sharper than they first look.

• Reliability: the error math is unforgiving. An agent at 90% per-step accuracy compounds across a sequence: three such steps in a row clear only about 73% of the time (0.9 × 0.9 × 0.9). At production volume, that's the difference between a system you trust and one you babysit.
• Debuggability: a deterministic pipeline has one path to inspect and it fails loudly at a known node. An agent doesn't, which is the failure mode an over-agentified pipeline quietly slides into.

Here's the load-bearing insight, and it reframes the whole binary: most "agent" projects fail because they are workflow problems wearing agent costumes. If your agent does the same thing every morning at 9am, it's a workflow. Schedule it and move on. The operators who actually ship don't pick one or the other. They build hybrids: a deterministic layer handles the predictable 80% of the task (triggering, routing, retrying, logging) and a single reasoning node is injected only into the 20% that genuinely requires judgment. Save the full agent architecture for problems where the path to the goal is genuinely unknown at runtime.

So the decision isn't "workflow or agent." It's "workflow with a model node exactly where judgment is unavoidable, and a full agent only when you can't enumerate the branches at all."

A definition of done is the explicit, observable state that ends the agent's loop, plus the constraint set it must hold throughout, and writing it before the prompt is the move that pays off most in the whole build. Vague instructions plus an autonomous agent is the precise recipe for a runaway token bill. Given autonomy and no boundaries, the agent will scaffold files you never asked for and install frameworks you didn't want.

• Completion criteria: the specific, observable state that signals the task is finished. Not "research this topic" but "research this topic until you've identified at least eight sources with verifiable citations, then produce a structured summary." Not "write an email" but "produce a draft under 150 words, cite the source record, do not send." That's what ends the loop.
• Constraint set: the conditions that must hold throughout: "do not send any email without first showing me the draft," "do not delete a file without writing a backup path to the log," "stop and surface a question if you hit an input that matches none of the three categories." That's what keeps the agent inside the rails.

Bake the definition of done into every agent prompt. This one change eliminates most of the dissatisfaction operators report, the sense that the agent "kind of did the task but not really." The agent did exactly what was asked. What was asked was underspecified.

Around that core sits the prompt contract, a structured brief in four parts:

1. Goal: the specific outcome.
2. Constraints: what not to do.
3. Format: the structure of the output.
4. Failure: what counts as a bad result.

And around the contract, the full system prompt is built from a few standing elements:

• Role: who the agent is.
• Context: its inputs, including dynamic ones (inject the current date so the agent knows what "today" means instead of hallucinating one).
• Tool instructions: what exists and when to use each.
• Rules: the operating procedures that suppress hallucination.
• Examples: which double as direct counters to past failures.

The way you actually build that prompt is not by writing a wall of instructions up front. It's reactive prompting: start with an empty system prompt and one tool. Test. Watch what breaks. Add exactly one rule, and for a recurring failure add one concrete example, the exact input, the tool-call sequence, the desired output. Change one thing per cycle, so you always know what fixed what.

It's the same discipline as "start with workflows": grow the system one verified increment at a time.

Two layers an agent needs but that sit downstream of this decision live in their own pillars: the loop, the harness, runtime tool and MCP discovery, memory hygiene, and model-cost routing in agentic loop engineering, and production orchestration, evaluation, and observability in multi-agent systems in production. The catalogue of automations worth packaging, and what they sell for, lives in the productized-offer playbook. This piece stays on the one upstream call: workflow or agent.

Two questions hide inside "what to automate first": which tasks earn it and in what order (the scoring and the accuracy ladder), and how to build each (the workflow-vs-agent call, which keys off whether you can write the decision logic down in advance). Do the documentation honestly and the second answer falls out of it. Most people get it wrong by starting with something too hard or too consequential. Here's the explicit order.

Step 1: Document every manual step before touching any tool

Write down every task, input, and decision for one workflow. Just write down everything you do, every step, every task. Half the value shows up right here, because writing it down surfaces redundant steps you can simply delete, and the cheapest automation is the step you realize you never needed to run. Criterion: if you can't write the process down as discrete steps, it's not ready to automate.

Step 2: Score each candidate against four marks

Favor the ones that hit all four:

Aim at "boring" high-frequency work where people currently lean on agencies, freelancers, or hacky internal tools, and steer away from "cool" industries that are far more competitive. The sweet spot is the intersection of value and complexity, and one operator's heuristic is to "identify problems worth more than $50,000 to solve." Criterion: skip anything a plain rule already handles.

Step 3: Sequence by accuracy tolerance, not by ambition

This is the single most useful decision tool in the set.

Start with low-precision tasks where a miss is cheap and a human in the loop catches it. Defer high-precision work, because operators report the cruel shape of it:

An agent reaches roughly 80% accuracy in a week and feels almost there, then takes months to grind to the 98%-plus that critical roles require.

That long tail is where naive projects quietly die. Deploy the lower-precision tasks first for real production data and operational confidence. Only then invest the time the high-precision tasks demand. Don't attempt both at once.

🔒 authorize for free to reveal 76 words

Step 4: Make the workflow-vs-agent call

This is the decision from the opening chapters, now applied with real data in hand: documented, finite logic means a workflow (a model node only at the one step that needs judgment), and un-enumerable judgment means an agent, with its definition of done written first.

Step 5: Build the minimum viable version and verify before you trust it

Build it reactively, as above: one tool, one rule, tested on real messy data, not the happy path. Then, before any agent runs unattended, clear this checklist:

• It completes end-to-end with no manual intervention.
• Output matches the expected format, enforced by a structured-output parser or JSON schema, not by hope.
• Failure paths are handled. You know what happens when an API call errors.
• A human review gate sits on the first 10–50 runs.
• Success metrics are tracked.

Deterministic-first design is what keeps failure recoverable. The rest is a handful of guardrails that turn a silent corruption into a loud, catchable stop. The most dangerous automation works 95% of the time and quietly poisons data the other 5%.

• Approval gates on destructive actions. "Draft email" runs free. "Send email" requires approval. "Publish" requires approval.
• Read-only monitoring in production. A mission-control view watches what the agent did without ever touching the live session, and redacts secrets like API keys in previews. This is the pattern for any revenue-generating workflow.
• Model-switching visibility. Surface exactly when the agent escalates from a light model to a strong one, so you can trim the spots where heavy lifting happens unnecessarily.
• The walk-backward debug. When a task fails, don't rebuild the chain. Visualize the full path (prompts, tool calls, results, retries, model switches, retrieved memory) and start at the final result, walking backward. The weak link is almost always one or two steps before the end.
• Analytics, or you're flying blind. Track sessions per agent, tool calls per session, tokens per model, peak hours. The read is simple: if weekly cost is up 30% and output is up 60%, the system works. If cost is up 30% and output is flat, you have a loop somewhere.

Beyond the two big ones already covered (over-agentifying deterministic plumbing, and skipping the definition of done), three more failure modes recur often enough to name:

1. Only ever giving the system easy tasks. Automate only the easy low-precision work and you never discover what the system can do on hard tasks, nor build the validation hard tasks require. The accuracy ladder is a starting point, not a ceiling.
2. Skipping the memory layer. An agent without persistent memory produces generic output that ignores everything the business learned on previous runs. Even a simple append-only file of past decisions materially improves later output.
3. Trusting output without verification. AI is confidently incorrect more often than operators expect, especially on factual precision and domain-specific knowledge. Verification isn't a phase you exit. It's a standing discipline. Spot-check outputs, demand citations, and define what a wrong answer looks like before you deploy, so you recognize one when it appears.

Verification is never "it ran without errors." It's "the output is good enough to ship." The cadence that gets you there is boring on purpose.

Week 1: establish the baseline

Deploy on real input, but do not run it autonomously. Review every output. This is calibration: the first week is where you catch the edge cases your prompt didn't handle and the ways your definition of done was underspecified.

Weeks 2–4: tighten and extend

Fix the week-one edge cases. Add output validation where the data shows consistent failure modes. Raise volume once the error rate on real input drops below your stated tolerance. By the end of the month you want one workflow running daily and one agent-assisted judgment step, both verified on real data.

Ongoing, a weekly cadence

Check error rates on a held-out sample, spot-check outputs, and watch whether the task structure has shifted. Track error rate per task type, cost per completed task against a ceiling, time-to-completion versus the manual baseline, and the share of runs that clear your precision threshold without correction.

Verify which kind you built: run the same input twice

A workflow produces identical output. An agent may not, because its reasoning path is non-deterministic. If your task requires identical output for identical input and you built an agent, you built the wrong thing.

• A correct workflow shows consistent output, loud failures at a specific node, linear cost, and no quality drift.
• A correct agent shows output that improves as the definition of done is refined, graceful handling of novel inputs, stop conditions that fire reliably instead of looping, and an audit trail of the steps it took.

The decision criteria, compressed to a card you can apply at every step:

• Identical task shape every run → workflow node.
• Choice between tools based on intermediate results → agent.
• Silent failure or variable output needing review → add an approval gate.
• Over ~30 minutes of continuous operation → an agent that compacts or resets its context between chunks, or scheduled chunked execution.

The model alone is sharply limited. The harness around it (the tools, the memory, the runtime tool discovery, the feedback loops) is what turns raw capability into reliable, verifiable work. An agent isn't the model. It's the model wrapped in infrastructure: roads (tools), communication (MCP), and storage (memory).

The corollary is the honest limit on all of it.

You can outsource your thinking, but you cannot outsource your understanding.

The agent absorbs the cognitive load of processing, but the human stays the director who decides the project is worth building, supplies the judgment and the taste, and catches the errors. And there will be errors. The review gate on the first 10 to 50 runs is not training wheels you outgrow, it's the standing price of letting a non-deterministic system touch anything that matters.

Access to a strong model in 2026 is roughly uniform. The winners won't be the operators with the best model. They'll be the ones who build the best harness, and who ship fastest, learn from the output, and compound by automating the next bottleneck.

Humans for judgment, agents for execution. Start deterministic. Add reasoning only where it earns its keep. Schedule everything, so the system builds while you sleep.

The decision that determines everything else is the one you make before any model or platform: workflow or agent, deterministic by default, an agent only where the path to the goal is genuinely unknown until it runs.