Agentic Automation vs Workflow Automation: The Line That Actually Matters

Agentic automation is automation where the software chooses the next step at run time. Workflow automation is automation where a person chose every step in advance and the software only executes them. That single difference, who decides the path, dictates everything else: what can go wrong, where the controls have to live, and which jobs each one is fit for.

We run both. On 26 July 2026 our n8n instance held 115 workflows, 70 of them active. Three days later our Hermes-based agent mesh had 7 profiles carrying 119 skills between them. Nothing was migrated from one to the other. What we did instead was put the agents in front of n8n with a gate between them, and the reasons why are the whole argument of this post.

What is the actual difference between agentic automation and workflow automation?

A workflow executes a path somebody drew. An agent picks the path. In a workflow, the branches, conditions and failure routes were all decided by a human at design time, so approval happened before the first run. In an agent, the branch is decided by a model at run time, so approval has to happen then, or not at all.

Anthropic's engineering team, in its December 2024 guide Building Effective Agents, draws the same line: "Workflows are systems where LLMs and tools are orchestrated through predefined code paths. Agents, on the other hand, are systems where LLMs dynamically direct their own processes and tool usage, maintaining control over how they accomplish tasks." The word that matters is control. Whoever holds it is the party you have to govern.

Most definitions stop there and treat the two as rungs on a maturity ladder, workflow first and agent later. That is the wrong frame. They are answers to different questions. The question a workflow answers is "we know what to do, do it every time." The question an agent answers is "we do not know the next step until we see the input." A business that moves its known, repeatable paths into agents has not matured. It has taken decisions a person already made and handed them back to a model to re-make, with variance, on every run.

Why does "who decides" change where the controls have to live?

Because a control has to sit somewhere the decision-maker cannot reach. In a workflow the decision-maker is the person who drew it, and the control is design review. In an agent the decision-maker is the model, and the model can read anything inside its own container, including a rule that says it may not act.

We learned this on 29 July 2026, the day we built the write gate. Our first instinct was the obvious one: tell the founder agent in its system prompt that it is read-only by default, and give it an approval code to type when it wants to write. Both fell over on inspection. A prompt-enforced restriction is convention, not enforcement, because an agent hit with injected text cannot tell our instruction from the attacker's. And an approval code stored where the agent runs is theatre. The agent can read the code, or brute-force a three-digit one.

So the code and the write credentials moved to where the agent cannot go. The executor is a root-owned program on the host, reachable only through an SSH forced command, holding credentials in a file the agent cannot read. The agent submits a typed proposal. A one-time code, bound to that single action and expiring in sixty minutes, goes to the founder's phone. The agent relays the code back. It never sees the keys, and it never sees the code before the founder does. Three wrong codes and the proposal auto-rejects with an alert. We then attacked it ourselves: the agent could not read a pending code through the status command, the key yielded no arbitrary command, and every unregistered action type was refused at the door.

The OWASP Top 10 for LLM Applications names this failure class Excessive Agency: "the vulnerability that enables damaging actions to be performed in response to unexpected, ambiguous or manipulated outputs from an LLM, regardless of what is causing the LLM to malfunction." Read the last clause twice. The cause does not matter. Once the model decides the path, a hallucination and a prompt injection are the same risk, and neither is fixable in the prompt.

The full construction of that gate, including the two policies that did not hold on the first attempt, is in our post on AI agent governance.

Where did the n8n workflows end up, and why were they not migrated?

They stayed in n8n. All 70 active workflows kept running as workflows, because each one is a path a person had already drawn and approved. The agents got three things: a read-only view of every workflow and its executions, the ability to create new workflows in an inactive state, and a gated verb to switch one on.

The temptation in an agent build is to re-express everything as an agent, because it feels like progress. Our website lead intake is an n8n workflow: a form fires a webhook and the payload fans out to four destinations. Nothing in that path benefits from a model choosing. The same input should produce the same four writes every time, and a workflow guarantees that where an agent only tends to. The daily ad-account funds check is the same shape. Scheduled, deterministic, and boring in the way money-touching automation should be.

What the agents are for is the other question, the one where the next step is unknown until the input arrives. Reading a contract and a scope document and filling twelve sections of a client record is that kind of job. When our operations agent ran it on its first client on 30 July, it filled 9 of 12 sections, left 3 honestly marked as not yet collected, and every quoted figure in its output matched the source verbatim. A regex sweep for currency or percentage figures that did not appear in the source returned zero. No workflow could have done that job, and no agent should be trusted to do it without that check.

The hybrid is where it gets interesting. On 29 July the gate grew from 10 registered action types to 17, and among the new ones were three n8n verbs: create, activate, deactivate. An agent can now draw a workflow, but it arrives switched off. Turning it on is a separate, human-approved step. The agent proposes the path, a person approves the path, and n8n then executes the path with no model in the loop at all. The agent's decision gets frozen into a workflow before it is allowed to have consequences.

This is the shape we build for clients too: n8n workflow automation for the paths you already know, AI agent development for the decisions you cannot script, and a gate between them. Our AI automation services page lays out the full stack.

How do you decide which actions an agent may take on its own?

By consequence, not by capability. Our line, settled on 30 July 2026 after a day of over-gating: irreversible, outward-facing or spend-changing actions need a human code, and routine, reversible, internal actions are self-service within the agent's role. The agent keeps every capability. Only the consequences are gated.

