n8n Agents Change the Automation Contract: From Steps to Goals
n8n Agents shift the automation contract from laying out steps to describing an outcome. The session log becomes the audit trail; one turn becomes the budget.
TL;DR
- On September 25, 2026, n8n introduced Agents: you describe what an agent should do, give it a model and the tools and workflows it can use, and it works out the steps itself.
- The same agent is reachable from Slack, runs on a schedule, or gets called from any workflow — "the same agent in every one of those places."
- n8n now supports both directions: the workflow in charge with an agent as a step, or the agent in charge with workflows as tools — and then those workflows' permissions define what the agent can reach.
- Observability is built in: each session shows every step the agent took, the tools it called, with inputs and outputs.
- Availability: n8n Cloud for everyone on the latest stable version, self-hosted with extra setup, Enterprise "soon" — and still in preview.
- Cost is metered per turn: "One turn with an agent is one execution."
On September 25, 2026, n8n announced Agents on its blog, in a post by Ophir Prusak. The post opens by rewriting the platform's premise: "You describe what an agent should do, give it a model and the tools and workflows it can use, and it works out the steps itself." For a tool built by dragging steps onto a canvas, that phrasing moves the contract from process to outcome — the operator describes the goal, the agent negotiates the how. What the announcement leaves open is operational rather than ergonomic: who reviews the path the agent actually chose?

How agents work in practice
The announcement is careful about scope. "For as long as n8n has existed, automating something meant working out the steps and adding them to the canvas." That model still fits plenty of jobs: a lead comes in, you enrich it, score it, route it. The dividing line n8n draws is whether the next step depends on the last answer. When a teammate asks in Slack why a customer's usage dropped, answering takes a few rounds — pull the account, ask which product line, check support history — and the post names the reason: "The next step depends on the answer to the last one, so there's no way to lay out the process in advance."
The worked example is a support agent holding three workflows as tools: one pulls account context, one adds a note to the account, one pages on-call. The agent decides when each runs; what happens inside stays fixed, "the way you built it." That middle workflow is the detail worth pausing on. Without it, logging a note would mean giving the agent write access to the CRM and trusting its instructions to stay in the notes field; with it, "the agent never holds that credential." Each tool runs with its own credential, sensitive tools pause for approval, and one published agent serves Slack, a schedule, and the intake workflow — "Change the instructions once, publish, and every place it's connected gets the new version."

Workflow in charge, or agent in charge
The design decision underneath the launch is that both patterns now exist. "Sometimes you want the workflow in charge, with the agent as a step inside it. Sometimes you want the agent in charge, with workflows as tools." The Message an Agent node covers the first direction — a workflow sends a message built from its data and gets the answer back — while the Agents tab treats every existing workflow as callable tooling. n8n is explicit that the line stays movable: pull a task out of an agent when you want it fixed, hand a workflow to an agent when you want it used with discretion.
The inversion is what changes operations. When workflows are tools, the workflows' permissions define the agent's blast radius: what the agent may reach is decided by what its callable workflows are allowed to do, not by its instructions. The announcement makes the same point in plainer language: "For anything sensitive, start where the blast radius is small: scoped tools, a test channel, and approvals on any action that writes to a system of record."
What an n8n agent is made of
The definition matters because this is more than a chat wrapper. Each agent bundles a model, instructions that "read like a brief you'd write for a colleague", channels and triggers (Slack, Telegram, Linear, Discord, a schedule), tools at three levels — MCP servers, n8n integrations set up for one specific action, whole workflows — plus skills, sub-agents, knowledge files, memory, and sessions. "Memory, sessions, channels, versions and approvals come with every agent", the post notes; sessions are stored, reviewable, and resumable, and drafts publish as versions teams keep using in the meantime.
For teams on the AI Agent node, nothing breaks: "The AI Agent node is still there and works as it always has." The primitive sits alongside the old one rather than replacing it, so most existing builds do not change yet. The comparison n8n reaches for: a pre-built PC versus building your own — everything arrives connected, and you can still open it up.

Governance and operations: session logs, blast radius, budgets
Here the launch turns into an operating decision. Every session records each step the agent took, the tools it called, and the input and output of every call — so n8n ships the audit trail by default. The session log is the review surface; treat it like a diff in code review — the gate for what the agent keeps doing, not an afterthought.
The cost model makes that contract countable. "One turn with an agent is one execution." Calls from workflows or sub-agents do not count separately; they share the workflow execution quota. n8n Assistant also consumes AI credits when you build an agent, a distinct build-time cost. That makes the execution count a usable budget unit — a point reinforced by our explainer on API rate limits as part of agent architecture: limits belong in the control plane, not the prompt. A turn meter is an enforceable ceiling before the bill arrives, which matters more in production than in demos.
A daily n8n operator — I run Netics' own automation on it — meters that budget before connecting an agent to a system of record. Take a hypothetical: a support queue where the agent may call the note-writing workflow but not the account-export one; the export stays out of reach because that workflow is not in its toolset.

What to watch: preview status and the parts that stay the same
The launch carries honest caveats. Agents are on n8n Cloud for everyone running the latest stable version, self-hosted deployments need "some extra setup", Enterprise support is "soon", and the feature is still in preview — n8n's baseline is test before publishing, keep approvals on anything sensitive. The inconvenient facts matter for planning: agents fit open-ended jobs rather than fixed sequences, self-hosting is not turnkey yet, and the unchanged AI Agent node rewards the teams that already understand the new contract.
The practical sequence is short: decide which workflows an agent may call, and what those workflows can do, before connecting it to production; review the session log like a diff; put a number on the turn meter before the first busy month. Teams that treat the journal as audit trail and the turn as budget unit get the ergonomics n8n is selling without giving up the controls they already had. For how Netics builds and operates automation end to end, see neticslabs.com.
Sources
The claims above come from Introducing n8n Agents (blog.n8n.io, September 25, 2026). The announcement links to n8n's Build and manage agents documentation for the full construction and management details.
Source: Introducing n8n Agents — blog.n8n.io, 2026-09-25.