Do you need an AI agent or just a workflow

Almost certainly a workflow. A fixed sequence of steps your own code controls, with one model call at the step where the answer is genuinely ambiguous, is cheaper to build, testable in CI, debuggable at two in the morning, and sufficient for most of what arrives here described as an agent. An agent, meaning a system that picks its own next step at runtime, earns its cost only when the path cannot be written down in advance.

The test is a whiteboard. If you can draw the process as a flowchart and the person who runs it today agrees with the drawing, build the flowchart and put the model in one box. What follows is why that is the boring right answer, what you give up when it isn’t, and how to tell which one you are holding.

The line between the two is control flow, not intelligence

Anthropic’s engineering write-up Building effective agents draws it plainly: a workflow orchestrates models and tools through predefined code paths, while an agent directs its own process and tool use. Its standing advice is to find the simplest thing that works and add complexity only when it demonstrably improves the outcome. OpenAI’s practical guide to building agents lands in the same place: reach for an agent when deterministic, rule-based approaches have run out, not before.

The distinction is not about model quality or tool count. A workflow can call six tools and a frontier model and still be a workflow, because your code decided the order. An agent can have two tools and still be an agent, because the model decides the order and when to stop. One concession: the word has been flattened, and much of what is sold as an agent is a workflow with good branding. That is usually fine. It stops being fine when a buyer reads the label, asks for the architecture, and gets it.

The flowchart test, and the three questions after it

Draw it. Boxes for steps, diamonds for decisions, arrows for what follows what. Then ask three things.

• Is the list of steps finite and known before the run starts? If you can enumerate them, the orchestration belongs in code. Enumerable is the whole test.
• Do the branches turn on facts or on judgement? Amount over a threshold, customer tier, file type: facts, and they belong in an if statement. Whether a complaint is about billing or delivery, whether a clause is unusual for a contract of this kind: judgement, and that is where a model call goes.
• Would you train a new hire with a checklist or by having them shadow someone for a month? A checklist is a workflow. An apprenticeship is a hint, not proof, that the path is discovered rather than followed.

If the drawing takes two attempts and a colleague argues about one arrow, that is normal and you still have a workflow. The signal that matters is different: every new example adds a box, and after forty examples nothing has converged. Keep drawing until you know which you are in. It costs an afternoon and it decides the shape of the build.

Where the model actually goes

Inside a workflow the model does one thing at a time and returns something a schema can validate. Classify, extract, draft, rank, summarise. Constrained output, a known token profile, testable code on either side of it.

The shape behind most document automation: receive, dedupe, convert to text, one model call that extracts fields into a schema, validate totals with arithmetic rather than with a language model, route anything under a confidence threshold to a review queue, post to the system of record, reconcile. Eight steps, one model call, and the only non-deterministic part is fenced in. We took that pipeline apart in how to automate document processing without a data team. Ticket triage is the same skeleton, and a planner would only make it worse in ways that surface in production rather than in the demo.

What agency actually costs you

The pitch is capability. The invoice is for five other things, none of which appear in a demo.

The same input stops producing the same run

Temperature zero does not rescue determinism here, because the path itself is chosen from model output: a different tool result on step three produces a different plan for steps four through nine.

Sierra’s tau-bench, published in 2024 as a benchmark for tool-using agents in retail and airline domains, is the cleanest public statement of the problem. Its contribution is the metric rather than the leaderboard: run the same task several times and report how often the agent gets it right on all of them rather than on one. That figure falls sharply as trials rise. Agents that solve a task once often fail to solve it consistently. In a workflow the orchestration scores one hundred percent, because it is code, and the model call scores whatever its evaluation set says. Two numbers you can move independently beats one that moves for reasons you cannot isolate.

Token spend scales with reasoning, not with volume

A workflow has a cost per unit of work you can compute before you build it: fixed prompt, bounded context, one call, multiply. Forecast it as in how to forecast LLM cost per user and the answer lands close, because the token path barely varies with the input.

An agent’s cost is a distribution instead of a number. A run that resolves in four tool calls and one that thrashes through twenty-six both count as one job in your volume forecast and differ by an order of magnitude on the bill. Two mechanics drive it. Reasoning tokens are billed as output, and output is the expensive side: Anthropic’s published pricing for its Sonnet tier is $3 per million input tokens against $15 per million output tokens, so tokens spent thinking cost roughly five times tokens spent reading. Check live pricing before quoting anyone, because these move. Second, every tool result is appended to the context, so step ten pays for the history of steps one through nine. Budget on the tail rather than the mean, and expect the tail to be fat.

Evaluation stops being a test suite

For a workflow, testing is ordinary. Fixture in, expected output, per step. The model call gets an evaluation set of a couple of hundred labelled examples and a regression run on every prompt change: a morning of setup that pays for itself the first time somebody edits a prompt on a Friday.

For an agent the unit under test is a trajectory. Two failures matter: the right answer reached through a path that also emailed the wrong customer, and the wrong answer reached through a reasonable path. You score the destination and the route. Repeated trials multiply the cost of every run, and judging a trajectory usually means a model judging a model, which adds a second error rate you need a held-out set to measure. Our own estimate: the evaluation harness runs a quarter to a third of an agent build. It is the line item most often cut in negotiation and most often regretted, because without it nobody can say whether last week’s prompt change helped.

Failures that will not reproduce

