AI automation is work a system takes over where a language model reads, judges or writes somewhere in the process; at Oase Creative, most of our own scheduled tasks deliberately run without AI.
What is AI automation?
AI automation is work a system takes over, with a language model making a call somewhere. That model reads, judges or writes; the rest of the process does not. In practice, three very different things hide under that one word:
- Ordinary process automation. A rule or a script. The same input always gives the same output.
- An AI step in a process. The process is fixed, but at one point a model reads a text and returns a judgement or a draft.
- An AI agent. The model chooses which action comes next, and carries it out.
People searching for "ai automation" or "business process automation" often only need layer 1. Sometimes layer 2. Rarely layer 3. Yet conversations about AI usually start with the agent, because it sounds the most exciting.
We build this for clients, and we run it ourselves. Our own system carries out dozens of scheduled tasks every day. Most of them contain no AI. That is a deliberate choice: most automation does not need a language model, and where there is one, we put a gate in front of it.
This piece pulls the three layers apart. For each layer: what it is, a recognisable example, what goes wrong, and when you should not use it. We already wrote a separate piece on cost: what automation costs, and why you count tool calls instead of workflows.
Which three layers fall under AI automation?
The three layers differ in one thing: how much the system decides on its own. A script decides nothing, it executes. An AI step decides at one point. An agent decides the order of the whole job. The more the system decides, the more it can do, and the more you need in between to catch mistakes.
| Layer 1: script | Layer 2: AI step in a process | Layer 3: AI agent | |
|---|---|---|---|
| Who decides the next step | You, in advance | You, in advance | The model, along the way |
| Same input, same output? | Yes | No, can vary per run | No, the route varies too |
| Can read free text | Barely | Yes | Yes |
| Typical example | Form to CRM, order to packing slip | Sorting email, summarising a request, writing a draft | Searching, planning and driving several systems on its own |
| How it goes wrong | Breaks hard and visibly | Sounds convincing and is wrong | A small error compounds over several actions |
| What it needs in front | An alert when it stops | A person or hard check on the outcome | Approval before every outward action, plus a pause switch |
The "how it goes wrong" row is why we are strict about the layer. A script that breaks, stops. You get an error, someone looks at it, done. A language model that is wrong does not stop. It produces a tidy sentence that looks fine. That is where the risk sits, and that is why the layer decides how much control you build in, not the tool.
Platforms like Zapier, Make and n8n can handle all three layers. That does not make the choice easier. In one workflow you can chain a fixed step, an AI step and an agent, and from the outside you can no longer see which part is predictable and which is not. So always map it out first, step by step: who decides here?
When is a plain script enough?
A script is enough as soon as you can write the steps down in advance and the input has a fixed shape. That covers far more work than people think. An order comes in, a packing slip has to come out. A contact form is filled in, the details have to go into the CRM. An invoice is paid, the status has to change. No judgement involved, just discipline.
An example from our own system. Every half hour a script runs through our inbox. It sorts, archives what can go, and flags what stands out. Two deliberate choices: it archives instead of deleting, so everything can be brought back. And messages from the contact form on our site always go through to Louie as a lead, whatever the other rules say. No language model, no interpretation. A list of rules we wrote ourselves.
A second example: every evening a publishing preflight runs. That script dry-runs every check the publication will run the next morning, and publishes nothing itself. If something fails, we get a signal while there is still an evening left to fix it. The script exists because we had mornings where an article got stuck on a small layout error and nothing went live that day.
What goes wrong. A script is only as smart as the shape of its input. If a supplier renames a field, a form changes or an email arrives in a format nobody expected, it breaks. Annoying, but it breaks hard: it stops and you see it. So above all, make sure you notice. A script that stops silently is worse than one that stops loudly.
When not to. If you find yourself writing a new exception into your rules every week because customers keep phrasing their question differently, you are solving a language problem with rules. That is the moment for layer 2. Not before.
What does an AI step in a process do?
An AI step is one point in a fixed process where a language model reads a text and returns something: a label, a summary or a draft. Everything before and after it stays ordinary automation. The model may read and suggest; it may not decide what happens next.
Recognisable examples: labelling an incoming email as a quote request, complaint or spam. Summarising a long quote request into five lines for the salesperson. Preparing a first draft reply that someone still has to read and send. Pulling product information out of a supplier's PDF into fixed fields.
An example from our own system. This article. Every morning an agent reads news and research and lines up the findings with their sources. Another one writes a draft from that. After that, no AI is involved: a fixed script checks the draft against style rules, and a second script puts every figure in the text next to the page it came from. If the figure is not on that page, the draft does not pass. Then Louie reads it, and only with his approval does it go live.
That fact check exists for a reason. Earlier drafts contained figures without a source, and a few times a source that did not exist. The model had phrased them neatly. Nobody could have told from the sentence.
What goes wrong. A language model does not always give the same answer to the same question. It can label an email as a complaint one time and as a question the next. And it can be confidently wrong: copy an amount incorrectly, invent a name, cite a source that is not there. The person who notices is usually the customer who got the answer. By then you are too late.
When not to. If the outcome has to be exactly right and there is a fixed rule for it, do not use a language model. Calculating a discount, updating stock, assigning an invoice number: a script gets that right practically every time, a model most of the time. Most of the time is not enough there.
When is something an AI agent, and when do you build one?
An AI agent is a language model that chooses its own next action and carries it out: searching, calling a system, editing a file, sending a message. The difference with layer 2 is not how smart the model is, but who decides the order. With an agent, you have not fixed the steps in advance.
That makes an agent useful for work where you cannot predict the route. Research is a good example: which source you read next depends on what you found in the previous one. A customer question that first has to be looked up in three systems is another.
What goes wrong. With an agent, errors compound. A wrong assumption in step two becomes a wrong search in step three and a wrong email in step four. And an agent that does something in the outside world cannot be undone. In practice that risk is rarely covered. Researchers looked at public n8n workflows with a language model in them. Only 2.78% of 6,003 workflows ask a human for approval before an external action. In 26.52%, the model's output goes straight to an action without any check. The researchers' own caveat: these are shared designs and templates, not what runs in production. But templates are where most people start.
An example from our own system. Our agents prepare, they do not send. Six days a week the system lines up two potential clients with a draft email. Nothing leaves without Louie approving each email individually, and that approval is recorded before sending starts. Every agent task also has a pause switch: a single file that stops the task without breaking anything.
When not to. If you can draw the process on one page with fixed steps, do not build an agent. You would be paying for freedom you do not want. And if nobody in your business can judge the outcome, do not build one either: an agent without someone watching is a gamble you take again every day.
Why does our own system run mostly on scripts?
Because most of our work needs reliability, not judgement. Our system is called Milo and runs on a single laptop, day and night. It carries out dozens of scheduled tasks every day. Go through them and you see a clear split.
| Task in our system | Layer | Why that layer |
|---|---|---|
| Sorting and archiving the inbox | Script | Fixed rules, and a mistake must be reversible |
| Pre-publishing check, every evening | Script | Has to test exactly the same thing every time |
| Check for tasks that get stuck | Script | An alarm that sometimes fires and sometimes not is worthless |
| Style and source check on drafts | Script | The gate itself must not have an opinion |
| Summarising research and news | AI | Reading free text and choosing what matters |
| Writing drafts | AI | Language, with a person and a script behind it |
| Preparing potential clients and draft emails | AI | Needs judgement, sending only after approval per email |
The pattern: everything that is a gate is a script. Everything that needs judgement may be AI, but always sits behind such a gate. A gate with its own opinion is not a gate.
The check for stuck tasks shows why. At one point it produced a stream of empty alarms, because two scripts each kept their own list of what to ignore. The fix was not a smarter check, but one shared list that both scripts read. What the check skips now goes into a log instead of quietly disappearing. Boring, checkable, and it works.
We measured separately what such a system costs to maintain: what an agent system costs to maintain, over 134 days. In short: the AI parts need the most attention. One more reason to keep them small.
Where do businesses get stuck with business process automation?
Not on the technology, and not first on price. In a vendor survey by Zapier and Centiment among 508 small US businesses, 43% name "which tool works?" as the biggest blocker, against 34% for cost. Zapier sells automation itself and this is the US only, so read it as a direction, not as a fact for the Netherlands. Striking in the same survey: 30% already let AI act across multiple systems with limited human input. That is layer 3, without anyone calling it that.
In larger organisations you see a different problem: it stays at trying. Deloitte asked over three thousand organisations, and only 25% have 40% or more of their AI pilots in production. Gartner saw the same picture in its own survey: only a small share of organisations have rolled AI out across multiple business units.
Our reading of those figures: most pilots are an agent or an AI step built before anyone mapped out the process. The demo works, and a few weeks later it turns out nobody knows who checks the outcome. How small Dutch businesses are doing, with figures from Statistics Netherlands, is in our piece on AI implementation in small businesses. And if you want to hire someone to build it, first read how to separate the real AI providers from the rest.
Which task do you automate first?
Start with a task where you see the error the same day. Not because it pays off most, but because you learn fastest from it. A form that does not land in the CRM, you notice the same afternoon. A wrongly labelled email, you only notice when a customer calls back. So start with the first kind, without AI, and only add an AI step where a person now has to read and choose. An agent only comes into view if after a few months you see that the route genuinely differs each time.
Run every candidate through these questions:
| Question | If the answer is yes |
|---|---|
| Can you write the steps down in advance? | Layer 1. Build a script or a fixed workflow. |
| Does someone now have to read free text to choose? | Layer 2 at exactly that point. The rest stays layer 1. |
| Must the outcome be exactly right (amount, stock, number)? | No language model in that step. |
| Does the outcome go to a customer or a system outside your business? | A person or hard check in front, always. |
| Does the route differ each time, and can you not map it out? | Only then layer 3, with approval before every external action. |
| Can nobody judge the outcome? | Do not automate yet. First find someone who can. |
A few tasks we often start with: contact forms into the CRM, orders to the shipping partner, sorting email with one AI step for the label, and draft replies that someone still reads. Not exciting. But work that costs hours every week, and where you see after a month whether it works.
Two things we pin down for every first automation. One: who gets an alert when it stops, and what does that person do then. Two: how do you switch it off. An automation you cannot pause is one you will turn off after the first mistake and never turn on again.
If you want to build this yourself in a tool like n8n or Zapier, first work out what an AI step or agent costs per run in tasks or executions. That is worked out in our piece on what automation costs.
How do we approach AI automation at Oase Creative?
We start with the process, not the tool. What work comes back every week, who does it now, and where is the judgement? Only then do we choose the layer per step. In practice, the vast majority becomes ordinary automation, with AI in the few places where a person now has to read and decide.
What we always build in, because we run it that way ourselves:
- A person or hard check before anything goes out. No email, message or publication without someone or something having tested it.
- A pause switch. You must be able to stop every automation without breaking anything.
- An alert when it stops. Failing silently is worse than failing loudly.
- Fixed rules in scripts, judgement in AI. Never the other way round.
Part of that is accepting that AI is not always the answer. Sometimes the best outcome of a first conversation is that you need a few fixed workflows and no agent. Then we say so. If something needs building that goes beyond a workflow, such as your own internal tool, that falls under software and app development. What we deliver around automation and agents is on the page about AI systems and automation.
Got work that comes back every week and you are not sure which layer it belongs in? Tell us where it gets stuck, and we will work out together where you can best begin.
