n8n Agents: let AI choose the next step, and workflows define its execution

A set of connected tools for work across applications

n8n connects applications into workflows—prearranged steps that run automatically. It suits teams repeatedly organizing data, routing requests or updating business records. Builders traditionally defined the sequence on a canvas. Agents, introduced on September 25, 2026, adds an AI-assistant entry: describe the goal, choose a model and permitted tools, and let the Agent decide the next step from the situation.

For example, support receiving “my account has not been working well” may not yet know which service to investigate. Fixed workflows can reliably check accounts and contracts, but cannot anticipate every follow-up. The Agent can interpret the problem and ask questions before calling a configured lookup. The goal is a result consistent with business records, rather than merely a polished response.

Prepare the business actions before handing judgment to an Agent

Consider a customer complaint that requires investigation and an account note. The team first decides which reads and writes are allowed, then connects existing workflows as actions the Agent—an AI assistant—can call. Fixed workflows perform the operations; the Agent uses the conversation to decide what is needed next. The customer-support example in the Agents announcement wraps account notes in a workflow that receives an account and a note.

Create a draft from Agents, describe its responsibilities, choose a model and connect the required tools. Application credentials, permitted actions and approval conditions need configuration. Agents is still in preview. The building guide lists self-hosted version and environment requirements and says queue mode—putting tasks in a queue for separate processes to execute—is not supported yet. Self-hosted teams should check those requirements first.

Follow one request through judgment and execution

1. Understand the input. If a customer only says “my account does not work,” the Agent can ask for more detail before choosing a lookup tool.
2. Call a limited action. A workflow reads the account or writes a note through defined steps, returning a result for the next decision.
3. Intervene before sensitive actions. A tool requiring approval pauses until the user approves or rejects it. Assess the particular record and proposed change: connecting a customer-record system does not authorize arbitrary edits.
4. Inspect the conversation history. Check actual calls and results to confirm that the note reached the correct account, rather than judging only the fluency of the final reply.

The relationship also works in the other direction. A workflow can use Message an Agent to delegate a step that requires understanding, then handle its result. An uncertain judgment can fit into an existing business process without rebuilding the whole automation.

Move from draft preview to team use

Check several realistic tasks in the draft preview before publishing the configuration for connected channels or schedules. Later changes stay in the draft until reviewed and published. Restoring a configuration does not undo notifications already sent or records already written.

Agents and workflows share execution allowances, and continuing conversations have a running cost. Assess whether the task completed, tools operated within the intended scope and the team can explain what happens after failure. Flexibility is useful, but people still own business permissions and result checks.

Separate when to act from what the action does

In n8n's official support example, adding an account note is packaged as a workflow that accepts only an account and a note. The Agent decides whether a note is needed; the workflow performs the write through configured steps. The memorable relationship is that freedom can belong to the judgment layer without belonging to the whole system.

Imagine a colleague asking why a customer complained. The Agent can investigate, then decide whether to record a note. It receives a bounded action rather than a broad instruction to be careful when changing customer records. That gives a product designer a concrete control: make the tool's capabilities fit the task, instead of relying only on a better prompt. Defining those tools takes business knowledge; too narrow means repeated calls, while too broad weakens the boundary.

Put the intervention before the action

Sensitive tools can require approval. The Agent pauses before the call, and the user can approve or reject it. Compared with reading a report after everything has happened, this creates a moment to intervene before the effect. Escalating a support ticket, for example, interrupts an on-call colleague, so the decision should be understood through the people and content affected.

The useful part is not an extra click, but a decision the person can evaluate. If the destination and intended change are unclear, a pause can become automatic approval. The documented mechanism supplies an intervention point; the team still needs to configure the scope and meaning of the tools.

Keep work in progress separate from the serving version

Drafts and published versions are separate. Edits stay in a draft until it is previewed and published. Publishing fixes a configuration that others will use, instead of exposing every temporary edit to the team. Sessions also retain tool calls and results, making the actual sequence available for review.

If the team changes when a ticket should be escalated, it can try several inputs in the draft before replacing the active configuration. This preserves room to explore and an explicit moment of activation. Restoring configuration does not undo notifications already sent or records already written.