Do You Need an AI Agent or Just a Script?

Do you need an AI agent or just a script?

Most of the time, a script. If the steps are known in advance and the inputs are predictable, code is cheaper, faster and easier to debug than a model deciding what to do next. An agent earns its keep when the path cannot be written down before the job starts.

This is the most common question we get about automation now, and the framing is usually wrong. People compare "AI" against "manual", when the real comparison is a model making decisions against code following a plan.

Anthropic's own engineering guidance draws the line cleanly, and it is worth using as your default. Here is how we apply it in client work.

What is the actual difference between a workflow and an agent?

Anthropic's Building Effective Agents post, published on 19 December 2024, defines workflows as systems where language models and tools are orchestrated through predefined code paths. Agents are systems where models dynamically direct their own processes and tool usage, keeping control over how they accomplish tasks.

That distinction decides everything downstream. A workflow fails in ways you can trace, because you wrote the path. An agent fails in ways you have to reconstruct, because it chose the path at runtime.

The same post names five workflow patterns worth knowing: prompt chaining, routing, parallelization, orchestrator-workers, and evaluator-optimizer. Four of those five are just software with a model inside one step. Only orchestrator-workers starts to look like what people mean by an agent.

When is a plain script the right answer?

When the job has a stable shape. Pull new form submissions, enrich them from an API, score them against fixed rules, write them to the CRM, notify a channel. Nothing in that sentence needs a model to decide anything, so nothing in it should pay a model to decide anything.

Scripts win on four things that matter in production: cost per run, latency, testability, and the ability to explain what happened last Tuesday. A cron job with logs is boring in exactly the way operations should be boring.

Anthropic's guidance says the same thing more politely: find the simplest solution possible, and only increase complexity when needed. Many applications do fine with single model calls plus retrieval and good examples.

When does an agent earn its cost?

When the input is messy and the number of possible paths is large. Sorting an inbox of support emails where each one might need a lookup, a refund, an escalation or nothing is a reasonable agent job. So is research, where the next query depends on what the last one returned.

Anthropic frames the threshold as flexibility and model-driven decision-making being needed at scale. We would add a practical test: if you can write the decision tree on one page, build the tree.

The other honest reason to use an agent is that the rules change weekly. Code that has to be rewritten every Friday is more expensive than a model reading an updated policy document, even at a worse cost per run.

What does an AI agent actually cost to run?

Less than most teams fear, and more than they budget. Published Claude API prices put Claude Haiku 4.5 at 1 dollar per million input tokens and 5 dollars per million output tokens. Claude Sonnet 5 is 2 dollars and 10 dollars. Claude Opus 5 is 5 dollars and 25 dollars.

Anthropic's own worked example is useful for sizing: processing 10,000 support tickets at roughly 3,700 tokens per conversation with Claude Haiku 4.5 comes to about 37 dollars. That is the arithmetic to run before anyone says AI is too expensive or too cheap to bother measuring.

Two documented discounts change the maths. The Batch API takes 50 percent off input and output tokens for work that does not need to be immediate. Prompt caching charges cache reads at 0.1 times the base input price, so a large fixed instruction block gets cheap after the first call.

Compare that to platform pricing, which charges by run rather than by token. n8n publishes a Starter plan at 20 euros a month for 2,500 workflow executions, Pro at 50 euros for 10,000, and Business at 667 euros for 40,000, where an execution is a single run of the entire workflow regardless of how many steps it has. Its Community Edition is on GitHub for self-hosting.

How do compounding errors show up in practice?

Quietly, three steps in, and usually in the records rather than the logs. Anthropic's post is blunt that the autonomous nature of agents means higher costs and the potential for compounding errors, and that agentic systems often trade latency and cost for better task performance. Both halves of that sentence bite in production.

In real systems that means a mis-read field becomes a wrong lookup, which becomes a confident summary, which becomes a CRM record nobody questions. The model was not wrong at any single step by much. The chain was wrong by a lot.

The fix is not a better prompt. It is checkpoints: validate the output shape at each hop, stop on low confidence, and keep a person in the loop where a mistake is expensive. Our notes on where to put a human in an AI workflow go through the specific places we insist on review.

Where does MCP fit into this decision?

MCP is plumbing, not a reason to build an agent. The Model Context Protocol is an open standard for connecting AI applications to external systems, described in its own documentation as a USB-C port for AI applications: one way to expose tools, data and prompts to any client that speaks it.

It matters because it removes the worst part of tool integration. Write one server for your CMS or your database, and Claude, ChatGPT and your editor can all use it. That reduces the cost of giving a model real capabilities.

It does not change the workflow question. A script can call the same API directly with fewer moving parts. We covered the practical side in our piece on MCP servers for web teams.

What do we build for clients most often?

A workflow with one model call in the middle. The pattern that keeps proving itself is deterministic code for the fetching, routing and writing, with a model doing the one thing code is bad at: reading unstructured text and turning it into a clean field.

That shape is cheap, observable and easy to hand over. When something breaks, the logs show which step failed, and the fix is usually code rather than prompt archaeology.

We reach for something more agentic in a narrow set of cases: research tasks, first-pass QA sweeps across many pages, and triage where the next action genuinely depends on what was just found. Even then we cap the number of steps and the spend per run.

How do you test whether the agent is better?

Run both against the same 50 real examples and count. Build the script version first, because it takes an afternoon and gives you a baseline. Then measure the agent on the same inputs for accuracy, cost per run, time per run, and how many outputs a human had to correct.

Write down the pass bar before you look at the results. Teams that skip this step end up defending the interesting system instead of the effective one, and nobody wants to admit the cron job won.

Keep the evaluation set and rerun it whenever you change the model or the prompt. Our guide to evaluating AI automation before production covers how we structure those checks.

What should you build first?

Pick the most repetitive task on your team, write the boring version, and put one model call where the judgement is. Ship it with logs, an error alert and a spend cap. Then see whether anything about the result actually needs autonomy.

The industry will keep selling agents, and some of them are genuinely good. Your job is to know which of your problems has a shape, because problems with a shape do not need a decision-maker.

If you want a second opinion on whether a workflow or an agent fits the job in front of you, we are happy to walk through it. You can see how we build these systems at phoenix.studio.