Do you need an AI agent? Mostly no.

If you are asking whether you need an AI agent, the honest answer is: probably not. Most product features that founders want to make "agentic" are better built as a deterministic workflow, a plain form, or a small ranking model — cheaper to run, testable in CI, explainable to a customer, and free of the non-determinism that turns a Tuesday outage into a forensic investigation. Reach for an agent only at the narrow edge where open-endedness is the actual requirement.

We wrote a similar argument once about machine learning: most problems people frame as ML are really a SQL query and a threshold. The same disease has a new name now. The cure is the same: define the problem precisely, then pick the dumbest tool that solves it.

AI agent vs automation: what an agent actually is

An AI agent is three things bolted together: a large language model, a set of tools it can call (search, a database, an API, a code runner), and a loop — the model decides what to do, does it, reads the result, and decides again, until it thinks it is done. That loop is the whole point. It is also the whole problem.

Deterministic automation, by contrast, is a fixed sequence of steps you wrote. A webhook fires, a record is created, an email goes out, a row is updated. Same input, same output, every time, forever. You can read it, test it, and reason about every branch.

The difference that matters is not intelligence. It is control. Automation does exactly what you specified. An agent does whatever it decides, which means each run can differ, and the failure modes are open-ended: it can loop, hallucinate a tool argument, call the wrong API, or confidently produce a wrong answer that looks right. You are trading determinism for flexibility. Most features do not need that trade.

The short version

• Form or workflow when the inputs and the steps are known. This is most of what you are building.
• Small model / ranker when you need to score, sort, classify, or recommend over structured signals.
• Agent only when the input is genuinely unstructured, the path is genuinely open-ended, and a wrong answer is cheap to recover from.

Why "agentic" usually loses to a scripted workflow

Here is the uncomfortable pattern we see. A founder describes a feature — "the user asks for a refund and the system handles it" — and someone reaches for an agent because the request arrives as a sentence. But the underlying logic is a decision table: was it within 14 days, was the item shipped, is the amount under the manager-approval threshold. That is four branches. An if statement does it. It is correct 100% of the time, it costs nothing per call, and when a customer disputes the outcome you can point at the exact rule that fired.

Wrap that same logic in an agent and you inherit four new bills:

• Latency and cost. Every step is a model call. A three-step loop is three round-trips, hundreds of milliseconds to seconds each, paid per token, every single time — versus a database read that returns in single-digit milliseconds for free.
• Non-determinism. The same input can produce different outputs across runs. That is a nightmare for support, for refunds, for anything a regulator or an angry customer might examine.
• Testing collapse. You cannot write an assertion against "the model usually does the right thing." You end up with eval suites and statistical pass rates instead of green CI, and a 96% pass rate means 1 in 25 customers gets the wrong answer.
• Inexplicability. When it goes wrong, the answer to "why" is a transcript of the model's reasoning, which is a story it told itself, not a cause you can fix with a one-line patch.

None of that is the model's fault. It is the loop. You took a problem with a known shape and handed it to a system whose defining feature is that it makes up the shape each time.

Where agents genuinely earn their place

We are not anti-agent. There is real, valuable work that only an LLM-in-a-loop can do well, and pretending otherwise is just the opposite mistake. An agent earns its keep when three conditions all hold:

• The input is genuinely unstructured. A pile of PDFs in inconsistent formats, a free-text support inbox, a messy email thread where the actual request is buried in three paragraphs of pleasantries. When you cannot write the parser, a model that reads is worth it.
• The path is genuinely open-ended. Open-ended research where you don't know in advance which sources matter, or a debugging assistant that has to look at code, run it, read the error, and try again. The branching is real, not imagined.
• A wrong answer is cheap. Low-stakes drafting — a first-pass email, a summary, a code suggestion a human reviews before it ships. The human in the loop is the safety net, and the agent saves them the blank-page problem.

