Prompt Engineering for Automation: Writing Prompts That Actually Run Reliably

There's a difference between a prompt that works when you're watching it and a prompt that works when it's the third step in a Make scenario firing two hundred times a day. The first one you can fix while you watch. The model drifts, you see it, you adjust the wording and rerun. The second one runs without you. It has to handle inputs you never saw in testing, fail in ways the next node can recover from, and return something your filter or formatter step can actually read.

Most prompt advice is written for someone sitting in ChatGPT having a conversation. When you drop that same prompt into an n8n AI node feeding a Google Sheet, the rules change. This is about the second case.

The output format is a contract with the next step

When you read model output yourself, you forgive a lot. "Sure, here's the summary:" followed by the summary reads fine to a human. Your Zapier formatter step reading the same thing grabs "Sure, here's the summary:" as the value and pushes it into your CRM. The most common reason an automated prompt breaks isn't weak reasoning. It's the model wrapping its answer in friendly conversation that your workflow wasn't built to strip out.

Pin the format down. If the next step expects one clean value, tell the model to return only that value with nothing before or after it. If you need structured data with several fields, ask for JSON, name the exact keys, and show one example of the shape you want back. A model told "respond only with valid JSON, no explanation" will follow that most of the time.

A pattern that holds up in real scenarios: have the model put its answer inside a delimiter you pick, like a tag, then add a step that extracts what's between the tags. This beats hoping the whole response comes back clean, because it gives the model somewhere to put any throat-clearing without poisoning the value you actually pass downstream.

A worked example: screening CVs in n8n

Here's the format-as-contract idea applied to the hiring pipeline. The prompt screens a CV and returns its verdict inside a tag, so any stray sentence the model adds lands outside the tag and never reaches your next step.

The AI node prompt:

You are screening a candidate for an AI Automation role.

Read the CV text below and return:

- decision: "shortlist" or "review"

- reason: one sentence, 20 words or fewer

Rules:

- shortlist only if the CV shows at least 2 years of hands-on

  automation work (Zapier, Make, or n8n) AND includes a

  portfolio or GitHub link

- if the CV is empty or unreadable, return decision "review"

  and reason "no readable CV content"

Return your answer only inside tags as JSON, with

nothing before or after the tags:

{"decision": "shortlist", "reason": "..."}

CV text:

{{ $json.cv_text }}

After the AI node, add a Code node to pull out what's between the tags and parse it. The node reads the model's reply, looks for the block, and falls back to a safe "review" verdict if the block is missing or the JSON is broken, so a bad response slows a candidate down instead of crashing the run:

// Point this at your AI node's output field. Depending on the

// node and version it may be message.content, text, or output.

const raw = $input.first().json.message.content || "";

const match = raw.match(/([\s\S]*?)<\/result>/);

if (!match) {

  return [{ json: { decision: "review", reason: "no result block found" } }];

}

try {

  return [{ json: JSON.parse(match[1].trim()) }];

} catch (e) {

  return [{ json: { decision: "review", reason: "result was not valid JSON" } }];

}

Downstream, your IF node branches on {{ $json.decision }}, and the rest of the scenario routes shortlisted candidates one way and everything else to manual review. The model never hands a raw paragraph to your Google Sheet, because the only thing leaving the Code node is a clean two-field object.

If you're building in Make instead, the same pattern uses a Text Parser "Match pattern" module with the regex ([\s\S]*?)<\/result> to grab the contents, then a JSON "Parse JSON" module on the captured group.

Write for the input you'll actually get

Building a prompt on tidy sample data is how you ship something that breaks in week one. The real inputs flowing through your automation are messier. Empty fields where a form was submitted blank. A customer message in Yoruba when you tested in English. Text that arrives already half-formatted from another tool. An input five times longer than anything you tried. And eventually, someone typing instructions into a form field hoping your AI step will follow them instead of yours.

Decide what each of those should do before you turn the scenario on, and write that decision into the prompt. What should the model return when the input is empty? If the answer is "an empty result in the same format," say exactly that, because the model's instinct is to apologize or ask a question, and neither of those parses cleanly into the next step. What happens when the input contradicts the instruction? Tell the model how to resolve it instead of leaving it to guess differently each time.

This is where examples pay for themselves. One or two examples of the normal case teach the model your format. An example built from a weird input, the blank submission or the message in the wrong language, teaches it judgment. That second kind is usually the one that stops your workflow from quietly producing garbage over a weekend.

Constrain the reasoning, not just the answer

A prompt that says "review this CV and decide if the candidate is a fit" gives you a different answer depending on how the model reads the borderline cases that day. A prompt that says "mark as shortlist if the CV shows at least two years of hands-on automation work with Zapier, Make, or n8n and includes a portfolio or GitHub link, otherwise mark as review" gives you the same call for the same CV, run after run. For a hiring pipeline that screens hundreds of applications, that consistency is the reason you built the automation instead of reading each one yourself.

Vague instructions get interpreted, and every interpretation is a place the output can swing from one run to the next. Wherever you leave a judgment call open, you've added drift. You won't close every gap, but the ones tied to your actual criteria are worth nailing down, because those are the ones where a loose call shortlists the wrong person or screens out someone you wanted.

There's a real tension with letting the model think out loud. Reasoning through a candidate usually makes the decision better, but free reasoning also widens the range of formats the model might land in. A compromise that works: let it reason inside a section you label as scratch, then have it give the final verdict in a fixed structure underneath. You keep the judgment quality and still get a clean value to pass to the next step.

Treat a saved prompt like infrastructure

Once a prompt sits inside a live scenario, it's a dependency the rest of your workflow leans on. Change the wording and the behavior of every step after it can shift. So keep track of what your prompts say and when you changed them. Even a simple doc with the current prompt text, the date, and a line on what you adjusted will save you when a scenario that ran fine last month starts behaving differently and you need to know what moved.

Writing it down also forces a useful habit. When you record a prompt and its history, you start noting why a line is there, the malformed input that made you add that odd instruction about skipping blank fields. That note saves the next person who opens the scenario, often you in four months, from cleaning up the prompt by deleting the exact line holding it together.

Test the prompt before you trust it

You wouldn't switch on a scenario that moves money or messages customers without running it on a few cases first. A prompt deserves the same check. Put together a small set of test inputs that covers your normal path plus the failure modes you've already hit, run the prompt against all of them whenever you change the wording, and confirm each output is something the next step can read and that it means what it should.

The cases don't need to be fancy. A dozen sample inputs with the output you expect, pushed through your actual workflow, will catch the moment a wording tweak that fixed one case quietly broke three others. Models don't return the identical answer every single time, so run each case more than once. A prompt that gives you the right output four runs out of five is telling you something honest about how it will behave once it's live.

What this adds up to

A reliable automated prompt is mostly defensive work. You specify the format so the next step can read it, name the edge cases so the model doesn't invent its own handling, lock down the judgment calls that map to your business rules, and keep the prompt tracked and tested instead of pasted in once and forgotten. None of it is flashy. It's the same plain discipline behind any automation you'd let run unattended, applied to a step that happens to be made of words.

The clever prompt that produces a brilliant answer once is a demo you show in class. The plain prompt that produces an adequate answer two hundred times a day without breaking your scenario is the thing you actually got hired to build.