A user reports that the thing did something wrong on Tuesday. You run the same input and it behaves perfectly. Nothing threw, and the branch was invented at runtime and discarded. The only answer is to have captured the run: every prompt, every tool call with arguments and result, every token count and model version, retained long enough to be useful. That is storage, a viewer somebody has to build, and a retention policy legal has to agree with. It is rarely in the estimate.

The on-call surface

Things a workflow does not need and an agent does: a hard ceiling on steps per run, a spend cap per run and per day, loop detection because the classic failure is not a crash but a polite infinite conversation with itself, a kill switch a support lead can reach without a deploy, tool permissions scoped so the worst available action is survivable, and an alert on cost per run rather than only on error rate, because the expensive failure is the run that succeeds slowly. Add the idempotency and durable execution we set out in background jobs in Next.js. None of it is the feature, and all of it ships before the feature can be left running overnight.

When the agent is genuinely the right build

There is a real category here, and pretending otherwise would be the mirror image of the hype. Build an agent when the steps cannot be enumerated because they depend on what the run discovers.

• Open-ended research across sources you cannot name in advance, where the second query is a function of the first answer.
• Failure triage, where which log to read next depends on what the last error said.
• Remediation across a mixed estate, where each item’s obstacle is only visible once you are inside it.

The branch count is combinatorial and the useful branches get discovered mid-run. For that, a flowchart is not a simplification, it is a lie you then have to maintain.

Two conditions before you commit. A wrong path has to be cheap and reversible, or a human has to approve before anything reaches a system of record. And you need real transcripts of people doing the job: without a hundred examples with the correct end state marked, you cannot tell whether the agent works and you will ship on a demo, which is the happy path with warm tools and a cooperative prompt. The fair request, of us or anyone, is ten runs of the same task, all ten shown.

The shape almost everyone should build first

Between the extremes sits the thing most teams actually want: a deterministic graph with one bounded loop inside it.

The orchestration stays in code: your steps, your order, your retries. One node is permitted to iterate, with a fixed tool list, a ceiling on iterations, and a schema its output must satisfy before the graph moves on. Anything that fails validation twice goes to a person rather than round again. Our own defaults: a ceiling around five iterations, and a review queue for everything under the confidence threshold.

That buys most of what people mean by an agent, which is usually that the model can look something up before answering, while keeping a cost ceiling, a reproducible outer path and a CI test. Underneath it, use an orchestrator that survives a crash, so a run that dies at step six resumes rather than restarts and re-bills. We reach for Python with LangGraph or Temporal, and n8n where the ops team should be able to edit the flow without calling us. The tool matters far less than the property: control flow lives in code somebody can read.

Then let it earn its promotion. If after three months the loop keeps hitting its ceiling on cases a person solves easily, you have both the justification for an agent and the labelled data to evaluate one. That order is much cheaper than the reverse.

When we would tell you to build neither

This is the section that costs us work, so it goes in plainly.

Volume. If the process runs a handful of times a week and a person handles each one in ten minutes, neither shape pays back. Our own rule of thumb, not a study: under roughly two hundred instances a month, with no accuracy or latency problem, the payback runs into years and you are better off with a form, a checklist and a shared queue. Requests to automate low-volume work are usually requests for consistency, which is a cheaper purchase than either of these.

The wrong diagnosis. If the real problem is that four people edit a workbook and nobody knows which copy is current, that is a data problem, and the answer is in moving a spreadsheet into an application. If the model simply does not know your content, that is retrieval, and RAG versus fine-tuning is the piece to read. Neither is fixed by more autonomy, and both get worse with it.

Our own bias, since it points one way. An agent is more interesting to build and easier to sell than a state machine with a classifier in one box. It photographs better in a proposal and it justifies a larger number. If we propose one, the right challenge is to ask us to draw the flowchart we have just claimed cannot be drawn. If we can draw it, we were wrong, and the correct response is to build the drawing.

What each of these costs to build with us

Our published bands, unchanged for this article. The tier follows from the decision above rather than from ambition.

Outside the table: our minimum for a build is $7,500, a scoping sprint is $3,500 for a week and is credited in full against a build that starts within thirty days, support retainers start at $2,500 a month and AI advisory at $4,000 a month. Payment is half on contract and half on delivery, split into milestones above $30,000. Most of the work we take lands between $18,000 and $45,000.

The agent version of a brief costs more for reasons unrelated to the model call: the evaluation harness, the trace capture and a viewer over it, the spend caps and step ceilings, and the review interface somebody needs in order to approve anything. That is the surcharge on autonomy, and it is why the honest answer to a vague agent brief is a higher number. The same force is at work in fixed price versus time and materials: undefined scope carries a buffer, and autonomy is undefined scope by construction.

The compressed decision

Draw the process. If the steps are enumerable, build the flowchart in code and put one model call at the step that needs judgement, with a schema on its output and a review queue under a confidence threshold. If some cases need a lookup first, allow one bounded loop in one node, with a step ceiling and a spend cap. Build an agent only when new examples keep adding boxes, when the wrong path is cheap or a human approves first, and when you have a hundred labelled examples to evaluate it against.

Check the volume before any of it. Under a couple of hundred runs a month the answer is often a form. For a second opinion on which of these you are holding, send us the flowchart rather than the vendor deck and tell us where it stops converging. We will say if the answer is eight boxes and one model call, which it usually is, and what building that involves.