n8n System Prompt: A Template for Clear Agent Instructions

An n8n AI agent node uses a system prompt to set the rules for how the agent behaves: which tools it can use, what to do when it is missing information, and when to stop and ask a person instead of guessing. Without a clear system prompt, the agent makes those choices on its own, usually in ways that cause problems downstream.

The system prompt is not the same as the workflow logic. The workflow connects inputs, tools and outputs. The system prompt tells the agent how to make decisions within that structure. A tool like fenbs keeps the reviewed version of the prompt and the human decisions behind each rule, so the reasoning is available when the workflow needs to be updated.

What belongs in an n8n system prompt

Five things belong in almost every n8n agent system prompt:

• Role and purpose: what the agent is for and what it is not for.
• Tool boundaries: which tools it can use, in what order, and what it should never do with them.
• Missing input behavior: what to do when required information is absent.
• Output format: the exact structure the agent must return.
• Human handoff conditions: when the agent must stop and ask a person.

Keep the system prompt focused on these five areas. Do not put workflow logic, API credentials, or data processing rules in the system prompt. Those belong in the workflow nodes, not in the agent's instructions.

The template

You are [agent name], a workflow assistant for [workflow purpose].

ROLE
Your job is to [specific task]. You do not [out-of-scope task].

TOOLS
You have access to: [list tools by name].
Use [tool A] only for [purpose]. Do not use [tool B] to [prohibited action].
Call tools one at a time. Do not assume a previous tool succeeded without checking its output.

MISSING INFORMATION
If a required input is missing, list the missing fields and stop.
Do not guess, infer, or substitute a default value unless the field description says you may.

OUTPUT
Return a JSON object with the following fields: [field list].
Do not include extra fields. Do not add explanation outside the JSON.

HUMAN APPROVAL
Stop and return status "needs_review" with a reason if:
- [condition 1, e.g., the amount exceeds $500]
- [condition 2, e.g., the action cannot be undone]
- [condition 3, e.g., the data does not match expected format]

Define tool boundaries

Tool boundaries are the most important part of an agent system prompt. Without them, the agent may call a tool for a purpose it was not designed for, call tools in the wrong order, or use a write tool when you intended a read-only operation.

For each tool, write one sentence on what it is for and one sentence on what not to do with it. If the tools have an intended sequence, say the sequence explicitly: "Call the lookup tool first. Only call the write tool if the lookup returns a result."

For more on building secure agent prompts, see indirect prompt injection — a real risk when agents process external data that could contain instructions.

Handle missing or ambiguous inputs

A common failure mode: the agent receives a record with a missing field and fills in a value from context or training data. The workflow proceeds with invented data. By the time a person notices, the error has propagated.

Write the missing-input rule as an explicit stop condition: "If [required field] is empty or null, return status 'incomplete' and list the missing fields. Do not proceed." This makes the agent fail loudly and early rather than silently and late.

Set human-approval checkpoints

Agents that take irreversible actions — sending emails, writing to a database, posting to an external service — need explicit checkpoints where a person approves before the action runs. Define these conditions in the system prompt as stop conditions, not as workflow logic.

A workflow can route on the agent's output status. If the agent returns needs_review, the workflow pauses and sends the record to a review queue. If it returns ready, the workflow continues. This puts the approval logic in one place — the system prompt — rather than spread across multiple workflow branches.

Test and iterate the prompt

After writing the first version of your system prompt, run the workflow with test inputs that cover the cases you care about most. Use inputs that are complete and correct, inputs with missing fields, inputs that are ambiguous, and at least one that is out of scope. Check that the agent handles each according to the rules in the prompt.

When the agent breaks a rule, read the rule again before assuming it is a model error. Most prompt failures come from a rule that is ambiguous rather than a model that ignores clear instructions. Rewrite the rule to describe an observable behavior, add an example, or split it into two rules that do not conflict.

Keep a short log of your test inputs and what the agent returned. When you change the prompt, run the same test inputs again. If a fix for one case breaks another, you need to know that before the workflow is in production. For n8n workflows that call external APIs or write data, a small change in the system prompt can have large downstream effects.

How to do this with fenbs

1. Create a free account and add a project for your n8n workflow.
2. Save the current system prompt as a Skill in fenbs, with notes on the workflow it supports and the date it was last tested.
3. Record each boundary decision — what the agent may or may not do and why — as a Decision and rules entry in the project.
4. When the workflow is updated, update the Skill and add a note explaining what changed and what prompted the change.
5. Connect a supported AI assistant to fenbs over Integrations so it can read the prompt and the decisions before helping you debug or extend the workflow.

For more on n8n and AI: n8n MCP covers connecting n8n to MCP tools, and n8n AI agent goes deeper on agent node setup. For prompt patterns more broadly, see system prompt examples and prompt engineering.