@n8n/instance-ai 1.16.2 → 1.17.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@n8n/instance-ai",
-  "version": "1.16.2",
+  "version": "1.17.0",
   "main": "dist/index.js",
   "module": "src/index.ts",
   "types": "dist/index.d.ts",
@@ -13,9 +13,9 @@
   ],
   "exports": {
     ".": {
+      "types": "./dist/index.d.ts",
       "require": "./dist/index.js",
-      "import": "./src/index.ts",
-      "types": "./dist/index.d.ts"
+      "import": "./dist/index.js"
     },
     "./parsers": {
       "require": "./dist/parsers/index.js",
@@ -53,16 +53,16 @@
     "source-map-support": "0.5.21",
     "turndown": "^7.2.2",
     "undici": "^7.28.0",
-    "xlsx": "https://cdn.sheetjs.com/xlsx-0.20.2/xlsx-0.20.2.tgz",
+    "@e965/xlsx": "0.20.3",
     "zod": "3.25.67",
     "zod-from-json-schema-v3": "npm:zod-from-json-schema@^0.0.5",
-    "@n8n/api-types": "1.31.2",
-    "@n8n/agents": "0.16.2",
-    "@n8n/ai-utilities": "0.24.2",
-    "@n8n/mcp-browser": "0.14.0",
-    "n8n-workflow": "2.31.2",
-    "@n8n/utils": "1.39.0",
-    "@n8n/workflow-sdk": "0.24.2"
+    "@n8n/agents": "0.17.0",
+    "@n8n/ai-utilities": "0.25.0",
+    "@n8n/mcp-browser": "0.15.0",
+    "@n8n/api-types": "1.32.0",
+    "n8n-workflow": "2.32.0",
+    "@n8n/workflow-sdk": "0.25.0",
+    "@n8n/utils": "1.40.0"
   },
   "devDependencies": {
     "@ai-sdk/anthropic": "^3.0.81",
@@ -77,7 +77,7 @@
     "vitest": "^4.1.9",
     "vitest-mock-extended": "^3.1.0",
     "@n8n/typescript-config": "1.9.0",
-    "@n8n/vitest-config": "1.18.0"
+    "@n8n/vitest-config": "1.19.0"
   },
   "license": "SEE LICENSE IN LICENSE.md",
   "homepage": "https://n8n.io",

package/skills/config-evals/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: config-evals
+description: >-
+  Builds and maintains configuration-based evaluations on a workflow with the
+  eval-config tool. Use when the user asks to set up, add, view, change, or
+  remove an evaluation, score, grade, or judge a workflow's output, or measure
+  answer quality against a test dataset. This is the only eval form Instance AI
+  handles — it does not touch on-canvas evaluation nodes.
+recommended_tools:
+  - eval-config
+  - data-tables
+platforms:
+  - daytona
+---
+
+# Config-based Evaluations
+
+Use this skill to attach a configuration-based evaluation to a workflow with the
+`eval-config` tool. A config eval pairs a workflow with a name, a start node, an
+end node, one or more judged metrics, and a Data Table dataset. Nothing is added
+to the canvas — the config lives off-canvas via the evaluation-config API.
+
+Config evals are the only evaluation form you work with. Do not add, read,
+rewire, or reason about on-canvas evaluation nodes (EvaluationTrigger,
+Evaluation/checkIfEvaluating/setOutputs/setMetrics). If the user asks for those,
+build a config eval instead and briefly say that is how you set up evaluations.
+
+## What a Config Eval Needs
+
+- `name` — a human-readable evaluation name.
+- `startNodeName` — the node where a run begins; it is fed one test-input row.
+- `endNodeName` — the node whose output is judged.
+- `dataTableId` — a Data Table holding the test dataset. Create and populate it
+  with the `data-tables` tool first, then link it here by id.
+- `metrics` — one or more judged metrics (see below).
+
+## Default Procedure
+
+1. Identify the target workflow and read it. Trace the main path from trigger to
+   the node that produces the answer.
+2. Pick the nodes:
+   - `startNodeName` is normally the node that receives the input the dataset
+     varies (often the trigger or the first node after it).
+   - `endNodeName` is the node whose output you want scored (usually the AI agent
+     or the final response node).
+3. Resolve the dataset. Call `data-tables(action="list")` to find an existing
+   dataset, or create and seed one with `data-tables` before creating the config.
+   Never invent a `dataTableId`; use one returned by `data-tables`.
+4. Choose metrics and build the `actualAnswer` / `expectedAnswer` / `userQuery`
+   expressions (see Metrics).
+5. Call `eval-config` (`action="create"`), or `update` when changing an existing
+   config. The tool shows an approval card automatically — call it and respect
+   the result; do not ask for chat approval first.
+6. Close with facts: evaluation name, workflow, start/end nodes, dataset name and
+   id, and the metrics configured.
+
+## Metrics
+
+Each metric is LLM-judged and needs a judge model: a `credentialId`, a `model`,
+and an `outputType` (`numeric`, the default, or `boolean`). Reuse an LLM
+credential the workflow already uses when one fits.
+
+Do **not** set `provider` unless you know the exact chat-model node type — it is
+derived automatically from the credential you pass (each credential type maps to
+one provider). Just pick the credential and the model.
+
+Two presets are available:
+
+- **`correctness`** — compares the produced answer to a ground-truth answer.
+  Requires `expectedAnswer` (an n8n expression resolving to the ground-truth
+  value, typically a dataset column, e.g. `{{ $json.expected_output }}`).
+- **`helpfulness`** — judges the produced answer against the user's query.
+  Requires `userQuery` (an n8n expression for the input the user asked, e.g.
+  `{{ $json.input }}`).
+
+Every metric also needs `actualAnswer`: an n8n expression resolving to the
+workflow's produced answer at the end node, e.g. `{{ $json.output }}`.
+
+Pick `correctness` when the dataset has a known right answer to compare against;
+pick `helpfulness` when there is no single ground truth and quality is judged
+relative to the request. Use `prompt` only to override the default judge prompt.
+
+## Dataset Boundary
+
+- Build the dataset with the `data-tables` tool: one column for each input the
+  evaluation varies, plus a ground-truth column when using `correctness`.
+- The config only references the dataset by `dataTableId`; the `eval-config` tool
+  does not create or populate rows. If no suitable dataset exists, create one
+  first, then create the config.
+- Do not weaken the evaluation to fit a thin dataset — seed the dataset to match
+  the metrics, or ask the user for the expected answers.
+
+## More Detail
+
+Use [references/config-eval-playbook.md](references/config-eval-playbook.md) for
+tool-call recipes, worked examples, and output shapes.

package/skills/config-evals/references/config-eval-playbook.md

@@ -0,0 +1,109 @@
+# Config Eval Playbook
+
+Recipes and worked examples for the `eval-config` tool. All actions are
+discriminated by `action` and always take a `workflowId`.
+
+## Actions
+
+| Action   | Purpose                                  | Extra fields |
+| -------- | ---------------------------------------- | ------------ |
+| `list`   | List config evals on a workflow          | — |
+| `get`    | Read one config eval                     | `configId` |
+| `create` | Attach a new config eval                 | config fields |
+| `update` | Replace an existing config eval          | `configId` + config fields |
+| `delete` | Remove a config eval                     | `configId` |
+
+Config fields (create/update): `name`, `startNodeName`, `endNodeName`,
+`dataTableId`, `metrics`.
+
+`create`, `update`, and `delete` show an approval card automatically. Call the
+tool and act on the result; do not ask for chat approval beforehand.
+
+## Metric Fields
+
+| Field          | Required                | Notes |
+| -------------- | ----------------------- | ----- |
+| `name`         | always                  | e.g. `"Correctness"` |
+| `preset`       | always                  | `correctness` or `helpfulness` |
+| `credentialId` | always                  | credential id for the judge model; also determines the provider |
+| `model`        | always                  | e.g. `gpt-4o` |
+| `outputType`   | defaults to `numeric`   | `numeric` or `boolean` |
+| `actualAnswer` | always                  | expression for the produced answer, e.g. `{{ $json.output }}` |
+| `expectedAnswer` | `correctness` preset  | expression for ground truth, e.g. `{{ $json.expected_output }}` |
+| `userQuery`    | `helpfulness` preset    | expression for the user's query, e.g. `{{ $json.input }}` |
+| `prompt`       | optional                | overrides the default judge prompt |
+| `provider`     | omit                    | chat-model node type; leave unset — derived from `credentialId`. Set only if you know it (e.g. `@n8n/n8n-nodes-langchain.lmChatOpenAi`) |
+
+## Worked Example — correctness eval on an agent workflow
+
+1. Ensure a dataset exists with an input column and a ground-truth column:
+
+   ```
+   data-tables(action="list")
+   // if none fits:
+   data-tables(action="create", name="Support agent eval dataset",
+     columns=[{ name: "input", type: "string" },
+              { name: "expected_output", type: "string" }])
+   // then seed rows with data-tables insert
+   ```
+
+2. Create the config eval, linking the dataset by id:
+
+   ```
+   eval-config(
+     action="create",
+     workflowId="<wf_id>",
+     name="Support agent correctness",
+     startNodeName="When chat message received",
+     endNodeName="AI Agent",
+     dataTableId="<dt_id>",
+     metrics=[{
+       name: "Correctness",
+       preset: "correctness",
+       credentialId: "<cred_id>",   // provider is derived from this credential
+       model: "gpt-4o",
+       actualAnswer: "{{ $json.output }}",
+       expectedAnswer: "{{ $json.expected_output }}"
+     }]
+   )
+   ```
+
+3. Report: evaluation name, workflow, start/end nodes, dataset name + id, metric.
+
+## Worked Example — helpfulness eval (no ground truth)
+
+Use `helpfulness` when there is no single correct answer. The dataset needs only
+the input column; no ground-truth column is required.
+
+```
+eval-config(
+  action="create",
+  workflowId="<wf_id>",
+  name="Assistant helpfulness",
+  startNodeName="When chat message received",
+  endNodeName="AI Agent",
+  dataTableId="<dt_id>",
+  metrics=[{
+    name: "Helpfulness",
+    preset: "helpfulness",
+    credentialId: "<cred_id>",   // provider is derived from this credential
+    model: "claude-sonnet-4-5",
+    userQuery: "{{ $json.input }}",
+    actualAnswer: "{{ $json.output }}"
+  }]
+)
+```
+
+## Changing or Removing
+
+- To change metrics, nodes, or the dataset, use `update` with the `configId` from
+  `list`/`get`. `update` replaces the full config — resend every field you want
+  to keep, not only the changed ones.
+- To read current state before editing, use `get` with the `configId`.
+- To remove an eval, use `delete` with the `configId`.
+
+## Boundary Reminder
+
+This tool never touches the canvas. Do not add EvaluationTrigger or Evaluation
+nodes; config evals are attached through the evaluation-config API only. Build
+and seed datasets exclusively through the `data-tables` tool.

package/skills/intent-recognition/SKILL.md

@@ -8,8 +8,10 @@ description: >-
   workflow invoked as an agent tool). Must be used before deciding the intent
   of any automation request, including compound requests with multiple
   independent automations, mid-build extensions to an existing workflow or
