The mental model that fixes most bad prompts: you are not asking a question, you are onboarding a contractor who starts in ten seconds and has never heard of your business. A new hire gets context, constraints, examples of good work and a definition of done. A prompt that skips any of those produces exactly what a new hire would produce without them — something plausible, generic and subtly wrong.
The corollary is that prompts are assets, not messages. A prompt you will run four hundred times against four hundred store records deserves an afternoon of iteration and a version number. The people getting good output from agents are not writing cleverer sentences. They are reusing three or four patterns that they refined once and have not touched since.
Pattern one: count before you commit
Write it as a hard sequence. Before returning any list, report how many stores match the filter. If the count is below fifty, loosen exactly one criterion and report the new count. If it is above five thousand, tighten exactly one. Do not return rows until the count sits between fifty and five thousand, and state which criterion you changed and why.
The clause doing the work is exactly one. An agent asked to fix a filter will rewrite the whole thing, and you lose the thread of what you were actually testing. One variable at a time is the same discipline that governs testing outreach: change the subject line or the body, never both, or the result tells you nothing you can act on next week.
This pattern also surfaces dead filters early. A combination that returns eleven stores usually means a country code, a platform name or a field spelling is wrong — and finding that in the first ten seconds is considerably cheaper than finding it after the agent has enriched and drafted for eleven irrelevant merchants.
Pattern two: the evidence contract
Every factual statement about a store must be followed by the name of the field it came from. If the field is empty, omit the statement rather than inferring it. If you cannot write three evidenced sentences about a store, return the store with the note insufficient data and move on. That is the entire pattern, and it does more for output quality than any amount of tone instruction.
It works for two reasons. First, fabrication becomes structurally visible — an invented claim has no field to name, so it either disappears or announces itself. Second, the insufficient-data escape hatch changes the model’s incentives completely. Without a way to decline, an agent asked for output will produce output, and the gaps get filled with confident guesses about revenue, budget or strategy.
Track how often the escape hatch is used. If it never fires across a large batch, the contract is not being enforced and you should assume the evidence lines are decorative. A healthy rate of insufficient-data returns is a sign the pattern is working, not a sign the data is thin.
Pattern three: schema-locked output
Describe the shape of the answer in words, precisely, and forbid anything around it. A domain as a string. A score as an integer between zero and one hundred. Exactly three evidence strings, each ending with the field name in parentheses. A segment label chosen from a closed list you supply. A boolean for whether a contact email exists. Nothing before the structure and nothing after it — no preamble, no summary, no offer to help further.
The closed list matters more than the format. Let an agent name segments freely across four hundred rows and you will get a hundred and eighty segment names, which is the same as having none. Supply six labels and force every row into one of them, plus an explicit unassignable option so you can see what your taxonomy is missing.
Pattern four: one good example and one bad one
Few-shot examples work, but the negative example does more work than the positive. Show one output you would ship, then one you would reject, with a single line explaining why the second fails — it claims something no field supports, or it opens with a compliment, or it invents a number. Models generalise from contrast far better than from a single specimen of good.
Pair that with an explicit ban list for outreach copy. No opening line that begins with coming across their website. No declarations of admiration for what they are doing. No apologising for the intrusion, no announcing that you know they are busy, no introducing yourself in the first line when the signature already does it. These phrases signal template at a glance, and merchants have been trained by thousands of emails to delete on that signal alone.
Keep the ban list in the prompt rather than fixing the output afterwards. Post-processing removes the phrase and leaves the sentence shaped around it, which is somehow worse. Prevention is one line; correction is a regular expression and a lie.
Pattern five: the segmentation loop
Do not ask an agent to segment and assign in one pass. Run two. First pass: read a sample of store records and propose five to eight segments, each with a name, a defining rule expressed purely in field values, an estimated size, and the angle you would pitch to it. Second pass, with the segment list now fixed: assign every row, and return anything that fits none of them.

The unassignable pile is the most valuable output of the whole exercise. It is where the segments you did not think of live — the stores with large catalogs and no Google presence, the ones with strong traffic and no AI visibility at all, the ones on a platform you have never sold to. Segments discovered in the data beat segments invented in a meeting, every time.
Requiring rules expressed in field values is what keeps this honest. A segment called premium boutiques is a vibe. A segment defined as product count under eighty, average traffic above ten thousand, rating above four and a half, with a claimed Google profile, is something you can re-run tomorrow and get the same rows.
Pattern six: the critic pass
Send the source record and the draft to a separate prompt with no memory of how the draft was produced. Three questions only. Is every factual claim traceable to a named field. Is any required element missing. Does the tone match the brief. Then a verdict: pass, revise or reject, with one sentence of reason.

The critic must not rewrite. Give a model permission to improve and it will regress everything toward the same competent, forgettable middle, and after a hundred rows every email in your queue will sound identical. A critic that only judges preserves the variation that came from the data, which is the only thing making the emails specific in the first place.
Anti-patterns worth naming
Asking for creativity. Be creative is an instruction to abandon your constraints, and what comes back is metaphor where you wanted a fact. If you want variety, vary the input — different segment, different angle, different artifact — not the temperature of the instruction.
Stacking ten instructions into one dense paragraph. Models drop the middle of long undifferentiated blocks. Number them, group them by concern, and put the non-negotiables last where they are least likely to be lost. Then read the prompt aloud; if you lose track of it yourself, the model will too.
Asking for a number the model cannot know. Ad spend, revenue, headcount, marketing budget — a request for any of these will be answered, fluently and wrongly. There is no advertising data anywhere in this stack, and pretending otherwise produces the one category of error a prospect will notice immediately. State the absence in the prompt so the agent has somewhere honest to land.
And using the same prompt for research and copy. Research wants breadth, caution and structured output. Copy wants one record, a narrow angle and voice. A prompt that tries to do both produces research that reads like marketing and marketing that reads like a spreadsheet.
How to test a prompt change
Keep a fixed evaluation set of twenty store records you have read by hand and whose right answers you know. Change one thing in the prompt. Re-run the twenty. Score three numbers: the share of claims with a valid field citation, the share of outputs matching the schema exactly, and the share the critic rejects. Anything else is impressions.
Version your prompts alongside the rest of the pipeline, with a date and a one-line note on what changed and what moved. Six weeks in you will want to know why the current version has a strange clause about closed lists in the middle of it, and the answer will be a batch of four hundred rows that came back with a hundred and eighty segment names. Prompts drift the same way filters do, quietly, and the fix is the same: measure, one change at a time, and write down what you learned.
