Skip to main content

Agent: The Custom Prompt

The agent's assigned prompt (from the snapshot) is its instruction — the standing job the operator gave it. But an instruction needs something to act on. That's the custom prompt: the runtime input you supply on the Agent node, in its input field.

Instruction vs. input​

Keep these two clearly separate, because they come from different owners:

  • The assigned prompt — "You are a reporter for The Hedgerow Herald; write a warm garden news report from the operator's briefing…" — is the operator's instruction, fixed for every run.
  • The custom prompt — the specific briefing, "the wrens who moved into the old watering can" — is the input for this run, and it's what you wire in.

In the employees framing: the assigned prompt is the job description; the custom prompt is today's specific assignment. The reporter always writes garden news (the prompt); what they write about changes each time (the input).

Where the input comes from​

The input field supports n8n expressions, so you feed it from wherever the work item lives — most often the workspace snapshot (the plugin's domain content, like a Thing's title and description), or the output of a previous node in your workflow. It can also be static text while you're testing. The node sends the assigned prompt and your input as separate messages to the model — the prompt as the instruction, the input as the thing to work on — so you don't need {placeholder} templating in the prompt; you just supply the input alongside it.

Why the split matters​

This separation is what lets one agent handle endlessly many jobs without the operator rewriting anything. The prompt stays put; you vary the input per run. It also keeps responsibilities clean: the operator owns how the agent thinks (the prompt), and your workflow owns what it's pointed at (the input). Get the input wiring right — usually a field or two from the workspace snapshot — and the agent does the rest.