By Gavin Smith | DATAFORT FDE | 28 October 2026
There’s a moment in almost every client workshop. Somebody senior leans back, nods slowly, and says: “So we’ll need an agent for this.”
Not a question. A diagnosis. Usually delivered about four minutes after they’ve watched a demo where a model booked a restaurant, refactored a codebase and wrote a sonnet about the experience.
And look, sometimes they’re right. More often the thing they’ve described is a process with eleven steps, nine of which haven’t changed since 2014, and one of which involves reading a PDF that a supplier insists on sending as a scanned fax. That isn’t an agent problem. That’s a workflow with one awkward bit.
We spend a surprising amount of time at DATAFORT talking clients down from agents. Agents aren’t bad. They’re just expensive, slow, hard to test, harder to audit and, given the right email in the inbox, capable of doing something spectacularly stupid with total confidence. Choosing between deterministic, orchestrated and agentic AI is an architecture decision, and like every architecture decision worth arguing about, it comes with a blast radius.
Who owns the control flow?
Strip away the vendor slides and the distinction is simple. It comes down to who decides what happens next.
Deterministic. Code owns the control flow. Code owns every decision. Same input, same output, every time. Rules engines, ETL, the stored procedure nobody dares touch. There may be ML in there (a fraud score, a classifier) but the model returns a number and code decides what to do with it. Boring. Testable. Cheap. Wonderful.
Orchestrated. Code still owns the control flow, but some nodes in the graph are LLM calls. Extract the invoice fields. Classify the email. Summarise the call. The model gets a narrow task, a schema to fill (structured outputs, JSON Schema, Pydantic, pick your poison) and absolutely no say in what runs next. If it returns rubbish, validation catches it and the workflow retries, falls back or routes to a human. The LLM is a very clever function call. Nothing more.
Agentic. The model owns the control flow. You hand it a goal, some tools and a loop, and it decides which tool to call, with which arguments, how many times, and when it’s done. The execution path is generated at runtime. It isn’t in your code. It isn’t in your architecture diagram. It’s in a context window, being made up as it goes along.
That last paragraph is more or less the whole article. Everything else is consequences.
“It needs judgement” is two different claims
When a client says a process needs AI, what they usually mean is that it needs judgement. Fair enough. But judgement comes in two flavours, and mixing them up is how people end up with an agent where a function call would have done.
Input variability. The inputs are messy. Free-text emails. Contracts in seventeen layouts. Complaints typed entirely in capitals. You need a model to understand the input: classify it, extract from it, normalise it. But once it’s understood, what happens next is known. Billing complaint goes to billing. Invoice over £10k goes to approval. This is orchestrated territory. One LLM node, tightly scoped, schema-validated, and the rest is plain code.
Path variability. The sequence of steps can’t be known in advance. Working out why a reconciliation broke. Triage across six systems where the next query depends on what the last one returned. Research. Debugging. Anything where a competent human would say “well, it depends what I find.” This is where an agent earns its keep, because writing the decision tree by hand would mean enumerating every possible world.
Our test is blunt. Could a reasonably competent analyst draw the flowchart on a whiteboard in an afternoon? If yes, draw the flowchart. Put the LLM in the boxes that need reading comprehension. Do not hand it the pen.
In our experience, most “we need an agent” requests turn out to be input variability wearing a trench coat.
Security is a constraint, not the deciding vote
We used to frame this as “agents are less secure.” True-ish. But it starts the wrong conversation, because clients hear “agentic = dangerous” and either panic or, worse, decide the risk is worth it and stop thinking altogether.
The better question: what authority does this thing have, and what happens when it’s wrong? An agent’s risk is roughly the product of three things.
• Authority. Which tools it can call. Read-only search over a document store is one thing. An UPDATE on the ledger is another. An MCP server with write access to your CRM is a third, more exciting thing.
• Exposure. What untrusted content lands in its context. Every email, web page, PDF and support ticket is a potential prompt injection. Indirect injection stopped being an academic curiosity a while ago. If the agent reads attacker-controlled text and holds write tools, congratulations: you’ve built a confused deputy with a natural-language API.
• Reversibility. Can you undo it? A draft, yes. A sent email, no. A payment, very much no.
Push any one of those towards zero and the risk collapses. Read-only agent over untrusted content? Fine. Worst case, a wrong answer. Write-capable agent over trusted internal data, with a human approving each action? Probably fine. Write-capable, untrusted input, irreversible actions, nobody watching? That isn’t an architecture. That’s a future incident report with your name on it.
It cuts both ways, by the way. A deterministic pipeline running under a service account that can drop production tables is not secure just because there’s no LLM in it. And a well-sandboxed agent can be perfectly safe. Security tells you how to contain the thing. It rarely tells you which thing to build.
The bits that bite in production
Security gets the headlines. These are the ones that get you at 2am.
Auditability. Ask a deterministic system “why did it do that?” and you get a line number. An orchestrated system gives you a mostly deterministic trace, plus a handful of model outputs you can log and replay. An agentic system gives you “it seemed like a good idea at the time”, spread across forty tool calls and a 90k-token context. If your client answers to a regulator (FCA, PRA, anyone with a clipboard), that matters. A lot.
Cost and latency at volume. An orchestrated extraction is one call. Predictable tokens, predictable latency, predictable bill. An agent loop is N calls, where the model picks N and each step re-reads a growing context. Fine at fifty runs a day. Less fine at fifty thousand. P99 latency on an agent loop is a fun number to show a CFO. Once.
Testability. You can unit-test code. You can build an eval set for a narrow LLM node: 200 labelled invoices, field-level accuracy, job done. Evaluating an agent means evaluating trajectories. Did it get the right answer, by a sensible route, without touching anything it shouldn’t have? Doable. But it’s a different discipline, and most teams haven’t built it yet.
Model updates. Bump the model version and an orchestrated node might move a couple of points on your eval. An agent might take an entirely different route through your tools. Same prompt. Same tools. Different behaviour. Lovely.
Rate of change. This one cuts the other way. If the process changes every month, hand-coded rules turn into a maintenance swamp, and a model that reads the policy document and adapts starts looking very attractive. Determinism isn’t free. You just pay for it in developer hours instead of tokens.
Build the spine first
The pattern we keep coming back to is a deterministic spine with judgement inserted only where it’s needed. Autonomy gets granted per step, not per system.
In practice that’s a plain workflow. A state machine, a queue, Temporal, Step Functions, or a Python script with ideas above its station. Most nodes are code. A few are scoped LLM calls with schemas and validators. Occasionally, one node is a bounded agent. Bounded meaning: limited tools, read-only wherever possible, a step budget, a token budget, a timeout. Its output lands back in the spine as structured data, and code validates it before anything actually happens.
The agent doesn’t run the business process. It runs one investigation inside it, then hands back a report.
For every step, we ask three questions:
1. Does it need judgement? On the inputs, on the path, or neither?
2. What happens if it’s wrong? Cheap and reversible, or expensive and permanent?
3. What authority does it need? Read, write, or write to something that matters?
The answers mostly make the decision for you. No judgement needed: code. Judgement on the inputs only: an LLM node with a schema. Judgement on the path: a bounded agent. Expensive and permanent: a human in the loop, whatever else you picked. Write access to something that matters plus untrusted input: go back to question one and try harder.
It isn’t glamorous. Nobody’s going viral with a demo of a state machine. But it ships, it passes audit, and when it breaks you can find out why before lunch.
So, do you need an agent?
Maybe. Sometimes the path really can’t be drawn, and an agent is exactly the right tool. We build them. We like them. The good ones are remarkable.
But start from the other end. Assume code. Earn every LLM call. Earn every tool. Earn every loop. Autonomy should be something a step has to justify, not something the architecture gets by default because the demo looked cool.
The best AI system is frequently the one with the least AI in it. Annoying, I know. Still true.
