n8n-io/n8n/intent-recognition

Intent recognition

Purpose

Use this skill when an automation request still needs to be classified before designing or building it, or when a new turn may require reconsidering the current artifact. Do not load it again for a routine edit or extension when the conversation already targets a workflow or Agent, unless the user introduces an independent automation or the new request carries its own anchor signal. The deciding question is not a single "workflow or agent" label — it is two questions: who owns the top-level control flow, and does the other primitive show up inside that flow.

If the user asked to build, route on the result: workflow-builder for workflow-anchored (a bounded LLM step is an AI node in the graph; an embedded agent is an AI Agent step inside it), an agent-oriented design for agent-anchored (a tool-use loop), ask_user for needs-clarification, or answer directly for out-of-scope.

Inputs

• The user's request or scenario prompt.
• Whether the user is mid-build on an existing workflow or agent in this

conversation — incremental requests default to extending that primitive.

• Whether the editor/canvas context the conversation opened from shows an

existing agent or an existing workflow (or both). An existing agent in context that the user asks to change is an agent-anchored request — see Context continuity and Existing-agent modification.

• Any explicit constraints about determinism, auditability, latency, cost,

compliance, reusability, or allowed tools.

• If the user did not explicitly select an Agent and the request is

underspecified on an anchor-deciding axis, ask for the missing detail instead of guessing. An explicit Agent request already decides the anchor. Leave missing setup and implementation details to the Agent Builder.

Decisions

Two orthogonal decisions per request, or per part for compound requests:

1. Anchor — which primitive owns the top-level control flow:

• workflow-anchored: the outer shell is a workflow graph. May include LLM

steps as bounded transformers (classify, extract, summarize, score, a single decision feeding fixed branches).

• agent-anchored: an agent owns the flow; the LLM decides the next step

at runtime or owns an ongoing role that requires judgment. n8n Agents are not chat-only: besides chat sessions, they run recurring objectives on a cron schedule (tasks) and keep memory across sessions and runs — so recurring or scheduled duties do not disqualify this anchor.

• needs-clarification: the request is under-specified on an

anchor-deciding axis.

• out-of-scope: not a build intent at all. Covers meta or product

questions (e.g. asking what the assistant is capable of building) and one-off content tasks with no trigger, no persistence, and no reuse intent (summarize, translate, or draft something once) — answer or do these directly instead of building an automation. This bucket only applies when you can actually do the task directly: a one-off question or report that needs external systems you have no ad-hoc access to (a private issue tracker, wiki, or CRM) is not out-of-scope — classify it, and when answering requires judgment-driven navigation of those systems it is agent-anchored (see Signals). Requests to operate on existing resources (running or triggering a workflow the user already has, debugging a failed execution, listing or managing workflows or agents, querying data) are not classified by this skill at all — route them through their normal paths. Per the system prompt's "Existing Resources" section, check list_workflows before reading "trigger my X" as a build: a workflow's own name can contain a build verb ("X — Create"), and a link to a service you integrate with is an input value, not a request to build an integration for it. Finally, a one-off task with a concrete external effect (export/copy data somewhere once, a migration, a backfill) is workflow-anchored, not out-of-scope — the workflow is just the vehicle. Classify it by shape (bounded data already in hand, imperative ask, no trigger/schedule/reuse vocabulary) — users rarely say "one-off" explicitly. Load the one-off-operations skill before building and pass executionIntent: "one-off" to workflow_builder_build_workflow; the completion criterion is then a live run with read-back instead of simulated verification.

2. Embeds other — whether the other primitive appears inside the anchor:

• workflow-anchored + true: an agent embedded as a workflow step (e.g. a

scheduled pipeline whose middle step is open-ended investigation).

• agent-anchored + true: workflows invoked as tools of the agent; see Agent

tool shape to distinguish them from direct tools.

• n/a for needs-clarification and out-of-scope.

Migration from the old taxonomy: old hybrid → workflow-anchored, embeds_other: false. Old single AI task → out-of-scope when it is a one-off request (do the task directly); workflow-anchored with one LLM step only when the user wants a persistent, triggerable automation. Old ambiguous → needs-clarification. Old workflow and agent map directly onto the matching anchor value.