-  agent, and requests that need clarification before an anchor can be chosen,
-  before choosing workflow-builder, planning, or an agent-oriented design.
+  agent, one-off questions or reports that need external systems you cannot
+  query directly, and requests that need clarification before an anchor can
+  be chosen, before choosing workflow-builder, planning, or an agent-oriented
+  design.
 ---
 
 # Intent recognition
@@ -27,9 +29,8 @@ 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; build reusable actions as workflows the
-agent invokes), `ask-user` for needs-clarification, or answer directly for
-out-of-scope.
+agent-anchored (a tool-use loop), `ask-user` for needs-clarification, or answer
+directly for out-of-scope.
 
 ## Inputs
 
@@ -51,25 +52,32 @@ Two orthogonal decisions per request, or per part for compound requests:
   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.
+  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. Requests to operate on
-  existing resources (debugging a failed execution, listing or managing
-  workflows, querying data) are not classified by this skill at all — route
-  them through their normal paths.
+  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 —
-  especially when the user wants reusable or manually-triggerable actions, or
-  an action is itself a deterministic multi-step procedure.
+- agent-anchored + `true`: workflows invoked as tools of the agent; see Adding
+  tools to an agent to distinguish them from direct tools.
 - `n/a` for needs-clarification and out-of-scope.
 
 **Migration from the old taxonomy**: old **hybrid** → workflow-anchored,
