Prompt Engineering: A Framework for Prompts That Actually Work

Prompt engineering is the practice of structuring what you tell an AI model so it reliably does the specific thing you need, not a vague approximation of it. It isn't a set of magic words or a trick you memorize. It's closer to writing a spec: you give the model context, a task, constraints, a required output format, and often an example, roughly in that order, because models weight what comes first and treat the rest as elaboration. Most bad AI output traces back to a missing piece in that stack, not to the model being dumb. This post lays out the framework, then rebuilds one real prompt three times so you can see, concretely, what "better" even means.

Why "just ask better" isn't a strategy

Anthropic's own prompt engineering guidance for Claude makes a point worth sitting with: the field is shifting from "prompt engineering," which sounds like finding the right incantation, to "context engineering," which is about optimizing everything the model sees, including the system prompt, the available tools, prior examples, and the conversation history, not just the sentence you typed (Anthropic, prompt engineering best practices). That reframe matters for anyone building with AI day to day. If your output is wrong, the fix usually isn't a cleverer verb. It's an information gap: the model didn't have something it needed, or it had too much noise burying the one thing that mattered.

OpenAI's developer documentation makes a related, more mechanical point: the API itself enforces a hierarchy between message roles. Developer messages carry the system's rules and business logic, user messages carry inputs, and assistant messages are the model's own prior turns, each with a different priority level in how the model resolves conflicts (OpenAI, prompt engineering guide). In other words, the platforms you're already using were built around the idea that instructions have layers and an order. Prompt engineering is just doing that on purpose, in a single message, instead of by accident.

The five-layer prompt stack

Strip away the jargon and almost every prompt that works reliably contains the same five ingredients, in the same rough order. Miss one and you get an answer that's plausible but not what you needed. This is the framework: treat it as a checklist you run before you hit enter, not a template to fill in mechanically. This framework centers on prompts that produce text; prompting for AI image generation leans on the same context-task-constraints thinking but weights style and composition description far more heavily, since there's no back-and-forth to fix a vague result after the fact.

1. Context

Who is asking, what's the situation, and what does the model need to know that isn't obvious from the task alone. This is where you tell the model about your business, your customer, your codebase, or your constraints as a founder rather than as a generic user. A model with no context defaults to the most statistically average answer for your phrasing, which is exactly the generic output most people complain about. If you're prompting about your own business regularly, it's worth reading up on how to give AI context about your business so you're not re-explaining the same background in every prompt.

2. Task

One sentence, stated as an instruction, not a question. "Write X that does Y for Z" beats "Can you help me think about maybe writing something for this." Vague tasks get vague answers because the model is filling in the same ambiguity you left open. If you find yourself writing three sentences trying to describe the task, that's usually a sign the task itself is underspecified, not that you need more words.

3. Constraints

What the output must or must not include: length, tone, things to avoid, things that are non-negotiable (a legal disclaimer, a specific number, a banned phrase). Constraints are where most prompts quietly fail. People state the task and assume the model will infer the boundaries. It won't, reliably. State the constraint even when it feels obvious to you.

4. Output format

Tell the model the literal shape of what comes back: a numbered list, a table replaced with prose, an email with a subject line, valid JSON matching a schema, three paragraphs and nothing else. Skipping this step is the single most common reason people get an answer that's "close but the wrong shape" and have to reformat it by hand. If you're piping AI output into another system, this layer isn't optional. See how to get JSON output from AI if that's your case, since structured output has its own failure modes on top of the general ones here.

5. Examples

One good example of the input-to-output mapping you want does more work than three more paragraphs of description. This is few-shot prompting, and it's not a nice-to-have for anything with a specific tone, format, or edge case. Show, don't just tell, whenever the "right answer" is easier to demonstrate than to describe in words.

These five layers also have a priority order when they conflict, which mirrors the role hierarchy OpenAI documents at the API level: context and constraints set the boundaries, the task defines the goal inside those boundaries, and format and examples shape the final presentation. If you're building an app with a system prompt and letting end users type their own prompts on top of it, this ordering question becomes a real design decision, not just a writing tip. That's covered in more depth in system prompt vs user prompt.

One prompt, rebuilt three times

Frameworks are easy to nod along to and hard to apply. So here's one realistic prompt, built up through three versions, using a scenario a lot of this audience will recognize: replying to an unhappy client email as a small agency or freelancer.

