n8n launches Agents: goal-driven automation callable from Slack, schedules and workflows

On September 25, 2026, n8n announced Agents, a feature that lets users of the workflow automation platform describe a goal rather than map out every step. According to a dev.to write-up of the announcement, which was published on the n8n blog by Ophir Prusak, each agent gets a model, a set of instructions and a toolbox of integrations and workflows, and works out the sequence of actions on its own.

What changed

For most of n8n's history, building an automation meant deciding the steps in advance and arranging them on the canvas. That model still fits deterministic jobs such as enriching, scoring and routing an incoming lead. The new feature targets a different class of task: investigations where each action depends on the result of the previous one. The example in the announcement is a colleague asking in Slack why a customer's usage dropped. Answering might require pulling the account, narrowing down the product line and checking support history, in an order nobody can lay out beforehand.

One agent, several entry points

A published agent is not tied to a single surface. It can be messaged from Slack, Telegram, Linear or Discord, triggered on a schedule, or invoked from any workflow, and editing its instructions once pushes the new version to every place it is connected. Under the hood, an agent bundles a model, instructions, channels and triggers, plus tools at three levels: MCP servers, n8n integrations restricted to a single action, and whole existing workflows. Skills, sub-agents, knowledge files, memory and sessions are also part of the package, with versions and approvals included. Sessions are stored, reviewable and resumable.

Two directions of control

Both arrangements are supported, per the dev.to report. The Message an Agent node lets a workflow call an agent as one step inside it and use the reply. The Agents tab inverts the relationship: the agent is in charge, and existing workflows become its tools.

That inversion carries the launch's most consequential design decision. Because each tool runs with its own credential, an agent's reach is defined by what its callable workflows are permitted to do, not by the wording of its instructions. The announcement's worked example is a support agent with three workflow tools: one reads account context, one writes a note to the account, one alerts the on-call engineer. Routing the note through a dedicated workflow means the agent never holds the CRM credential itself, and sensitive tools can be configured to pause for human approval.

Metering, logging and availability

Observability ships by default. Every session records each step the agent took, which tools it called, and the inputs and outputs of those calls, giving teams an audit trail without extra setup. Cost follows existing execution metering: a single turn with an agent counts as one execution, and calls made from workflows or sub-agents share that quota rather than adding to it. Separately, building an agent with n8n Assistant consumes AI credits, a build-time expense. The feature remains in preview. It is available on n8n Cloud for accounts on the latest stable version, on self-hosted instances with some additional setup, and on Enterprise plans only in the near future. The older AI Agent node is unchanged and continues to work as it always has.

Why it matters

The launch reframes what an automation platform sells. Where n8n's contract used to be about defining a process, it now also covers describing an outcome, and the operational burden shifts accordingly, from designing steps to reviewing the paths an agent actually took. Two details make that review tractable: session logs that exist from day one rather than as an add-on, and a turn counter that turns agent usage into a budgetable unit before the invoice arrives.

The permission model is the bigger idea. Anchoring an agent's reach to the credentials of its tool workflows, rather than to natural-language instructions, gives operators an enforceable boundary before an agent touches a production system. For teams already running deterministic n8n workflows nothing breaks; the new primitive sits alongside the old one, and choosing between them becomes as much a governance decision as an architectural one.