We got this wrong in both directions inside 48 hours. First we over-restricted. An early version made the agent's own tools read-only and froze its learning, which added almost nothing to security (the gate is enforced server-side, so editing a wrapper gains an attacker nothing) while disabling a headline capability. That was reverted the same day. Then we over-gated. Every one of the 24 action types then registered needed the founder's code, so a co-founder trying to enter client terms hit an approval prompt on every section. Twenty-seven clients times twelve sections is roughly 324 codes through one person. That is not a control. It is a reason the database never gets filled.

The fix was per-agent keys with the profile name baked into the forced command, so the key itself is the identity and one agent cannot claim to be another, plus a narrow auto-approval list. A client record write now executes at once, the founder gets a notification rather than a request, and the audit line names the agent. When pricing edits were opened up later the same day, we did not gate them again. We added a distinct pricing-changed alert instead, so a retainer change is visible the instant it happens. Visibility replaced permission, which is usually the right trade for a reversible write.

The line also moves with role. Creating an inactive n8n workflow is self-service for the operations and founder agents. Activating one auto-executes for those two and stays gated for the HR and business-development agents. The action is the same; the authority differs by seat. That is why we say the org chart is the routing map, which is the subject of our post on the agent mesh.

What broke, and what did it teach us about governing decisions?

Two things broke, and neither was the gate. Once, a rule stayed in the prose after the runtime stopped enforcing it. Once, every control worked perfectly while the whole mesh was dead for six days. Both taught the same lesson: when a declaration and a behaviour disagree, the agent believes the declaration and nobody checks the behaviour.

The prose failure came on 9 August. Activation had been opened to the operations agent ten days earlier, but its identity file still read: "You propose, you don't execute. Changes to campaigns, CRM or workflows go through the approval gate." The gate had already granted it every one of those actions. The permission was granted in the runtime and withheld in the text, and the text is what the agent reads every time it reasons. Nothing errored. Seventeen messages passed between two agents in three hours, all of them asking permission for a decision the asker already owned. The tell was cost, not error.

The silent failure surfaced on 8 August. A model change six days earlier had made the runtime refuse every unpinned scheduled job, to prevent unintended spend. That refusal is correct. It also failed each job forever and told no one. Around 2,975 consecutive failures across three subordinate agents, including the pollers that carry messages between them. The message bus served 200s, the dispatcher woke the workers, the container isolation held, and the workers died on arrival, 100 per cent of the time. A correct refusal that is silent is an outage generator. The wider pattern, a control that is declared but never applied, is the subject of our post on AI governance controls.

Why this matters for the workflow-versus-agent question: a workflow that fails a thousand times in a row is, from the outside, indistinguishable from one that had no work to do. That is true of n8n and true of agents. The difference is that a workflow's silence is at least about a path you can read. An agent's silence hides a decision nobody saw it make, or fail to make.

The primitive: govern the decision, not the path

A workflow is approved when it is drawn. An agent has to be approved when it acts, by something it cannot reach. Every design choice above falls out of that one sentence. Keep known paths in workflows, because the approval already happened. Give agents the unknown-path jobs, and put their consequential actions behind a gate that lives outside their container. Let an agent draw a workflow, but make the switch-on a human act, so the model's choice is frozen into a path before it has consequences. And when you set the line, set it by consequence: gate the irreversible, the outward-facing and the spend-changing, and leave the reversible open but visible.

We ran this on ourselves before offering it to anyone. The whole build, seven agents doing real jobs across a live agency, is in the Neogen AI OS case study. If you are deciding which of your processes should be a workflow, which should be an agent, and where the gate goes between them, talk to us.

Frequently asked questions about agentic automation

Is agentic automation just workflow automation with an LLM node in it?

No. An LLM node inside an n8n workflow still runs on a path a person drew. The model fills a field, classifies a message or writes a paragraph, but it does not choose the branch. Automation becomes agentic when the model selects which tool to call next, and how many times, before the task is done. That is the moment the governance problem changes.

Does agentic automation replace n8n or Zapier?

Not for paths you already know. In our own build, all 70 active n8n workflows stayed exactly where they were. The agents were given a read-only view of them, the right to create new ones in a switched-off state, and a gated verb to activate. If a process runs the same way on every input, keep it as a workflow. It is cheaper, deterministic and already approved.

How long does it take to put a gate in front of an agent?

Our first working gate took one day, 29 July 2026, from design through adversarial testing, with no new container and no second bot. Tuning where the line sits took two more days, and it moved twice on the second of them. Budget for the tuning rather than the build. The mechanical parts are quick; deciding what counts as consequential is the part that involves people.

What should be self-service for an agent, and what should need a human?

Our line is consequence, not capability. Gated: invoice delivery and payment posting, live ad-spend changes, turning a workflow on or off, and any host or infrastructure mutation. Self-service: client record updates, drafts, reports, creating a workflow that is not yet active. The test for each action is whether it is irreversible, visible outside the company, or changes spend. If none of those, open it and make it visible instead.

Can a small business run agentic automation safely without an engineering team?

Yes, provided the gate is mechanical rather than written. The controls that held for us are cheap: an SSH forced command, a credential file the agent cannot read, one key per agent, and a registry of allowed action types. The control that failed was the one that looked easiest, a rule written into the agent's prompt. Spend the effort on the mechanical layer and keep the prompt for describing the job.

What is the right first job to give an agent?

One where the input is unstructured and the output can be checked against a source. Our first was a single client record filled from a contract and a scope document, chosen because every quoted figure could be verified. We deliberately ran one client rather than thirteen, because 13 clients times 12 sections is 156 sections written unattended, with no gate to catch a plausible invention. Start with one and check it.