@@ -79,47 +87,97 @@ only when the user wants a persistent, triggerable automation. Old
 **ambiguous** → needs-clarification. Old **workflow** and **agent** map
 directly onto the matching anchor value.
 
+## Adding tools to an agent
+
+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.** Forward requests to add capabilities
+  to `build-agent` near-verbatim so the delegated builder can choose MCP,
+  node-backed, provider, or custom tools. 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.
+
 ## 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. If the request is not a build intent — a meta or product question, or a
+1. **Explicit artifact requests.** When the user names the deliverable —
+   "build me an agent/assistant that…", "create a workflow that…" — the
+   named primitive is a routing instruction, not surface vocabulary.
+   Classify by it unless the described behavior is unambiguously the other
+   primitive's shape (e.g. "an agent" whose behavior is a fixed
+   schedule-fetch-notify pipeline). Even then, never switch silently:
+   propose the reclassified design and say you are deviating from the named
+   primitive, grounding the choice in the task's shape. The false-friends
+   rule applies to task descriptions, not to an explicitly requested
+   artifact.
+2. 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.
-2. Split the request into parts only if it contains multiple independent
+3. 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 3-7 on each part.
-3. Test the agent signals. If any one holds, classify **agent-anchored**.
-4. Otherwise, test the workflow conditions. If all of them hold, classify
+   steps. Run steps 4-9 on each part.
+4. Test the agent signals. If any one holds, classify **agent-anchored**.
+5. Otherwise, test the workflow conditions. If all of them hold, classify
    **workflow-anchored**.