Agent tool shape

After choosing an agent-anchored design, decide whether each capability should be a direct agent tool or a workflow tool:

• Direct agent tools are the default. One node-backed capability or multiple

independent node tools stay on the Agent build path with embeds_other: false.

• Use a workflow tool only when one agent tool call must run an ordered

multi-node procedure, or when the user explicitly needs that workflow reusable, manually callable, or usable outside the agent. Build the workflow first, attach it to the Agent as a workflow tool, and set embeds_other: true.

Count the nodes required inside one tool invocation, not the total number of tools on the agent. For example, looking up and inserting Data Table rows are two direct node tools; an atomic lookup-transform-write procedure is one workflow tool.

After choosing an agent-anchored design, load agent-builder before the first agent_builder_* call. It owns targeting, prerequisite creation, and the Agent build.

Decision Steps

1. If the user is mid-build on an existing workflow or agent, apply context

continuity (see Signals) before anything else — an incremental request normally extends the current primitive.

1. Explicit artifact requests. "Build me an Agent/assistant that…" selects

an Agent artifact and decides the anchor. Do not ask the user to reconsider that choice during intent recognition. Do not silently substitute a workflow, even when it could implement the same behavior. You may explain a simpler workflow alternative, but switch only after the user chooses it. Route missing setup and implementation choices to Agent Builder. The immediate next routing action is to load agent-builder. Do not call ask_user between classification and that handoff. Forward the request without selecting services, tools, topics, schedules, or other implementation details. Agent Builder owns those questions. An explicit workflow request selects a workflow, unless it fits a row in Close pairs. Then the word "workflow" or named workflow nodes do not settle the choice: ask that row's question before you build either one. The false-friends rule applies to task descriptions, not to an explicit Agent request.

1. If the request is not a build intent — a meta or product question, or a

one-off content task with no trigger or reuse — classify out-of-scope and answer or do it directly.

1. Split the request into parts only if it contains multiple independent

automations with separate lifecycles (unrelated triggers, audiences, or cadences). Markers like numbering or "and separately" are a giveaway but are not required — a single plain sentence can contain two automations. Do not split a single automation that merely enumerates many tools or steps. Run steps 4-9 on each part.

1. Test the agent signals. If any one holds, classify agent-anchored.
2. Before selecting a workflow, verify that the request supplies or clearly

entails every workflow condition. Do not invent a fixed sequence, decision policy, or bounded LLM task from a generic outcome. If a missing anchor-defining detail could make the work judgment-driven, classify needs-clarification and ask only for that detail.

1. Otherwise, test the workflow conditions. If all of them hold, classify

workflow-anchored.

1. Decide embeds_other in both directions: does an agent step appear inside

this workflow, or does this agent invoke workflows as tools?

1. Degenerate-shell check. If a workflow-anchored design reduces to a

trigger plus a single open-ended agent step that does all the work — no deterministic steps earning the shell — the anchor is wrong: reclassify agent-anchored and build an n8n Agent (an on-demand duty becomes the agent's chat use; a scheduled duty becomes a task on the agent). Re-run this check while building: when fixed nodes prove unusable and the work migrates into one embedded agent step, stop and re-anchor instead of finishing the degenerate workflow.

1. If both anchors are genuinely defensible, apply the growth tiebreaker:

prefer whichever primitive scales with likely complexity growth — usually agent-anchored when novel situations, longer horizons, or learning are implied. The tiebreaker applies only to genuine ties: when a bounded workflow reading fully satisfies the request, prefer it. If it is a real toss-up, say so and name both readings instead of feigning certainty. The workflow preference applies to task-shaped requests; it never overrides an explicitly requested agent artifact (step 1).

Close pairs

Some artifacts look alike. Each row names a pair, the signal that a request fits both, and one question that tells them apart. When the user names one side and the signal fits the other side too, ask the row's question with ask_user, then build what the user picks. Do not build either side first. An explicit Agent request does not use this table (step 1). A new artifact type adds a row here.

Signals

Agent-anchored (any one is enough):