fix(core): Reduce planner workflow bias and fix data-table task routing (no-changelog)

packages/@n8n/instance-ai/src/agent/system-prompt.ts

@@ -170,7 +170,7 @@ You have access to workflow, execution, and credential tools plus a specialized
 
 2. **Multi-step work** (2+ tasks with dependencies — e.g. data table setup + multiple workflows, or parallel builds + consolidation): call \`plan\` immediately — do NOT ask the user questions first. The planner sub-agent discovers credentials, data tables, and best practices, and will ask the user targeted questions itself if needed — it has far better context about what to ask than you do. Only pass \`guidance\` when the conversation is ambiguous about which approach to take — one sentence, not a rewrite. When \`plan\` returns, tasks are already dispatched. Never use \`create-tasks\` for initial planning.
 
-3. **Replanning after failure** (\`<planned-task-follow-up type="replan">\` arrived): call \`create-tasks\` directly — you already have the task context from the failed plan and do not need discovery again.
+3. **Replanning after failure** (\`<planned-task-follow-up type="replan">\` arrived): inspect the failure details and remaining work. If only one simple task remains (e.g. a single data table operation or credential setup), handle it directly with the appropriate tool (\`manage-data-tables-with-agent\`, \`delegate\`, \`build-workflow-with-agent\`). Only call \`create-tasks\` when multiple tasks with dependencies still need scheduling.
 
 Use \`update-tasks\` only for lightweight visible checklists that do not need scheduler-driven execution.
 
@@ -278,7 +278,7 @@ When \`<running-tasks>\` context is present, use it only to reference active tas
 
 When \`<planned-task-follow-up type="synthesize">\` is present, all planned tasks completed successfully. Read the task outcomes and write the final user-facing completion message. Do not create another plan.
 
-When \`<planned-task-follow-up type="replan">\` is present, a planned task failed. Inspect the failure details and either call \`create-tasks\` with a revised remaining task list, or explain the blocker to the user if replanning is not appropriate.
+When \`<planned-task-follow-up type="replan">\` is present, a planned task failed. Inspect the failure details and the remaining work. If only one task remains, handle it directly with the appropriate tool rather than creating a new plan. Only call \`create-tasks\` when multiple dependent tasks still need scheduling. If replanning is not appropriate, explain the blocker to the user.
 
 If the user sends a correction while a build is running, call \`correct-background-task\` with the task ID and correction.
 

packages/@n8n/instance-ai/src/tools/best-practices/guides/data-persistence.ts

@@ -190,5 +190,16 @@ Data Tables and other storage nodes return 0 items when:
 - A filter/lookup query matches nothing
 
 This silently breaks the downstream chain — all nodes after the empty result are skipped. Always set \`alwaysOutputData: true\` on data-fetching nodes (operation: 'get') when downstream nodes depend on their output.
+
+## Standalone Data Table Operations
+
+Data tables are not only storage for workflows — they can also be managed as standalone resources:
+
+- **Table creation and schema design**: Create tables with specific columns for data organization, even without an associated workflow.
+- **Seed data**: Populate tables with initial or sample data as a standalone operation.
+- **Schema management**: Add, rename, or remove columns on existing tables.
+- **Data cleanup**: Delete rows or entire tables that are no longer needed.
+
+When the user's request is purely about table CRUD (creating tables, inserting rows, modifying schemas, deleting tables) with no automation triggers or schedules, these should be handled as direct data table operations — not wrapped in a workflow.
 `;
 }

packages/@n8n/instance-ai/src/tools/orchestration/add-plan-item.tool.ts

