Strategic call Automations used to be small. A macro here, a sync there. Today a single company can run hundreds of workflows and AI agents with access to its CRM, its finance tools and its customer data. At n8n, the product team made the case that this changes what matters. Building a workflow is the easy part. Running it reliably, seeing what it does and controlling who can do what is where the real work sits.
Here is what was presented, and what it means if your business runs on automations.
The automation lifecycle has a back half
Every automation goes through the same cycle: you plan it, you build it, you deploy it, you monitor it, and you manage the whole ecosystem around it, including who has access and what is allowed to happen. Then you go back to building. n8n has always covered that entire cycle, but the talk focused on the back half, which n8n calls the platform: deploy, monitor and manage. That is where reliability is won or lost.
Inexperienced automators tend to forget this part. A workflow needs somewhere to run, someone to notice when it fails, and rules that keep it from doing damage.
Why n8n is rewriting its engine
The engine that runs workflows is the heart of n8n. It was the first part of the product, and much of it is still the original code written by founder Jan Oberhauser. That is the kind of critical system you do not touch without a very good reason. n8n now has one: the engine is being rewritten from the ground up.
The obvious question in an AI world is why not just let AI write code and run it somewhere. Running code is a well understood problem. When AI coding tools took off, the team went back to the drawing board and experimented with exactly that: an engine that simply runs code.
What they found is that you lose things. In n8n you can see every step of a workflow light up and inspect the data at each step. Because every step is visible and saved, you can resume where a run left off. And because you can resume, you can retry failures automatically. Once those requirements were added back in, the design looked much more like a workflow engine than like running pure code. So the result is a new workflow engine, designed around a reliability framework.
Six principles of reliability, explained with a restaurant
A restaurant is also a system, and it maps surprisingly well to automation.
- Write it down first. A waiter writes the order on a ticket that goes to the kitchen rail. The order no longer lives in the waiter’s head, so nothing is lost if something happens to the waiter.
- One version of the truth. If the sign on the door says open, the restaurant is open. A system cannot be in two states at once.
- Every job must reach an end. No order may sit forgotten in the kitchen going cold. Every run finishes, one way or another.
- Contain the damage. When the fuse of one fridge blows, it must not take out all the other fridges.
- Make it safe to try again. Pressing a lift button twice is fine. Being asked to pay twice is not.
- Everything leaves a trail. Even the orders that could not be served are recorded.
What those principles mean inside the engine
Applied to n8n, the principles translate into concrete properties:
- Data is saved after every step, so you can inspect what happened and restart where a run left off.
- A reconciliation process finds runs that got stuck and repairs them.
- Steps are only retried automatically when they are marked safe, so side effects such as payments or emails are not repeated.
- Code runs in a sandbox. It cannot escape and affect the rest of the system, so the engine does not have to trust it.
- Worker pools let you give one or two critical workflows dedicated capacity, so a busy workflow elsewhere cannot slow them down.
- Resources are isolated and limited per run.
- Waits are stored as scheduled jobs instead of living in memory, so a restart does not lose them.
Around the engine sits the rest of the lifecycle: workflows are switched on, start up, run and are cleaned up afterwards. n8n already keeps backups of all of this, but it is moving to a setup where the load is shared. Instead of standby systems doing nothing, every node processes jobs and can take over more load, which makes a single point of failure even less likely.
Monitoring: one view over every instance
n8n already has insights, log streaming, audit logs and, more recently, OpenTelemetry support. But serious users run more than one instance, for example a development and a production environment, or separate instances per department. The speaker mentioned that even Anthropic runs more than one n8n instance.
What those users ask for is a layer on top: one place to see the entire n8n ecosystem without logging in to each instance. n8n is building exactly that, under the working code name Manifest. It answers the questions automation creates: what exists and is running, who owns it, and which systems are touched by which automations. It is currently in trial. At first it covers automations built in n8n, but the vision is to cover every automation in an organisation, whether it runs in n8n or not.
Governance when you have more agents than employees
The final part was about managing: the human and organisational side of running automation. A forgotten macro is shadow IT, a concern but a manageable one. Hundreds of agents with access to critical systems are a different story. And because a small company can now run more agents than it has employees, each of them as powerful as a person, governance is no longer a topic only for large enterprises.
n8n uses a four-part framework:
- Access. Who is acting and what can they do: identity, credentials and permissions.
- Guardrails. Within that access, what is limited and when: spending and usage limits, policies, anonymisation and approval gates.
- Ownership and quality. Who owns an automation, and can we trust it to keep working: lifecycle, testing, review and separate environments.
- Security. What happens when someone tries to abuse the system: prompt injection, tool poisoning and data exfiltration.
The first three pillars are about how the system behaves when it works as designed. The fourth is about what happens when someone attacks it.
What is already in place
Single sign-on makes logging in easy and secure. End-user credentials, a recent addition, mean a workflow runs as the person who triggers it rather than as its author. On the guardrail side there is human in the loop and data redaction, so not everyone can see all the data a workflow handles. Security reports are triaged and fixed, and customers receive an advisory by email with enough detail to act on. And because n8n’s code is publicly available, many people look at it and fixes can be verified instead of taken on trust.
What is coming
- Native agent identity. Most agents borrow a person’s login, so you cannot tell who did what and the agent inherits all of that person’s permissions. An agent with its own identity is narrower, attributable and revocable.
- SCIM provisioning and user groups, so access disappears when someone leaves the organisation and managing users gets easier.
- Policies and hard limits. Policies stop things before they run, limits cap the damage afterwards. Agents can loop and retry until costs run away unnoticed, and hard caps set the bounds.
- Smoother promotion between instances, and the same lifecycle that workflows have, applied to agents.
- Automated testing for workflows, bringing the evaluation suite n8n built for agents to regular workflows.
- Code sandboxing that allows more code, including imported libraries, without having to trust it.
What this means for your business
Three things stand out for any company that runs on automations.
First, reliability is a design decision, not luck. The six principles apply to every workflow we build, whatever engine it runs on: record before you act, make every run finish, retry only what is safe to repeat and keep a trail. Most broken automations we audit fail on exactly one of these.
Second, visibility is becoming a requirement. If you cannot answer what is running, who owns it and which systems it touches, you are one departure or one expired credential away from an outage nobody understands.
Third, governance is no longer an enterprise luxury. If your agents act with a colleague’s login and no spending cap, you have more access risk than most corporations. The fix is not to stop automating. It is to give every agent its own identity, every workflow an owner and every critical step a guardrail.
That is how we build automations at Viralistic, and it is what we check when we take over an existing setup. Read how we govern automations, see our automation service, or prepare for the next release with the n8n 3.0 upgrade checklist.
Frequently asked questions
Why is n8n rewriting its workflow engine?
The original engine is the oldest and most critical part of n8n. The team rebuilt it around a reliability framework: data saved after every step, safe automatic retries, repair of stuck runs, sandboxed code, dedicated worker pools and shared load instead of idle backups. Simply running AI-written code was considered and rejected, because you lose the step-by-step visibility and the ability to resume and retry.
What does governance mean for a small business using AI agents?
It means knowing which agents and workflows exist, who owns them, what they can access and what limits apply. A small company can run more agents than it has people, and each agent can be as powerful as an employee. Clear access, guardrails, ownership and security keep that power under control.
What should I change in my own automations today?
Give agents their own credentials instead of a personal login, assign an owner to every workflow, add an error workflow and alerts, put spending limits on AI providers, add human approval before irreversible actions, and keep a development and a production environment. A short governance check shows where to start.