-5. Decide `embeds_other` in both directions: does an agent step appear inside
+6. Decide `embeds_other` in both directions: does an agent step appear inside
    this workflow, or does this agent invoke workflows as tools?
-6. If the request is under-specified on an anchor-deciding axis (rule-based
+7. **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.
+8. If the request is under-specified on an anchor-deciding axis (rule-based
    vs judgment-based, scope/autonomy, interaction mode), classify
    **needs-clarification** and name the missing axis instead of guessing.
-7. If both anchors are genuinely defensible, apply the growth tiebreaker:
+9. 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).
 
 ## Signals
 
 **Agent-anchored** (any one is enough):
 
 - Reasoning dominates the flow: investigate, decide, act, iterate.
+- On-demand question or report that requires judgment-driven navigation of
+  external systems (which items matter, how they map to goals) and cannot be
+  answered directly with your own tools — the user is in effect already
+  chatting with the automation they need. The artifact is an agent with those
+  tools that can be asked again anytime, not a manually triggered workflow.
 - Multi-session or long-running: coordination across days, tracked open
   threads, daily check-ins.
-- Proactive or heartbeat-driven: wakes on its own, checks state, decides
-  whether to intervene.
+- Proactive or recurring on its own: wakes on a heartbeat or a scheduled
+  task, checks state, and decides what to do about it each run. The judgment
+  per run is the signal, not the cadence — a schedule alone is anchor-neutral
+  (see Scheduled judgment work).
 - Self-improving or skill accretion is first-class: learns from feedback
   over time, gets better at the task.
