Workflow or Agent? A Decision Framework for Enterprise AI

First, Define What You're Actually Choosing Between

The words get muddy fast, so let's be precise. A workflow is a path you wrote: a deterministic chain of LLM calls and tool invocations where you control the order, the branches, and the exit conditions. The model fills in the hard parts — classification, extraction, generation — but it doesn't decide what happens next. You do.

A true agent inverts that. The model controls its own loop: it decides which tool to call, reads the result, decides the next action, and decides when it's done. You hand it a goal and a toolbox, not a path. That's a fundamentally different reliability profile, because the control flow itself is now non-deterministic.

The mistake we see most is treating this as a binary when it's a spectrum. You can give a model a fixed five-step workflow with one bounded retry loop and call it 'agentic' in the deck — and that's fine, as long as everyone understands you've constrained the agency to a place where it's safe. The skill is knowing how much of the loop to hand over.

The interesting question is almost never 'how do we build an agent?' It's 'how much agency does this task actually need?'

The Four Axes That Actually Decide It

Forget the hype cycle. In our delivery work, the workflow-versus-agent call comes down to four concrete properties of the task. Score the task on each before you write a line of code.

If the task is low-variance, high-error-cost, demands tight observability, and has a strict latency budget, you want a workflow — full stop. If it's genuinely high-variance with an unbounded path, tolerant of errors or cheaply reversible, and latency-relaxed, agency starts to earn its keep. Most enterprise tasks sit firmly in the first camp, which is why most of what we ship is constrained.

• →Task variance: Can you enumerate the realistic paths through this task? If the answer is 'three branches and an error case', that's a workflow. If it's 'we genuinely don't know what the user will need', that's a candidate for agency.
• →Cost of an error: A wrong customer email is recoverable. A wrong ledger entry, a deleted record, or a mispriced quote is not. The higher the blast radius, the more deterministic control you want around the model.
• →Observability needs: Can you afford to explain exactly why the system did what it did? Regulated workflows need a fixed, auditable path. Agent loops produce traces that are far harder to reason about after the fact.
• →Latency budget: Every agent loop iteration is a round-trip. A workflow with three calls has a predictable ceiling; an open loop can run 12 iterations on a bad day and blow a sub-second SLA.

Agency Multiplies Your Failure Surface

Here's the part the demos hide. When you give a model control of its own loop, you don't just add capability — you multiply the number of places things can go wrong. Each iteration is a fresh opportunity to hallucinate a tool name, pass a malformed argument, misread a result, or decide it's finished when it isn't.

This compounds with a problem we've written about before: LLM confidence scores are badly calibrated, so an agent that decides 'I'm done' is making that call on a signal you can't trust. A workflow sidesteps this entirely — you decide when it's done, in code, against conditions you can test.

It also makes evaluation dramatically harder. Evaluating a fixed workflow means testing each step against known inputs and outputs. Evaluating an open agent means evaluating trajectories — sequences of decisions — which is a far larger and messier space. This is exactly why we argue the eval harness is the real deliverable: the more agency you grant, the more eval infrastructure you need just to ship with a straight face.

When We Deliberately Removed Agency to Hit Reliability

A recent engagement is the cleanest example. The brief was an 'agent' to handle inbound supplier documents — invoices, delivery notes, contract amendments — extract structured data, validate it against internal systems, and route it for approval. The first prototype, built before we got involved, was a genuine agent: it had tools for OCR, lookup, validation, and routing, and it chose the order itself.

It worked beautifully in the demo and failed about one in seven times in testing. Not because any single tool was bad, but because the loop made different decisions on near-identical inputs — sometimes validating before extracting, sometimes skipping a lookup it deemed unnecessary, occasionally declaring success on a half-processed document. For finance documents, a one-in-seven inconsistency rate is a non-starter.

We tore the loop out. The task had maybe four real path variations, all enumerable. We rebuilt it as a fixed workflow: classify the document type, extract against a type-specific schema, validate against the source system, then route — with one bounded human-review branch for low-confidence extractions. The model still did all the hard cognitive work; it just no longer decided the order. Consistency went from roughly 85% to the high 90s, and — just as important — every decision became traceable. When something failed, we knew exactly which step and why. That's a pattern we see constantly: the path to reliability runs through *less* autonomy, not more.

If you want the broader version of why these projects stall, the organisational version of this story is in why most enterprise AI pilots die in month four — and it's rarely the model's fault.

So When Is Real Agency the Right Call?

This isn't an argument against agents. It's an argument for spending agency where it pays. Genuine open-ended tasks exist: a research assistant exploring a codebase to answer an arbitrary question, a triage system fielding requests you genuinely can't enumerate in advance, an investigation tool that follows leads wherever the data goes. In those cases, the path *is* the value, and forcing it into a fixed workflow would cripple the thing.

The honest test we apply: if you can sit down and draw the realistic paths through the task on a whiteboard in under an hour, build a workflow. If you genuinely can't — if the branching is unbounded and the next step depends on information you only learn at runtime — then you have a real candidate for agency, and you should budget accordingly for the eval harness, the guardrails, and the insider-threat-style controls that come with handing a model real autonomy.

A useful middle path is to start constrained and earn agency incrementally. Ship the workflow, instrument it, and only widen the model's control over the loop where the data shows the fixed path is genuinely limiting outcomes. Agency added on evidence is very different from agency assumed in a roadmap.

The Thesis, and the Part That's Still Hard

Default to the most constrained design that solves the task. Workflows are easier to test, easier to observe, cheaper to run, and far more predictable under load. Reserve agency for tasks where the path itself is unknowable — and pay the eval-and-guardrail tax with eyes open when you do.

The part that remains genuinely hard: the boundary isn't always obvious up front. Sometimes you build the workflow and discover the real-world input variance is higher than anyone admitted, and you need to widen the loop. Sometimes you build the agent and discover, as we did with the supplier documents, that the variance was an illusion. There's no formula that gets this right on paper — it takes a prototype and a brutally honest eval set to know. Anyone who tells you they can decide it from the brief alone is selling something.

The cheapest way to get this wrong is to start with the answer ('we're building an agent') and reverse-engineer the task to fit. Start with the task, score it on the four axes, and let the architecture fall out of that. More often than not, it falls out as a workflow.