Agent vs workflow

Most things people call "agents" are actually workflows. A workflow is a fixed sequence of steps that an LLM helps with. An agent is a loop where the LLM picks the next step. The distinction matters because agents are slower, pricier, and less reliable. Use an agent when you need one. Use a workflow when you can. Most production systems are workflows with a tiny agent in the middle for the parts that actually need exploration.

The core distinction

A workflow is a script. You wrote the steps. The order is fixed. An LLM runs inside some steps (classify this email, summarize this doc), but you decide what happens next.

An agent is a decision-maker. It reads the current state, picks the next action, runs it, reads the result, picks again. The order is emergent, not authored.

If you can draw the flowchart in advance, it's a workflow. If the flowchart has a box that says "the LLM figures it out," it's an agent.

Picture it

When a workflow wins

• Steps are predictable. Every invoice gets parsed, validated, entered, and emailed. The order never changes.
• Latency matters. A workflow runs in fixed time; an agent takes whatever it takes.
• Cost matters. Workflows make N calls where N is known. Agents make N calls where N could be 3 or 30.
• Reliability matters more than cleverness. Workflows fail in predictable ways. Agents fail in creative ways.
• You can debug it. Workflow bug: look at the failing step. Agent bug: read 40 turns of trace to figure out why the model decided to loop forever.

When an agent wins

• Steps are unknown until runtime. Debugging a production issue. You don't know if step 2 is "check logs" or "run a query" until step 1 tells you.
• The task branches widely. Customer support: the next action depends on what the customer said, what their account shows, what they've tried.
• Tool selection is the hard part. You have 15 tools; figuring out which two to call is most of the task.
• The task benefits from self-correction. Code → test → fix → test. You can't hardcode how many iterations it'll take.

A worked example: invoice processing

Your company ingests 500 invoices a week. Flag fraudulent ones. Route the rest to accounting. Workflow or agent?

Mostly workflow. 98% of invoices are normal: extract fields, validate the math, match to a PO, approve. Fixed flow. Runs fast, costs cents.

Agent for the weird ones. When validation fails (missing PO, amount mismatch, unknown vendor) the workflow hands off to an agent. The agent can look up the vendor, check recent emails with that vendor, ask a human, escalate, or reject. The agent handles 2% of volume but 80% of the interesting decisions.

That hybrid is the shape of most good production AI systems: a workflow with a tiny bounded agent at the decision points that actually need it.

Cost and latency, side by side

The anti-pattern: agent wrapping a fixed sequence

You built an "agent" and its trace always looks like this: call tool A, call tool B, answer. Every time. That's not an agent, it's a workflow with extra steps. You're paying for the LLM to re-decide a decision you already know. Refactor it into a workflow and save 60% on cost and latency.

The other anti-pattern: workflow where you needed an agent

You hard-coded a flow and now every new edge case means a new branch. The code turns into a 400-line if/else tree. The LLM would pick the right path trivially if you gave it the choice. Signal: your flowchart keeps growing and you're scared to touch it.

A practical decision rule

1. Write out the happy path as a workflow. 80% of your volume fits here.
2. List the edge cases. If there are fewer than 3, branch in code.
3. If there are more than 3, put an agent at the decision point. Give it 3-5 tools, a max step count of ~10, and a cost cap.
4. Never wrap the happy path in an agent. Only the branches that actually need reasoning.

What to do with this

• Read when not to use agents - this page's sharper sibling.
• Then the agent architecture map to see where an agent fits inside a larger system.