-- Chat or session-based interaction.
+- Chat or session-based interaction. A workflow with a Chat Trigger is not
+  a substitute — this signal holds unless the chat merely triggers a fixed
+  pipeline (see Gotchas).
 - Cross-session memory.
 
 **Workflow-anchored** (all must hold):
@@ -127,10 +185,23 @@ directly onto the matching anchor value.
 - Structure is a graph of enumerable steps.
 - Any LLM use is a bounded transformer: fixed-label classify, extract,
   summarize, or a single decision.
-- Trigger and actions are deterministic.
+- Trigger and actions are deterministic. A cron schedule satisfies this but
+  never decides the anchor by itself — agents run scheduled tasks too; what
+  must be deterministic is the body of each run.
 - Reproducibility or auditability is served by the same graph running every
   time.
 
+**Scheduled judgment work** (recurring cadence + open-ended body): both
+primitives can own it — a workflow shell with an embedded agent step, or an
+agent with a scheduled task. Default to the workflow shell for a standalone,
+single-duty job: a deterministic trigger and delivery around one open-ended
+step keeps auditability and avoids unnecessary agency. Choose an agent with a
+task instead when the duty belongs to an agent the user also interacts with
+or that has other duties, when it needs memory across runs (tracking open
+threads, "what did I flag last time"), or when the user explicitly asked for
+an agent. A recurring duty added to an agent mid-build is always a task on
+that agent, never a spawned workflow.
+
 **Embeds-other signals**:
 
 - Workflow with an embedded agent: a step in an otherwise fixed pipeline is
@@ -143,14 +214,14 @@ directly onto the matching anchor value.
   that drafts a tailored renewal pitch for each account from its usage
   history embeds an agent; a nightly job that condenses each ticket into a
   two-sentence summary does not.
-- Agent with workflow tools: the user asks for actions that should also be
-  reusable, callable manually, or run outside the agent; or an action the
-  agent invokes is itself a deterministic multi-step procedure.
+- For an agent with workflow tools, apply Adding tools to an agent.
 
 **Context continuity** (step 0): inside a workflow build, a request to insert
 a scoring step stays a bounded LLM step, not a new agent. Inside an agent
 build, a request to post an update on completion is a new tool on that
