12 Prompt Engineering Best Practices from Building an AI SaaS

You give your AI a writing prompt. The output comes back generic, so you add a rule. Then you add another one, and another, until ten rules later the output is somehow worse than when you started.

More instruction produces less compliance, and you can't figure out why.

I can tell you why, because I lived it. Every constraint you add to a prompt competes with every other constraint for the model's attention. Past a certain point, your instructions stop being a system and start being noise.

Prompt engineering is the craft of writing instructions an AI can actually follow, and most of it comes down to respecting how the model's attention works.

These 12 prompt engineering best practices come from months of live failures building Flyletter's newsletter agents. It took blood, sweat, and tears (mainly tears). They apply whether you're prompting ChatGPT to draft next week's edition or engineering your own multi-agent pipeline from scratch.

Core Prompt Engineering Best Practices

1. Goals and Guardrails Over Rigid Rules

AI models follow somewhere between 20% and 50% of your rules once you stack more than ten of them, and the rules at the end of the list get dropped first.

Flyletter's early draft agent carried a rule list that read like a legal contract:

Write in the user's brand voice. Don't use bullet points. Keep it under 400 words. Avoid jargon. Use short paragraphs. Don't sound corporate. Include a CTA. Match the subject line tone. Don't repeat the opening line. Stay positive.

The model treated that list like a buffet and picked what it wanted. The fix was one clear goal plus a few hard guardrails:

Goal: Draft a newsletter section that sounds like this creator on their best day. Guardrails: Factual claims must trace to the brief. Typical newsletter sections are 400 words or less.

A goal gives the model something to aim at. Guardrails mark the few lines it can't cross. Everything else is trust.

2. Show, Don't Tell

One strong example anchors the model better than three paragraphs of description.

I spent weeks describing voice to Flyletter's agents. I tried adjectives, tone scales, and style guides, and none of them moved the needle like dropping in a single sample paragraph of the real thing.

A description forces the model to imagine the target. An example gives it a reference to check against, and models are far better at matching than imagining. It's the reason Flyletter builds your brand voice profile from your actual writing samples instead of a text box that says "friendly but professional."

3. Avoid Bloated Prompts

Output quality degrades at around 3,000 tokens of instruction, well below any model's context limit. The failure is quiet. The model keeps producing fluent drafts while silently ignoring a growing share of your instructions.

Flyletter's newsletter agent started at 24k tokens of instructions and inputs. Every quality improvement since then came from cutting, not adding.

When output drifts, the instinct is to write a new rule. The fix is almost always deleting three old ones.

Structural Prompt Engineering Best Practices

4. Use XML Tags for Structure

Markdown headers suggest structure. XML tags declare it.

A <context> tag tells the model that everything between it and </context> is the context, and nothing else is. In a complex prompt holding instructions, examples, and background data, that unambiguous boundary keeps sections from bleeding into each other.

Every Flyletter agent prompt is sectioned this way, with the writing standards in one tag, the brand profile in another, and the task in a third. The model always knows what it's reading.

5. Data First, Directive Last

Models latch onto the beginning and the end of a prompt and go soft in the middle. Researchers call it the lost-in-the-middle problem, and it means task instructions buried mid-prompt land in a dead zone.

So the order matters: context, examples, and background first, directive last. Flyletter loads your brand profile and writing samples up front and places each agent's actual task at the end, where the model's attention is sharpest.

6. Say It Once

Repeating an instruction feels like insurance and works like a liability.

Repetition bloats the prompt, and any small difference between the two versions creates competing anchors. The model notices the gap between "keep it under 400 words" and "keep sections short," then drifts trying to satisfy both.

Every instruction lives in one place. If you feel the urge to repeat a rule, that urge is telling you the rule isn't clear enough where it already sits.

7. State an Explicit Priority Hierarchy

Your instructions will conflict. The voice rules will fight the formatting rules eventually, and if you haven't said which one wins, the model decides for you, silently and inconsistently.

Flyletter's agents run on an explicit ladder: safety first, then the writer's voice, then the task rules, then the universal quality floor. When the quality floor wants to strip a quirk your voice profile insists on, voice wins, because that ordering is written into the prompt.

State your hierarchy and the model stops guessing.

Phrasing Prompt Engineering Best Practices

8. Use Positive Language

Tell the model "don't use bullet points" and you've just put bullet points front of mind. Negative instructions draw the model's attention to the exact behavior you're trying to prevent.

Tell it "write in flowing prose" instead and you've given it a target to aim at. Frame instructions as things to do, and save the hard "never" for the few lines that genuinely need one.

9. Explain the Why

Models generalize better from a reason than from a bare command.

"Avoid jargon" works on the sentences you anticipated. "Avoid jargon so a non-technical reader can follow" also works on the edge cases you didn't, because the why hands the model a decision rule it can apply to situations your instruction never covered.

10. Dial Back the Aggressive Language

Older models needed a CRITICAL or a MUST to pay attention. The newest models follow instructions more literally, and they over-trigger on that language, contorting the output to over-satisfy whatever you shouted.

When everything is critical, nothing is. Write in calm, plain language and reserve the hard imperatives for genuinely hard constraints, so that when you do use one, it still signals something.

11. Keep Descriptors Neutral

Every adjective in your prompt is an instruction, whether you meant it as one or not.

Flyletter's draft agent used to be told to write as the creator "on their sharpest day." The drafts came back full of short, fragmented sentences. The model had read "sharpest" as a style direction and sharpened the prose itself. Swapping one word ("best day" instead) removed the bias entirely.

Audit your descriptors, because loaded words steer output in directions you never chose.

The Closing Prompt Engineering Best Practice

12. Verify at the End

The end of your prompt is where the model's attention peaks, and most people waste it restating rules the model already read.

Use it as a gate instead:

Before responding, confirm: (1) the output matches the goal, (2) no forbidden phrases appear, (3) the format matches the spec.

A closing checklist makes the model check its own work against specific outcomes. Every Flyletter agent ends with one, and it catches the drift the first 11 practices didn't prevent.

Bottom Line

Bad AI output is the predictable result of treating a prompt like a rulebook instead of a system, and no fourteenth rule or ALL CAPS warning will patch it.

The fix is the four moves working together: goals and guardrails instead of rule lists, structure the model can actually parse, phrasing that doesn't trigger the failure you're trying to avoid, and a verification gate at the end.

That's the system running inside Flyletter's agent pipeline, one agent and one narrow prompt at a time, all of it built on a set of universal writing standards. Steal these practices for your own prompts, or let the pipeline that already follows them write your next edition.