The starting situation: a client's project shipped 10 days late because a bug broke the client's checkout flow in staging and the fix took longer than expected. The client emailed, annoyed, asking what happened and when it'll actually be done.

Weak version

Write a reply to this client email:

"Hi, it's been over a week past the deadline and I still don't have
the finished site. What's going on? I need a date I can actually
rely on."

This produces a generic, safe-sounding apology. It could be a reply to almost any late-project complaint from any agency in any industry. It will not mention the bug, the checkout flow, or a real date, because none of that context exists in the prompt. The model is guessing at tone and content simultaneously.

Better version

You are replying, as the agency owner, to a client who is frustrated
about a late delivery. The project is 10 days overdue because a bug
broke the checkout flow in staging, and the fix took longer than
estimated. Write an email reply that:
- acknowledges the delay without being defensive
- briefly explains the technical cause in plain, non-technical language
- gives a specific new delivery date: this Friday
- keeps the tone calm and professional, not groveling

Keep it under 150 words. Do not admit fault in a way that sounds like
a legal admission of liability.

This is dramatically better. It has context (agency owner, the bug, the timeline), a clear task, real constraints (length, tone, legal caution), and it will produce an email that's actually about this project. Most people stop here, and honestly, for a one-off email, this is often enough.

Best version

You are the owner of a small web development agency replying to a
long-standing client. Context: the project (a booking system rebuild)
is 10 days overdue. Cause: a bug broke the checkout flow during staging
tests, and fixing it took longer than the original estimate because it
touched a third-party payment integration. The client has been a client
for two years and has never complained before, so this is a real but
recoverable relationship, not a burned bridge.

Task: write a reply email that rebuilds confidence and gives a firm
next step.

Constraints:
- under 150 words
- calm, professional tone, no groveling, no over-apologizing
- do not phrase the cause as a legal admission of fault or liability
- include a specific new delivery date: this Friday
- offer one concrete goodwill gesture (for example, a discount on the
  next invoice or an extra week of free support)

Output format: a complete email with a subject line, greeting, three
short paragraphs (acknowledge, explain, resolve), and a sign-off.

Example of the tone I want (from a past client email, different
situation, same voice):
"Appreciate you flagging this directly, it's exactly the kind of thing
we'd want to know about fast. Here's what happened and what we're doing
about it..."

This version adds the relationship context (two-year client, first complaint), a concrete goodwill gesture requirement, explicit output structure, and a real tone example pulled from an actual past email. The output will read like it was written by someone who knows this specific client and this specific situation, because the prompt gave the model exactly that.

The test that actually proves it worked

Here's the check that separates a prompt that's genuinely better from one that just looks more detailed: swap in different real specifics and see if the output changes in a way that reflects the new facts.

Take the "best" prompt above and change the cause to "the delay was because the client submitted new requirements halfway through the build" instead of a bug. A well-built prompt should produce a visibly different email: less technical explanation, more focus on the scope change, possibly a different tone around whose "fault" it was. If the output barely changes regardless of what you swap in, your prompt isn't actually using the specifics you gave it. That's the same diagnostic behind how to prompt AI without getting generic answers: generic prompts produce generic output no matter how the input details change, and that's the tell.

If you run this test on a prompt you're already using in production and the output doesn't budge when the facts change, you don't have a prompting problem you can word your way out of. You have a missing-context problem, and no amount of politeness or clever phrasing fixes it.

Techniques worth knowing (and when to actually use them)

The five-layer stack covers structure. These are the specific techniques that make the content inside each layer work harder, and they show up across both Anthropic's and OpenAI's own guidance:

• Few-shot examples. Covered above, but worth repeating: Anthropic's own docs note that modern models "pay very close attention to details in examples," so a sloppy or inconsistent example will teach the model the wrong pattern just as effectively as a good one teaches the right one.

• Role or persona framing. Telling the model who it's acting as ("you are the agency owner replying to a client," not "you are a helpful assistant") narrows the range of plausible responses before the task even starts. It's not roleplay for its own sake, it's a fast way to set tone and priorities in a few words instead of a paragraph of description.

• Chain of thought / step-by-step instructions. Asking the model to reason through steps before giving a final answer helps on anything with multiple sub-decisions, like classification, math, or multi-constraint writing tasks. Reasoning models handle this differently: OpenAI's guidance notes that reasoning models actually do better with high-level goals rather than over-specified step-by-step instructions, since they plan the steps internally. Know which type of model you're prompting before you over-engineer this part.

