AI agents vs AI automation: what's the difference?

An AI agent is something you give a task to and then watch. An AI automation is something you set up once and leave running. Both can use the same model underneath. The difference is not how clever either one is, it is whether anybody is reading the output.

That sounds like a small distinction and it decides almost everything else: which of the two you want for a given job, how much it will cost, what it is likely to get wrong, and whether you will find out.

The short version

What an agent actually is

An agent is given a goal rather than a procedure. You say what you want, it works out the steps, uses whatever tools it has been given, and comes back with something. If it hits a problem it can change approach. If it needs to know something, it can ask you.

Which makes it good at work like this:

• Go through these forty transcripts and tell me what clients keep complaining about.
• Research these six competitors and put together a comparison of how they price.
• Reconcile this export against that one and tell me where they disagree.
• Draft the deck for Thursday from these notes.

None of those has a fixed procedure. You could not write the steps down in advance, because the steps depend on what it finds along the way. That is precisely what an agent is for, and it is why the good ones feel less like software and more like handing something to a capable new starter.

The important structural fact is at the end of every one of those jobs: you look at what came back. Not out of diligence, but because the whole point was to get a thing you wanted. If the competitor research has invented a price, you will see it, because you asked for it and you are reading it.

What an automation actually is

An automation has no goal. It has a procedure, and something that starts it. When a deal moves to a certain stage, wait three working days, check whether anything has changed, and if not, send a follow-up. It does that exactly, every time, indefinitely, without anybody thinking about it again.

Modern automations can have judgement in them. The follow-up above might be written by a model rather than pulled from a template, which is what AI automation means: a fixed procedure with a model call at the one or two steps that needed a decision a rule could not express. The procedure is still fixed. The model is doing a job inside it, not deciding what the job is.

Which makes it good at work like this:

• Chase an unanswered proposal on the third working day.
• Sort whatever lands in the shared inbox and route it to the right person.
• Assemble the monthly report and write the summary at the top.
• Set up the folders, the channel and the kickoff tasks when a client signs.

And here is the structural fact at the end of those: nobody looks. That is not negligence, it is the entire reason for building one. An automation you have to check is an automation that has saved you nothing.

Why nobody looking changes everything

Put those two facts next to each other and most of the practical differences follow without needing to be argued.

You will notice one kind of failure and not the other

Both agents and automations get things wrong. They fail at roughly comparable rates, and the same model is often doing the work in both. The difference is entirely in what happens next.

An agent that produces a bad answer is caught immediately, by the person who asked, because that person is reading it. The cost is a few wasted minutes and mild irritation.

An automation that starts doing the wrong thing is caught by whoever it did the wrong thing to. If it is chasing clients who already paid, the client tells you, and they have been receiving it for a month. If it is putting last quarter’s figure in this quarter’s report, you find out when somebody acts on the number.

This is the failure worth designing against, and it is worth being precise about why it is so hard to catch: nothing errored. Every run succeeded. There is no alert, no red mark, no failed job. The automation did exactly what it was built to do, and what it was built to do turned out to be wrong. No monitoring tool catches that, because from the outside it is indistinguishable from working.

Variation is a feature in one and a defect in the other

Give an agent the same task twice and you may get two different approaches. Usually that is fine and occasionally it is better, because the second approach was the smarter one.

Give an automation the same input twice and two different behaviours is a serious problem. If the follow-up went out on day three for one client and day five for another, and nobody can say why, then you no longer know what your business does. Consistency is most of the value.

The cost behaves differently

An agent costs money each time somebody uses it. That is visible and naturally self limiting, because a person has to decide to ask.

An automation costs money every time the thing that starts it happens, and nobody is counting those. A cost per run that looks trivial while you are testing is worth multiplying by how often the trigger actually occurs, which is frequently a much larger number than anyone guessed. This is also why pricing models matter: per task and per credit pricing makes your bill a function of how busy you are, which you cannot forecast at the start of the month.

The same job, done both ways

