An agentic workflow is a work process in which an AI agent chooses its own next step and tool; at Oase Creative, 44 leftover email drafts taught us that such a workflow is only reliable with a check afterwards.
What is an agentic workflow?
An agentic workflow is a work process in which an AI agent chooses the next step itself. A regular workflow does the same thing every time: form comes in, data goes to the CRM, confirmation email goes out. In an agentic workflow, an AI agent gets a goal and a set of tools, and decides what to do case by case. Look something up first, then write a draft, then check another source because the answer didn't add up.
Anthropic, the company behind Claude, draws the line like this: workflows follow predefined code paths, while agents direct their own process and their use of tools. An agentic workflow is the combination: a fixed frame with an agent that decides for itself in one or more places.
On our site we call this agentic flows. It is the same kind of system. The name matters less than the question behind it: who is watching when the agent makes the wrong choice?
How does an agentic workflow differ from regular automation?
The difference is who sets the route. With regular automation the route is fixed, and the builder sets it in advance. With an agentic workflow only the goal is fixed, and the agent picks the route.
| Regular automation | Agentic workflow | |
|---|---|---|
| Who decides the steps | The builder, in advance | The agent, each time |
| Behaviour on the same input | Always the same | Can differ |
| Good at | Fixed, repeatable tasks | Tasks that need reading or judgement |
| Typical failure | Stops when input deviates | Carries on with a wrong assumption |
| Cost per run | Low and predictable | Higher, varies with the number of steps |
| What you need to check | Whether it runs | Whether it chose well and nothing happened twice |
That last row is the core. Regular automation that breaks usually stops. But an agent that chooses wrong carries on. So a wrong assumption in step two becomes a wrong search in step three and a wrong email in step four.
That is why most tasks in our own system run as plain scripts, without a language model. The agent only sits where judgement is needed: research, drafts, sorting what comes in. Cost matters too. With an agent you pay per step it takes, and the number of tool calls drives the bill more than the number of workflows.
Where does an agentic workflow go wrong without checks?
In three places, and you see none of them in a demo.
Duplicate actions. An agent sends an email, gets a timeout back and tries again. But the first email did go out. Researchers at Old Dominion University measured this: on a task that records invoices, a standard agent produced duplicate side effects in 32%, 52% and 76% of runs at low, medium and high fault levels. An agent that first checked whether the action had already completed brought that down to 0%, 16% and 20%. The authors note themselves that it is a small, simulated setup. Read the numbers as a direction.
No person between agent and outside world. In an analysis of 6,003 public n8n workflows, only 2.78% asked a person for approval before an external action.
Watching, not testing. LangChain surveyed teams building agents: nearly 89% have monitoring on their agents, but 52% also test them against fixed examples. So you see what the agent did, but you don't check beforehand whether it does it well.
Which mistakes did we make ourselves with agentic flows?
Since March 2026 we have been running an agent system that helps run our agency. Every check in it today comes from something that went wrong. Five examples, all from our own log.
| What went wrong | Why you didn't see it | The check we built |
|---|---|---|
| A failed send reported itself as successful; 44 drafts were left behind | The exit code said "success" | After every send, check that the email is actually in Sent |
| Tasks were marked done while the result was missing, five times in one day | Only the status was checked | A task only moves to done once the result demonstrably exists |
| A check approved runs because a file existed, not because of what was in it | There was "something" | The check demands the proof itself, such as a link to the posted message |
| The scheduler kept running old code from memory | The file had been updated | Restart after a change, and an alert when it goes quiet |
| The AI service returned an error six times in a row; for forty minutes no reply came | The system itself could not report anything | A separate monitor outside the AI that alerts after two errors in a row |
The pattern is the same every time. The system thought it had worked, and nobody checked the thing itself. Measured over 134 days, almost a third of our failed runs was our own quality gate saying no. That is not a side issue. That is where the system did its job.
When is an agentic workflow the right choice?
When a step needs judgement you can't capture in rules. Reading an email and deciding whether it is a question, a complaint or a quote request. Looking up information that differs per case. Writing a draft based on what a customer said earlier.
It is the wrong choice when the steps are always the same. Then a script is cheaper, faster and more predictable. Most work processes consist of a few moments of judgement in a long row of fixed steps. Build those fixed steps as a script and put the agent only on the moments of judgement.
A quick test for any process:
- Does the input differ in shape every time? Then an agent adds value.
- Does the result go outside your business? Then a person has to see it first.
- Can you undo a mistake? No means: check first, then act.
At Familierestaurant Pluis you can see that split. The newsletter runs as a system, but a person approves every email before it goes out. Sign-ups move to the mailing list every hour through a fixed script. Judgement where it is needed, fixed rules where they will do.
How do you make an agentic workflow reliable?
With four checks you put in place before going live, not after.
- After every action, check that it worked. Not on the system's report, but on the thing itself: is the email in Sent, is the booking in the books. Only then retry.
- Put a person between the agent and the outside world. Everything that goes out on behalf of your business first gets an approval. For us that is a recorded approval tied to an actual message, not a tick box.
- Give every task its own pause switch. So you can stop one part while the rest keeps running.
- Test against a fixed set of examples. Every time you change the agent's instructions, you run the same set again and compare the outcome.
Together those four make the difference between an agentic workflow you build and one you manage. We call the second managed automation: the builder stays responsible after delivery.
How does Oase Creative build agentic flows?
We build AI systems and agentic flows for recurring work, from content and email to admin. First we map the process: which work comes back every week, who does it now, what goes out. Then we decide where an agent adds judgement and where a script will do.
Every flow we deliver has the four checks above. Not because they are on a checklist, but because we needed all four in our own system first. You can follow what the system does, pause it at any moment, and after the first month we look together at what it does and what needs to improve. If you want us to keep monitoring and improving it after that, we offer that as managed automation, with pricing on request.
Want to know whether an agentic workflow would pay off for you, or whether a script is enough? Tell us where things get stuck, and we will look together at where you can best begin.