• Delimiters and structure. Use headers, XML-style tags, or Markdown to separate context from task from examples inside a long prompt, especially once a prompt has multiple sections. This isn't decoration, it's how the model tells your background information apart from your instructions.

• Explicit permission to say "I don't know." Stating that an uncertain or partial answer is acceptable measurably reduces confident wrong answers on ambiguous questions, which matters anywhere hallucination risk is a real cost, not just an inconvenience.

• Diagnosing instead of rewriting from scratch. When a prompt fails, resist the urge to just add more words. Isolate which of the five layers is missing or wrong first. That triage process, and specific fixes for the most common failure patterns, is laid out in how to fix a bad AI prompt.

Prompting is different when you're building an app, not chatting

Everything above assumes a one-off prompt typed by a human. If you're building a product where an AI model runs against prompts you wrote once and thousands of users trigger, the stakes on getting the layers right go up, and a few things change: your context layer often has to be assembled dynamically from a database or user input rather than typed by hand, your constraints have to hold across inputs you didn't anticipate, and your output format has to be something your app can parse without a human checking it first. A prompt that works great when you type it three times in a chat window can fall apart the first time a real user pastes in something messy, so the testing bar is higher: run it against a spread of realistic inputs, not just the clean ones you wrote it against. That's a distinct enough problem that it gets its own approach in how to write prompts for AI app builders, and it's worth reading before you ship a prompt that only worked in your three manual tests.

A short checklist before you hit enter

If you don't want to rebuild the full five-layer stack from scratch every time, run through this before sending anything that matters:

1. Does the model have the context it actually needs, or am I assuming it knows something it doesn't?

2. Is the task one clear instruction, not a question or a hint?

3. Have I stated the constraints out loud, even the obvious ones?

4. Did I specify the exact shape of the output I want back?

5. Would one example make the "right answer" obvious instead of describable?

If you can answer all five without guessing, you've done the actual work of prompt engineering, regardless of how long or short the prompt ends up being.

When prompting alone stops being enough

There's a ceiling on what a well-structured prompt can do, and it's worth knowing where it is before you spend another hour tuning wording that isn't the actual bottleneck.

Prompting struggles when the model needs facts it was never trained on and that are too large or too fresh to paste into every prompt, like your entire product catalog or a knowledge base that updates weekly. That's a retrieval problem, not a prompting problem, and stuffing more instructions into the prompt won't fix a missing-knowledge issue.

Prompting also struggles when you need consistent behavior across a huge volume of edge cases, or a very specific style and vocabulary baked in so deeply that no amount of in-prompt instruction reliably reproduces it. At that point you're looking at training the model itself on your data, not just instructing it better each time.

Both of those are real, separate solutions with real tradeoffs in cost and complexity, and they're worth understanding on their own terms before you decide you need one. Start with what is fine-tuning in AI if the problem is behavior and style, and RAG vs fine-tuning vs long context if the problem is getting the right facts in front of the model at the right time. Most people reach for one of these before they've actually exhausted the prompt, though. The five-layer stack, applied honestly, fixes more problems than it gets credit for.

Frequently asked questions

What is prompt engineering in simple terms?

It's structuring what you tell an AI model, context, task, constraints, output format, and examples, so it reliably produces the specific result you want instead of a generic average answer. It's closer to writing a short spec than finding magic words.

What are the main prompt engineering techniques?

The core ones are few-shot examples, role or persona framing, chain-of-thought or step-by-step instructions, delimiters to separate sections of a long prompt, and explicitly allowing the model to say it doesn't know something. Which ones help depends on the task and the model.

How do you know if a prompt is actually good, not just longer?

Swap in different real specifics and check whether the output changes to reflect them. If a prompt produces nearly the same generic answer regardless of the details you feed it, it isn't using those details, no matter how detailed it looks.

Do you need to learn prompt engineering to use AI tools well?

Not formally, but understanding the five-layer structure, context, task, constraints, format, examples, fixes the majority of disappointing AI output people otherwise chalk up to the model being unreliable.

Is prompt engineering still relevant with reasoning models?

Yes, but the emphasis shifts. Reasoning models tend to do better with clear high-level goals and let the model plan its own steps, while non-reasoning models benefit more from explicit step-by-step instructions. Context, constraints, and format still matter for both.

One tactical choice inside that framework is example count: few-shot vs zero-shot prompting

One technique worth knowing on top of the fundamentals here is splitting a complex task into multiple linked calls. See how to chain prompts together for a worked example.