AI agent vs automation: most of what you want is a scheduled job

Automation follows a fixed sequence you defined in advance. An AI agent decides the sequence itself, at runtime, based on what each step returns. The commercial distinction is that automation is auditable by reading it, and an agent is only auditable by watching it run. Most business processes people want an agent for are fixed sequences, and they should stay that way.

This is the piece where I argue against buying the thing I sell. That is deliberate. The fastest way to waste money in this category is to purchase autonomy for a problem that had no decisions left in it.

What is the actual difference?

Automation is a recipe. An agent is a cook.

A recipe cannot handle an ingredient it has never seen, and it also cannot burn your kitchen down in a novel way. Every path it can take was written down by someone, which means you can read it, test it, and know what it will do on Tuesday. When it breaks, it breaks at a specific step you can point at.

An agent chooses. It calls a tool, reads the result, and decides what to do next. That is genuinely more capable when the path cannot be known in advance. It is also strictly harder to verify, because the thing you are checking is not a fixed sequence but a distribution of possible sequences.

	Automation	AI agent
Path	Fixed, written in advance	Chosen at runtime
Audit	Read the definition	Replay the run
Failure	At a nameable step	Anywhere, and it compounds
Cost to change	Edit one step	Re-test the behaviour
Right when	You know the steps	The steps depend on the data

How do you tell which one you need?

Write the process down. That is the whole test.

If you can write the steps, in order, including what happens when each one fails, you have automation. Building an agent for it adds a decision layer to a problem with no remaining decisions, and that layer is where the unpredictability enters. You will have paid more for a system that is harder to check and does the same thing.

If you genuinely cannot write it down, because step three depends on what step two returned in a way you cannot enumerate, that is a real case for an agent. Document analysis over a varied corpus qualifies. So does anything where the input format is genuinely unbounded.

Most processes fail this test. Not because people are lazy about writing them down, but because “we want AI in it” arrived before anyone asked what the process actually was.

What does buying the wrong one cost?

More than the price difference, and the extra cost lands in the wrong column.

An agent built for a fixed process costs more to build, more to test, and considerably more to debug. When it does something unexpected you cannot read the definition to find out why, because the definition is “it decided.” You replay runs and infer. That is a permanent tax on every future change, paid monthly in engineering attention rather than once at purchase.

Why is improvisation a cost rather than a feature?

Because in a solved process, improvisation is just a new category of error nobody specified.

A fixed automation that meets an unfamiliar input stops. An agent adapts. Adaptability is genuinely the thing you paid for, and it is valuable exactly when the correct behaviour was not already known. Where the correct behaviour was known and written down, the same property produces variance you now have to monitor.

Roughly 2 in every 3 automation requests I am asked to scope turn out to be fixed sequences. That ratio is my own count rather than an industry figure, and it has held steady enough that I now open every scoping conversation by asking for the process in writing.

Where is the line in practice?

Three questions, and the answers should all point the same way.

Does the next step depend on the content of the last result, or only on whether it succeeded? Dependency on content is agent territory. Dependency on success or failure is a conditional branch, which is automation.

Is the input format bounded? If you can list the shapes the data arrives in, you can write branches for them. If you genuinely cannot, you need something that adapts.

Is a wrong step recoverable without a human? If not, then whatever you build needs a checkpoint, and once you have a mandatory human checkpoint you have given up most of the argument for autonomy anyway.

Three questions locate the line between a fixed process and an agent.

The hybrid that actually ships

In practice the systems that work are neither pure.

The overall flow is fixed and readable. One or two steps inside it are genuinely hard, and those steps get a model. Everything around them is ordinary conditional logic that anyone can audit. You get the capability where the difficulty actually is, and you keep the ability to read the system everywhere else.

That shape is boring and it is what I ship most often. The parts that need judgment get judgment. The parts that need a scheduled job get a scheduled job, and nobody pretends the scheduled job is intelligent.

Keep the flow deterministic. Fence the one step that needs judgment.

What to ask a vendor proposing an agent

Ask them to describe the process as a sequence. If they can, ask what the agent adds beyond running that sequence. If the answer is flexibility for cases they cannot name, the flexibility is speculative and you are paying for it now.

AWS makes a version of this argument in its own strategic guide on agents versus automation, which is worth reading precisely because it comes from a vendor with every incentive to sell the more expensive option and still lands on matching the tool to the problem.

Then ask what happens when it is wrong, and how you would find out. A vendor who has thought about agents seriously has an answer involving logging, replay and a human checkpoint. A vendor who has not will tell you the model handles it, which is not an answer, it is the absence of one.

Frequently asked questions

Is an AI agent the same as automation?

No. Automation runs a sequence you defined in advance. An agent decides the sequence at runtime based on intermediate results. Automation is auditable by reading it; an agent is auditable only by watching it run.

When should I use an AI agent instead of automation?

When the next step genuinely depends on the content of the previous result and you cannot enumerate the possible paths in advance. If you can write the process down, use automation.

Is an agent more expensive than automation?

Usually yes, and the larger cost is ongoing rather than upfront. Debugging, testing and changing an agent all cost more, because you cannot simply read the definition to know what it will do.

Can you combine both?

Yes, and this is the shape that most often works. Keep the overall flow fixed and readable, and give a model only the one or two steps that genuinely require judgment.