Prompt engineering for business automations: writing instructions a model follows on the ten-thousandth run
A prompt in an automation runs unattended at scale, so it needs to be specific, constrained and testable. The structure — role, inputs, task, format, rules, examples — and the habits that keep outputs consistent.
10 Jan 2026 · 2 min read · by HeiSyn
A prompt written for a chat window and a prompt written for an automation are different objects. The first is a conversation with a person watching; the second runs ten thousand times with nobody watching, and its output is parsed by the next step. The second kind needs the discipline of code: a fixed structure, explicit constraints, a defined output shape, and tests.
Structure
Role: one sentence on what the model is acting as. Inputs: the data, clearly delimited and labelled. Task: exactly one thing to do. Output format: a JSON shape or a fixed template, with every field defined. Rules: what to do when the input is missing, ambiguous or out of scope — including a 'return unknown' path. Examples: two or three input-output pairs, including an edge case.
Constrain the output
Ask for structured output and validate it. Enumerate allowed values for classifications. Set length limits. Ban the phrases you have seen it produce that you do not want. A model that is told exactly what shape to return returns it almost every time; one that is told to 'summarise' returns something different on each run.
Test like software
Keep a file of twenty to fifty inputs with the expected outputs. Run them after every prompt change and after every model update. Track the pass rate. A prompt that scores lower than the last version does not ship. This costs an hour to set up and saves the afternoon of debugging a silent regression.
Version and observe
Prompts in version control, with a changelog. The prompt version logged on every output. A sample of production outputs reviewed weekly. When something looks wrong in the CRM, the version tells you when it started and the sample tells you how widespread it is.
Questions people ask next
- Should prompts be in the workflow or in a separate file?
- In version control as separate files that the workflow loads, so they can be diffed, reviewed and rolled back independently of the workflow. Inline prompts in a workflow node are where undocumented changes hide.
- What temperature should automation prompts use?
- Low — zero or close to it — for classification, extraction and anything with a defined output. Consistency matters more than variety in an automation. Reserve higher settings for drafting tasks where a person reviews the output.
- How do we handle inputs the prompt did not anticipate?
- Give the prompt an explicit path for them — return a defined 'cannot process' value with a reason — and route those outputs to a person. A prompt that must always produce an answer will produce a wrong one when surprised.
Want this built for your team?
A free scoping call: we map your motion, name the number that should move, and quote a fixed-scope build.
Related
- Documenting automations so they survive the person who built them
- Choosing data and enrichment providers: coverage, accuracy, compliance and cost by region
- API rate limits, batching and retries: keeping CRM integrations from falling over
- Migrating from Zapier to n8n without breaking anything on a Tuesday
