N8n Agents Official

n8n Agents

A first-class n8n Agent is a saved resource with its own instructions, model, tools, skills, sub-agents, memory, channels, scheduled tasks, versions, and spend limits. It is configured as JSON through the Agent MCP tools, never with Workflow SDK code. The AI Agent node inside a workflow is a different thing, covered by n8n-ai-nodes-official.

<!-- TEMPORARY: revisit when the Preview tag is removed from Agents in the UI, and when Agents are declared ready for Enterprise. -->

Agents are generally available. The UI shows a Preview tag because they change often and some features you might expect aren't there yet. They aren't ready for Enterprise yet: an Enterprise instance may have them enabled, but don't assume it. If create_agent isn't in your tool list, Agents aren't enabled on this instance. Say so and offer a workflow instead of guessing.

Non-negotiables

1. Always send a memory block when creating over MCP: "memory": { "enabled": true, "storage": "n8n" }. The UI adds it on every save. create_agent saves exactly what you send, and without it the Agent forgets the previous turn even inside one session (verified live).

2. Never publish without the user's explicit OK. A built Agent is a draft. Configuring a channel on an already published Agent connects it immediately, so confirm that too.

3. Publish what the Agent calls. Workflow tools need a When Executed by Another Workflow trigger, the same project, and a published workflow (validate_agent reports it). Saved sub-agents must be published too, and nothing checks that: validation and publishing pass, then production delegation fails and the parent quietly answers on its own.

4. Approval on anything that sends, changes, deletes, or spends, and know what the approver will see. See references/APPROVALS.md.

5. One mutate_agent per change, always with the latest configHash. A stale hash returns stale_config: call get_agent and retry.

Agent, workflow, or AI Agent node?

Decide before calling any build tool. The first question is the "say it out loud" test.

"Build me an agent" or "assistant" means a first-class Agent unless a limit applies. A Chat Trigger plus an AI Agent node is not a substitute for a requested Agent. If a request is really a fixed trigger plus fixed steps, explain the mismatch and ask before building a workflow instead.

Current limits that point to the AI Agent node

<!-- TEMPORARY: revisit when n8n adds custom approval messages for Agent tools. -->

<!-- TEMPORARY: revisit when channel approval cards (Slack, Telegram, Discord) show the tool's parameters. -->

<!-- TEMPORARY: revisit when Agent tools can read run context (trigger or upstream node data) in expressions. -->

<!-- TEMPORARY: revisit if n8n lets a workflow key into a native channel session (or the reverse). -->

MCP build sequence

1. get_agent_builder_reference once. Its configSchema is the source of truth for field names; trust it over this skill when they differ.

2. search_projects, then discover_agent_assets (models, integrations, workflows, subagents, mcpServers), list_credentials, and search_nodes with usage: "agentTool" + get_node_types for node tools.

3. create_agent with model, credential, instructions, memory block, and ordinary tools. Skills, tasks, and custom tools come after, through mutate_agent, because they need server-generated ids.

4. mutate_agent, one operation per call. skill.upsert doesn't change configHash; config patches do.

5. validate_agent until valid: true and missing is empty.

6. One representative call_agent. It runs the draft through Preview with real tools, so side effects happen: if any tool without approval sends, writes, or pays, ask the user before the test. Every returned approval goes to the human; resume each with its continuation.

7. Report the draft with the url from validate_agent, plus the session link (see references/SESSIONS_AND_DEBUGGING.md), and ask whether to publish.

8. publish_agent only on an explicit yes. Channels: update_agent_integration (references/CHANNELS.md).

Details on every operation, error code, and version tool: references/MCP_BUILD.md.

Where depth lives

For a chat bot built as a workflow shell (platforms without a native channel, slash commands, custom routing), the shell patterns live in n8n-ai-nodes-official references/CHAT_SURFACE_PATTERNS.md, section "Core as Message an Agent". Its one rule that can't wait: on surfaces that deliver the bot's own messages (Slack, Discord), a shell that posts replies must filter out the bot's user ID right after the trigger, or it triggers itself forever.

Writing instructions

Instructions are the system prompt. Same split as the node: persona, rules, output format, and inter-tool flow go in instructions; how to call a specific tool goes in that tool's description. Long procedures the Agent needs only sometimes belong in a skill, which costs tokens only when loaded. Say where to deliver results ("post the summary in #ops"), because a scheduled run has no one to reply to.

Anti-patterns