-agent, not a spawned workflow. Only cross into the other primitive when the
+agent, not a spawned workflow — and a recurring duty ("also send me a Monday
+summary") is a scheduled task on that agent, not a new scheduled workflow.
+Only cross into the other primitive when the
 incremental request itself carries its own anchor signal — and even then,
 prefer asking before switching paradigm if it isn't clearly load-bearing.
 
@@ -162,8 +233,10 @@ instead.
 
 **False friends — not signals**:
 
-- Surface vocabulary: "agent", "assistant", "bot", "workflow", "automate" in
-  the request text carry no weight. Classify the shape, not the words.
+- Surface vocabulary: "agent", "assistant", "bot", "workflow", "automate"
+  in a *task description* carry no weight — classify the shape, not the
+  words. An explicit artifact request ("build me an agent that…") is not a
+  false friend; see Decision Step 1.
 - Step count and tool count: long linear pipelines and high tool counts are
   not agentic. Seven deterministic steps with zero branches is still a
   workflow.
@@ -204,11 +277,22 @@ instead.
   `embeds_other: true`: long-running coordination invoking a workflow tool.
 - "Configure an AI agent to send me a nightly digest of new GitHub stars."
   -> **workflow-anchored**, `embeds_other: false`: fixed schedule and action
-  despite the word "agent" — a false friend.
+  despite the word "agent" — a false friend. When the user instead
+  explicitly asks to *build an agent* around a fixed pipeline like this,
+  keep the workflow classification but say so rather than switching
+  silently (step 1).
 - "Spin up a lightweight workflow that talks to shoppers on our storefront
   and handles their product questions." -> **agent-anchored**: chat-based
   Q&A means the LLM owns turn-by-turn control despite the word "workflow" —
   a false friend in the other direction.
+- "Build me an agent that answers customer questions from our docs." ->
+  **agent-anchored**, `embeds_other: false`: explicit agent artifact
+  request plus chat-shaped open-ended Q&A. The deliverable is an n8n Agent
+  — not a workflow with a Chat Trigger and an AI Agent node.
+- "Give me a chat box where I paste a company name and it runs our
+  enrichment steps and replies with the result." -> **workflow-anchored**,
+  `embeds_other: false`: chat is merely the manual trigger for a fixed
+  graph — the one case where a Chat Trigger workflow is the right build.
 - "Post every new Airtable record to a Discord channel, and separately set up
   an agent that handles customer refund requests end-to-end." -> two parts,
   joined only by topic, not data or trigger: "Airtable-to-Discord posting"
@@ -224,6 +308,14 @@ instead.
   deck that summarizes the findings." -> one part, **agent-anchored**,
   `embeds_other: true`: many tools but one lifecycle — do not split on tool
   count.
+- "Tell me how the platform team is progressing against their cycle goals —
+  current status is in our issue tracker, the goals are on our internal
+  wiki." -> **agent-anchored**, `embeds_other: false`: an on-demand judgment
+  report over external systems you cannot query directly. The artifact is an
+  agent with tracker and wiki tools the user can ask again anytime — not a
+  manual-trigger workflow whose only real step is an embedded agent with
+  those same tools. If the user later wants it every Friday, that becomes a
+  scheduled task on the same agent, not a conversion to a workflow.
 - "Tell me when something important happens with our shipments." ->
   **needs-clarification**: "important" is undefined; ask whether concrete
   rules exist or this needs judgment-based triage.
@@ -242,7 +334,26 @@ instead.
 - Never split a compound request on tool or step enumeration alone — split
   only on separate lifecycles.
 - Unnecessary agency adds latency, cost, and compounding error risk — do not
-  reach for an agent when a bounded workflow fully satisfies the request.
+  reach for an agent when a bounded workflow fully satisfies a task-shaped
+  request. This is not a license to override an explicit agent request.
+- Never satisfy an **agent-anchored** classification with a workflow
+  containing a Chat Trigger + AI Agent node. Agent-anchored requests
+  produce an n8n Agent artifact via the agent build path; the AI Agent
+  *node* exists only for `embeds_other: true` steps inside a genuinely
+  workflow-anchored pipeline. A Chat Trigger workflow is correct only when
+  chat is merely the manual trigger for a fixed graph.
+- Do not demote an explicitly requested agent to an embedded AI Agent step
+  inside a workflow — workflow-anchored with `embeds_other: true` is for
+  agent steps inside a pipeline the user described as a pipeline.
+- A workflow whose only real step is one embedded agent doing all the work
+  is an agent wearing a workflow costume — the mirror image of the Chat
+  Trigger gotcha above. Apply the degenerate-shell check (step 7) and
+  re-anchor instead of shipping trigger + AI Agent node.
+- Do not treat a cron schedule as a workflow signal by itself — agents run
+  scheduled tasks. Classify by the body of each run, and when a one-off
+  question can't be answered directly, do not fall back to "build a workflow
+  or do it yourself": an agent with the right tools is usually the missing
+  option.
 - Do not use an agent when progress cannot be verified: if the path cannot
   be scripted and the result cannot be checked, the design is not ready.
 - Respect the current build context: an incremental request stays on the
@@ -258,7 +369,7 @@ Return a concise classification and reason:
 Anchor: workflow-anchored | agent-anchored | needs-clarification | out-of-scope
 Embeds other: true | false | n/a
 Reason: <one or two sentences citing the deciding signals>
-Next step: <build workflow / build workflow with embedded agent step / design agent (workflows as tools where actions should be reusable) / ask clarification / answer directly>
+Next step: <build workflow / build workflow with embedded agent step / build n8n Agent artifact (agent build path; recurring duties as scheduled tasks on the agent) / ask clarification / answer directly>
 ```
 
 For build requests, do not expose this format unless the user asks for