/intent-recognition

name: intent-recognition
description: >-
  Classifies automation requests using two decisions: anchor (which primitive
  owns the top-level control flow — workflow-anchored, agent-anchored,
  needs-clarification, or out-of-scope) and embeds_other (whether the other
  primitive appears embedded inside — an agent step inside a workflow, or a
  workflow invoked as an agent tool). Must be used whenever the current turn
  requires choosing or reconsidering the intent of an automation request,
  including compound requests, independent automations introduced mid-build,
  one-off questions or reports that need external systems you cannot query
  directly, and requests that need clarification before an anchor can be
  chosen. Do not load for routine edits or extensions when the conversation
  already targets a workflow or Agent.

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.

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

compliance, reusability, or allowed tools.

• If the request is underspecified on an anchor-deciding axis, ask for the

missing detail instead of guessing.

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. 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 (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.

**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, pass it to `build-agent` via `workflowContext`, 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 calling `build-agent`. It owns prerequisite creation and the handoff to the delegated builder.

Decision Steps

0. 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.** When the user names the deliverable — "build me an agent