Take one job: the monthly client report. Numbers pulled from a few places, laid out the same way as last month, with two paragraphs at the top explaining what changed.

As an agent. On the second of the month you ask it to build the report for a client. It goes and gets the numbers, puts them together, writes the summary, and hands it to you. You read it, fix the one paragraph that missed the point, and send it. Repeat eleven more times for your eleven other clients.

As an automation. On the second of the month it runs, for all twelve clients, and the reports are in the folder when you get in. Nobody asked it. Nobody read them.

The automation is obviously better here, right up until the month a client changes their tracking and one number starts arriving empty. The agent version would have caught that, because a person read the report with the blank in it. The automation version sends twelve reports, one of which is quietly wrong, and finds out when the client asks why their conversions are zero.

That is the real trade. You are not choosing between clever and dumb, or between expensive and cheap. You are choosing between doing the work and checking it yourself, or not doing the work and not checking it. Which is fine, and is the correct choice for most repeating jobs, as long as you went into it knowing that the checking went away too.

The question that settles it

There is one question that separates these two more reliably than any feature list, and it is worth asking of any tool you are considering.

Can you say in advance exactly what it will do?

If yes, it is an automation, and the useful consequence is that anything knowable in advance is checkable in advance. You can read what it will do before it does it. You can run it against last month’s real data with everything switched off and look at what it would have sent. You can be wrong on paper instead of wrong at a client.

If the answer is that it depends on what it decides at the time, it is an agent, and there is nothing to check in advance, because the thing that would need checking has not been decided yet. The only meaningful review happens after the fact, which means somebody has to be there to do it.

That is not an argument against agents. It is an argument for matching the review to the thing: if it decides at the time, be there at the time.

The confusing middle

The terms have got muddier over the last year, mostly because “agentic” sells better than “automated”, and it is worth knowing what you are looking at.

An automation with a model call in it gets called agentic all the time and it is not. If the sequence is fixed and only one step involves a judgement, that is AI automation, and calling it something else does not add any capability.

An agent on a schedule is the genuinely different one, and it is the arrangement that deserves the most thought. Something that decides its own approach, running unattended, on a timer. Both of the things that normally catch a mistake are missing at once: nobody is reading the output, and the behaviour was never fixed enough to check beforehand. Sometimes that is exactly what a job needs. It should be a decision somebody made on purpose, and it should come with a much narrower set of things the agent is allowed to touch.

A tool that does both is increasingly common and is usually fine. The thing worth establishing is which mode a given piece of work is running in, because the two want completely different amounts of supervision and it is easy to end up with an agent running on a schedule without having decided to.

Which one you want

Most businesses want both, for different jobs. The mistake is not usually picking the wrong one overall, it is using one where the other belongs.

Reach for an agent when: the work is different every time; you could not write the steps down in advance; you want a thing rather than a process; it is occasional enough that a person can be there for it; and reading the output is not a burden, because reading the output was the point.

Reach for an automation when: the work repeats on something you can name; it has the same shape every time; it needs to happen whether or not anybody remembers; and the cost of it being quietly wrong is one you have actually thought about.

If you are not sure which of your jobs are which, the honest answer is that the sorting matters more than the choice. Working out where your hours actually go is a separate exercise, and it is the one that decides whether any of this pays off.

Where we come into it

Everything above is true whichever tools you use. This part is about ours, and it is the only part that is.

Nrth Star builds automations, not agents, and it is built around the answer to the question two sections up. Every automation it builds is fixed in advance, which is what makes it possible to hand you a plain-English description of exactly what it will do before it does anything, and then replay it against your last 30 days with everything switched off so you can read what it would have sent, client by client. That is aimed squarely at the failure this post spends the most words on: the one where nothing errors.

Which also means there is a large amount of work it is the wrong tool for. Anything one-off, anything open-ended, anything where you wanted a document rather than a process, is agent work, and there are good agents for it. If what you need is a research pass or a deck, use one of those. If what you need is for the proposal to get chased on the third day forever without anybody thinking about it, that is the other thing, and it wants checking before it starts rather than watching while it runs.