Notice the pattern: agents shine where you would otherwise need a human to read, judge, and improvise — and where a mistake costs a redo, not a refund or a lawsuit. Research synthesis, triage of unstructured intake, drafting under review. That is a real and growing category. It is just much smaller than the "let's make it agentic" hype suggests.

A decision checklist

Before you build anything agentic, walk this list top to bottom. Stop at the first yes.

1. Can a form or a fixed workflow do it? Are the inputs and steps known in advance? Build the workflow. Done.
2. Is it scoring, sorting, classifying, or recommending over structured signals? Build a small model or a rules-based ranker. Explainable, fast, testable.
3. Is the input unstructured AND the path open-ended AND a wrong answer cheap to recover from? Now an agent is justified. Keep its tools few, its loop bounded, and a human on the result if the stakes are real.
4. Still tempted to make step 1 or 2 "agentic" anyway? Write down what the agent buys you that the cheaper option doesn't. If the honest answer is "it feels more modern," you have your answer.

What Amplified Creations actually does

At Amplified Creations our default is deterministic automation and small, explainable models — and we only add an LLM at the edge where open-endedness is the genuine requirement. Our stack is boring on purpose: PHP 8.3 on shared hosting, server-rendered pages, a SQLite-backed Cockpit CMS, no build step. When a client needs "smart" behaviour, we ask which of the three buckets it falls into before writing a line of code.

Concretely: the recommender inside the Jofit wellness app is a small, explainable ranker, not an LLM in a loop. It scores and orders options over structured signals, so we can test it, reason about why it surfaced a given suggestion, and ship it without per-request token costs or non-deterministic output. For client websites, the "automation" is overwhelmingly plain server-side logic and scheduled jobs: form submissions routed through Resend, content pulled from the CMS, JSON-LD generated from the same data — deterministic, cacheable, and fast enough to keep Lighthouse around 95. We use LLMs where they belong — drafting and translating long-form content under human review, the kind of unstructured, low-stakes, human-checked work agents are good at. We do not put a model in the critical path of a checkout, a refund, or anything a customer could be harmed by getting wrong. That is not caution for its own sake; it is the same engineering instinct that says you don't roll your own crypto. Use the powerful, unpredictable tool only where its power is the point.

The result is software our clients can trust and we can debug at 2am. An agent in production is a thing you supervise. A deterministic workflow is a thing you forget about because it just works. Most of the time, "it just works" is the feature.

FAQ

What is the difference between an AI agent and automation?

Automation runs a fixed sequence of steps you wrote, so the same input always produces the same output. An AI agent is an LLM that decides its own steps in a loop using tools, so its behaviour can vary run to run. Automation trades flexibility for control; an agent trades control for flexibility.

Are AI agents worth it for my product?

Usually not, for the core flows. Agents are worth it only when the input is genuinely unstructured, the path is open-ended, and a wrong answer is cheap to recover from — like research, triage of messy intake, or low-stakes drafting a human reviews. For known inputs and known steps, a workflow or form is cheaper, faster, and testable.

When should I use a small model instead of an LLM agent?

Use a small model whenever you are scoring, sorting, classifying, or recommending over structured signals. A focused ranker or classifier is explainable, runs in milliseconds, costs nothing per call, and can be tested in CI — none of which is true of an LLM-in-a-loop. Save the LLM for unstructured language the small model can't read.

Why is non-determinism a problem in production?

Because the same input can yield different outputs, which breaks testing, support, and accountability. You can't write a clean assertion against "usually correct," and when a customer disputes an outcome you can only show them a model transcript, not a rule you can point to and fix. For refunds, billing, or anything regulated, that is unacceptable.

Is Amplified Creations against using LLMs?

No. We use LLMs where open-endedness is the actual requirement — drafting and translating content under human review. Our objection is to putting a non-deterministic model in the critical path of features that a deterministic workflow or a small ranker would handle more cheaply, more reliably, and more explainably.