@@ -64,7 +64,7 @@ export function createAddPlanItemTool(
 		description:
 			'Add a single plan item (data table, workflow, research, or delegate task). ' +
 			'Call once per item as you design it — each call makes the item visible to the user immediately. ' +
-			'Emit data tables FIRST, then workflows that depend on them. ' +
+			'Emit data tables FIRST. Add workflow items only if the request requires automation. ' +
 			'Set summary and assumptions on your first call.',
 		inputSchema: addPlanItemInputSchema,
 		outputSchema: z.object({ result: z.string() }),

packages/@n8n/instance-ai/src/tools/orchestration/blueprint-accumulator.ts

@@ -45,17 +45,27 @@ type BlueprintItem =
 
 /** Format a data table schema as a compact string for builder context. */
 export function formatTableSchema(dt: BlueprintDataTableItem): string {
+	if (!dt.columns || dt.columns.length === 0) return `Table '${dt.name}'`;
 	const cols = dt.columns.map((c) => `${c.name} (${c.type})`).join(', ');
 	return `Table '${dt.name}': ${cols}`;
 }
 
 function dataTableItemToTask(dt: BlueprintDataTableItem): PlannedTaskInput {
-	const columnList = dt.columns.map((c) => `${c.name} (${c.type})`).join(', ');
+	if (dt.columns && dt.columns.length > 0) {
+		const columnList = dt.columns.map((c) => `${c.name} (${c.type})`).join(', ');
+		return {
+			id: dt.id,
+			title: `Create '${dt.name}' data table`,
+			kind: 'manage-data-tables',
+			spec: `Create a data table named '${dt.name}'. Purpose: ${dt.purpose}\nColumns: ${columnList}`,
+			deps: dt.dependsOn,
+		};
+	}
 	return {
 		id: dt.id,
-		title: `Create '${dt.name}' data table`,
+		title: dt.name,
 		kind: 'manage-data-tables',
-		spec: `Create a data table named '${dt.name}'. Purpose: ${dt.purpose}\nColumns: ${columnList}`,
+		spec: dt.purpose,
 		deps: dt.dependsOn,
 	};
 }

packages/@n8n/instance-ai/src/tools/orchestration/blueprint.schema.ts

@@ -25,16 +25,17 @@ export const blueprintWorkflowItemSchema = z.object({
 
 export const blueprintDataTableItemSchema = z.object({
 	id: z.string().describe('Stable ID — preserved as task ID'),
-	name: z.string().describe('Table name'),
-	purpose: z.string().describe('1 sentence: what this table stores'),
+	name: z.string().describe('Table name or short task label'),
+	purpose: z.string().describe('What to do: create with schema, delete, modify, or seed data'),
 	columns: z
 		.array(
 			z.object({
 				name: z.string(),
 				type: z.enum(['string', 'number', 'boolean', 'date']),
 			}),
 		)
-		.describe('Column definitions — name and type only'),
+		.optional()
+		.describe('Column definitions for table creation — omit for delete/modify operations'),
 	dependsOn: z.array(z.string()).default([]),
 });
 

packages/@n8n/instance-ai/src/tools/orchestration/data-table-agent.prompt.ts

@@ -29,4 +29,12 @@ Do NOT produce visible output until the final summary. All reasoning happens int
 ## Destructive Operations
 
 \`delete-data-table\` and \`delete-data-table-rows\` will trigger a confirmation prompt to the user. The user must approve before the action executes. Do not ask the user to confirm via text — the tool handles it.
+
+## Seed Data
+
+When the task spec includes sample or seed rows to insert, create the table first, then insert the rows using \`insert-data-table-rows\`. Match column names exactly to the schema you just created.
+
+## Scope
+
+Only perform the operations explicitly assigned to you. Your task spec describes exactly what to create, modify, or delete — do nothing beyond that. If the spec mentions context about what other tasks will do (e.g. subsequent steps in a larger plan), ignore those — they are handled separately.
 `;

packages/@n8n/instance-ai/src/tools/orchestration/plan-agent-prompt.ts

@@ -24,10 +24,10 @@ You receive the recent conversation between the user and the orchestrator. Read
    - Skip searches for nodes you already know exist (webhooks, schedule triggers, data tables, code, set, filter, etc.)
 
 3. **Build incrementally** — call \`add-plan-item\` for each item:
-   - Emit data tables FIRST, then workflows that depend on them
+   - Emit data tables FIRST. If the request also requires automation, add workflow items that depend on them. A plan may consist entirely of data-table items.
    - Set \`summary\` and \`assumptions\` on your first call
    - Each call makes the item visible to the user immediately
-   - \`purpose\`: Write a rich, user-focused description of what the workflow does and why. Include key requirements and behaviors from the user's request. 3-5 sentences. Do NOT include node names, parameters, or implementation details — the builder handles that.
+   - \`purpose\`: Write a rich, user-focused description of what this item delivers and why. Include key requirements and behaviors from the user's request. 3-5 sentences. Do NOT include node names, parameters, or implementation details — the builder handles that.
    - \`triggerDescription\`: a few words (e.g. "Webhook POST", "Schedule daily")
    - \`dependsOn\`: **CRITICAL** — set dependencies correctly. Data tables before workflows that use them. Workflows that produce data before workflows that consume it. Independent workflows should NOT depend on each other.
    - \`columns\`: name and type only — no descriptions
@@ -45,5 +45,9 @@ You receive the recent conversation between the user and the orchestrator. Read
 - **Always call \`submit-plan\` after your last \`add-plan-item\`.** Never end without submitting.
 - **On rejection, be surgical.** Only change what the user asked for. Do NOT re-add items that are already correct.
 - **Dependencies are mandatory.** Every workflow MUST list the data table IDs it reads from or writes to in \`dependsOn\`. If workflow C needs data produced by workflows A and B, it must depend on A and B.
-- **No duplicate items.** Each piece of work appears exactly once. Use \`workflow\` kind for workflows, \`data-table\` kind for tables. Only use \`delegate\` kind for tasks that don't fit the other categories.
+- **No duplicate items.** Each piece of work appears exactly once. Use \`workflow\` kind for workflows, \`data-table\` kind for ALL data table operations (create, delete, modify, seed). Only use \`delegate\` kind for tasks that don't fit the other categories — never use \`delegate\` for data table operations.
+- **Data-table-only plans are valid.** If the request is purely about creating, populating, modifying, or deleting data tables — with no automation triggers, schedules, or integrations — use only \`data-table\` kind items. Do NOT wrap table operations in a \`workflow\` or \`delegate\` item.
+- **\`data-table\` kind supports any table operation.** For creation, include \`columns\`. For deletion, modification, or other operations, omit \`columns\` and describe the operation in \`purpose\`.
+- **Include seed data instructions in the \`purpose\` field.** When the user wants sample or initial rows, describe them in the data table item's \`purpose\` (e.g. "Seed with 3 rows: ..."). The data-table agent handles insertion.
+- **Each item's \`purpose\` must only describe what THAT item does.** Do not reference actions handled by other plan items. Each task is executed by an independent agent that only sees its own spec — cross-task context causes agents to perform work outside their scope.
 - Never fabricate node names — if unsure whether a node exists, search first.`;