LLM Agents vs Traditional Automation: What Actually Ships

I've lost count of the number of discovery calls that start with "we want to build an AI agent." I ask what the agent should do. Nine times out of ten, the answer describes a workflow with five known steps, two decision points and a hard requirement that it never gets the numbers wrong.

That is not an agent. That's a cron job with good error handling. And that's fine — saying so has saved clients six-figure budgets.

But the opposite happens too. Teams spend eight months hand-coding parsers for supplier invoices in 40 different formats, when an LLM would have handled it in a fortnight. So the question isn't "are LLM agents real?" They are. The question is where they actually belong in a production system, and where they quietly destroy your margins and your reliability numbers.

This post is my honest take, based on what we've shipped and what we've had to rip out.

First, let's define the terms properly

The word "agent" has been stretched until it means nothing. Here's how I use it internally.

Traditional automation

Deterministic code. Rules, state machines, ETL pipelines, RPA scripts, event-driven queues. You know the inputs, you know the branches, and the same input always produces the same output. If it breaks, you can trace exactly why. Most of the world's business value still runs on this and will for a long time.

LLM-in-the-loop (single call)

A deterministic pipeline that calls a model at one specific step: classify this ticket, extract these fields, summarise this call transcript, draft this reply. The control flow is still yours. The model is a function.

LLM agents

The model decides what to do next. It picks tools, plans multi-step work, reads its own results, loops, and stops when it thinks it's done. Control flow is delegated to a probabilistic system. That's the real distinction — not the model, not the framework. Who owns the control flow.

Most successful production systems we've built are the middle category. People talk about the third.

Where traditional automation still wins

I want to be blunt about this because it's where a lot of AI automation for business budgets get burned.

Use deterministic code when:

• The steps are known. If you can draw the flowchart, code the flowchart. An LLM re-deriving your flowchart on every run, at 3 seconds and $0.02 a pop, is not innovation.
• Correctness is binary. Financial postings, payroll, inventory decrements, invoice totals, safety interlocks in an embedded system. "95% accurate" is a failure, not a metric.
• You need to reproduce a result. Auditors, regulators, and angry customers all want to know why the system did what it did last Tuesday.
• Volume is high and margins are thin. At 5 million events a day, token costs stop being a rounding error.
• Latency budgets are tight. Sub-100ms? You're not calling a frontier model in that path.

We once replaced a client's "AI classification layer" with 60 lines of regex and a lookup table. Accuracy went from 91% to 100% and the monthly bill went from four figures to nothing. Nobody put that in a press release, but it was the right engineering call.

Where LLM agents genuinely earn their keep

Now the other side. LLMs are extraordinary at one thing traditional automation has always been terrible at: handling unbounded, messy, human input without a schema.

Good fits, in my experience:

• Long-tail input variation. Documents, emails, PDFs, scanned forms, chat logs, supplier catalogues. Anywhere the "format" is really 400 formats.
• Language-shaped work. Summarising, drafting, translating, tone-matching, turning a rambling customer message into a structured ticket.
• Genuinely open-ended investigation. "Find out why this shipment is late" might need the ERP, then the carrier API, then an email thread. The path isn't knowable in advance. That's a real agent use case.
• Semantic search over messy corpora. Retrieval over internal docs, specs, past tickets. Still the highest ROI-per-engineering-hour AI feature I know of.
• Code and config generation as a developer accelerant — with a human reviewing every line.

Notice how many of those are narrow. The agents that ship are boringly scoped. "Autonomous agent that runs our operations" doesn't ship. "Agent that resolves address discrepancies across three systems and escalates anything it can't reconcile" ships, and pays for itself.

The five things that kill agents in production

This is the part demos never show you.

1. Compounding error. A step that's 95% reliable is 77% reliable after five steps. Agents that plan long chains fail silently in the middle. The fix is fewer steps and hard validation between them — which starts to look a lot like traditional automation with LLM steps inside it.
2. Cost non-determinism. A deterministic job costs the same every run. An agent might loop three times or eleven. Your unit economics become a probability distribution. Cap iterations, cap tokens, alert on outliers.
3. No real observability by default. "The agent decided to call the wrong tool" is not a stack trace. You need trace logging of every prompt, tool call, and intermediate output from day one. Retrofitting this is misery.
4. Prompt drift and model upgrades. Your carefully tuned behaviour changes when the provider ships a new model version. Without an eval suite you won't know until a customer tells you. Build the eval set before you build the agent.
5. Security surface. Prompt injection is real. If your agent reads untrusted content and also has write access to your database or can send email, you've built a confused deputy. Tools get least privilege, writes get human approval or hard constraints.

The architecture that actually works

Almost every successful system we've delivered looks like this, whatever the client called it at kickoff:

1. Deterministic skeleton. A workflow engine, queue, or state machine owns the control flow. It's observable, retryable and testable.
2. LLM calls as bounded steps. Each one does a single job with a defined output schema. Structured output, validated. If validation fails, retry once, then escalate.
3. Tools as ordinary services. Typed, permissioned, rate-limited APIs — the same ones your other systems use. Not "whatever the agent can reach."
4. Agentic loops only in the fuzzy pockets. Where the path truly is unknown, let the model plan — inside a sandbox with a step limit and a budget.
5. A human in the loop where the stakes justify it. Confidence thresholds route the uncertain 8% to a person. That 8% is also your training data for the next iteration.
6. Evals in CI. A few hundred labelled cases. Run them on every prompt change and every model upgrade. This is the single highest-leverage practice in LLM engineering and the one most teams skip.

That's not a compromise architecture. That is the state of the art for AI automation for business right now, and the teams pretending otherwise are usually still pre-production.

How to decide, quickly

If I had one question to triage a project, it's this: can you write down the acceptance test?

If the acceptance test is "the output equals X" — build deterministic automation and use an LLM only where the input is unstructured. If the acceptance test is "a competent human would consider this a reasonable response" — you're in LLM territory, and you need evals, human review and a cost ceiling.

And if the honest answer is "we're not sure yet," spend three weeks and a small budget finding out on real data before anyone commits to a platform, a framework, or a roadmap. Real data breaks assumptions faster than any architecture diagram.

What we'd do on your project

We've been building software since 2012 — Python, AI/ML, embedded and IoT — for clients in the US, UK, Europe and the Middle East. That mix matters here: a lot of our AI work sits on top of systems where being wrong has physical consequences, so we're instinctively conservative about handing control flow to a model.

Practically, we usually start with a short paid discovery: map the workflow, identify which steps are genuinely fuzzy, build an eval set from your real data, and prototype the narrowest useful version. Sometimes that ends with a sophisticated agent. Sometimes it ends with me telling you a well-built pipeline and one LLM call will do the job for a fifth of the cost. Both are good outcomes.

If you're weighing up LLM agents against traditional automation for something real — and you'd rather have an engineering opinion than a sales pitch — get in touch at foogletech.com/contact-us. Send us the workflow you're trying to fix and we'll tell you honestly what we'd build, what we wouldn't, and roughly what it costs.