When should I use an AI agent instead of a script?

When the input shapes cannot be enumerated. Complexity is the wrong test — a complex calculation with fixed fields is a script, while a simple task over documents that every supplier formats differently is not. If you can write down the cases and the list terminates, that list is your program.

What is the main risk of using an agent for automation?

That its failures do not announce themselves. A script throws and names the line; an agent returns confident, well-formed output that is wrong and looks like a correct result downstream. This is the main argument for keeping an agent's remit narrow and constraining its output to something you can validate.

Can I combine an agent and a script?

That is usually the right design. Let the agent make the one genuinely variable judgement — classify, extract, route — and hand every deterministic step to ordinary code. Business rules stay auditable and testable, cost and latency stay low, and the agent's output is constrained enough to validate before anything acts on it.

Forge · 9 September 2026

When to use an AI agent, and when a script is the right answer

Agents are chosen for task complexity when the deciding factor is input variance. Where each one belongs, why an agent's failures are harder to catch than a script's, and the hybrid that usually wins.

4 min read

The usual way this decision gets framed is by difficulty: simple work gets a script, complicated work gets an agent. That framing produces expensive, slow, non-deterministic implementations of things a loop would have done, and it is the wrong axis. The question is not how complex the task is. It is how much the input varies.

Variance, not complexity

A payroll calculation is complex and has almost no input variance: the fields arrive in known positions with known types. Reading an invoice is conceptually simple and has enormous variance — every supplier lays it out differently. The first is a script no matter how intricate the rules. The second is not a script at any length, because you cannot enumerate the layouts.

script when inputs are enumerable · agent when they are not

If you can write down the cases and the list terminates, that list is your program. An agent earns its cost precisely where the list does not terminate.

The failure modes are not comparable

This asymmetry, rather than cost or latency, is the real argument for keeping the agent's remit narrow. Every task you hand it is a task whose failures stop announcing themselves.

	Script	Agent
Handles unseen input shapes	No — throws	Yes, that is the point
Same input, same output	Always	Not guaranteed
Cost per run	Effectively zero	Meaningful, and scales with volume
Latency	Milliseconds	Seconds
When it fails	Loudly, at a known line	Silently, in well-formed output
Debugging	Read the trace	Reproduce a non-deterministic path
Auditability	The code is the explanation	Requires logging intermediate reasoning

What you are actually trading

The hybrid that usually wins

Most workflows that look like agent problems are one judgement surrounded by deterministic work. The productive shape is to let the agent make that judgement and nothing else — classify, extract, route — and hand execution to ordinary code.

An inbound support queue

Messages arrive in free text, in several languages, with no structure. Deciding what each one is about genuinely needs a model.

Agent: read the message, return one of eight categories, an urgency and any order ID it can find.
Script: everything after that — look up the order, apply the refund rules, write the ticket, send the reply, escalate on a threshold.

The refund rules never touch the model. They are auditable, testable, unchanged between runs, and cost nothing to execute. The model is confined to the one step that actually needed judgement, and its output is constrained enough to validate before anything acts on it.

This also makes the failure mode tractable again: a category is checkable against a fixed list, an order ID either exists or does not. You have converted a plausible-looking wrong answer into a validation error, which is the whole game.

Illustrative shape, not measured — the proportions depend entirely on the process. The pattern worth taking is that splitting a workflow usually shrinks the part needing an agent rather than eliminating it.

Questions that settle it quickly

01Can you enumerate the input shapes, and does the list end? If yes, write the list. That is the program.
02Would a wrong answer be noticed? If it would flow downstream unchallenged, either constrain the output so it can be validated, or do not use an agent.
03Does it need to be identical every run? Regulatory, financial and billing paths usually do, and that rules out a non-deterministic step by itself.
04What does it cost at real volume? Per-run cost that is irrelevant at a hundred runs a day is a budget line at a hundred thousand.
05Can the variable part be isolated? Usually yes — and once it is, the rest is a script.

The strongest reason to keep this boundary deliberate is that it does not hold still. A step that needed judgement last year may be enumerable now that you have seen ten thousand examples of it, and that is a promotion from agent to script — cheaper, faster, testable, and loud when it breaks.

Common questions

When should I use an AI agent instead of a script?: When the input shapes cannot be enumerated. Complexity is the wrong test — a complex calculation with fixed fields is a script, while a simple task over documents that every supplier formats differently is not. If you can write down the cases and the list terminates, that list is your program.
What is the main risk of using an agent for automation?: That its failures do not announce themselves. A script throws and names the line; an agent returns confident, well-formed output that is wrong and looks like a correct result downstream. This is the main argument for keeping an agent's remit narrow and constraining its output to something you can validate.
Can I combine an agent and a script?: That is usually the right design. Let the agent make the one genuinely variable judgement — classify, extract, route — and hand every deterministic step to ordinary code. Business rules stay auditable and testable, cost and latency stay low, and the agent's output is constrained enough to validate before anything acts on it.

What AI changes about software testing, and what it does not

AI generates tests quickly, but generated tests assert current behaviour, which encodes existing bugs as expected. Where AI genuinely reduces QA effort, where the oracle problem stops it, and how to tell the two apart.

4 min read

WhatsApp automation in India: what you are actually allowed to send

Opt-in, the 24-hour window and template approval decide what you can send on WhatsApp, not your CRM. What each rule means, why TRAI's DLT registration does not apply, and how a contact list shrinks to a reachable audience.

5 min read

All insights.

Browse insights Talk to us

Or write to us at [email protected]