/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. An explicit Agent request routes to agent-builder before ask-user.
  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.

• 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 `workflows(action="list")` 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 `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