A Practical Guide to Prompt Engineering in September 2026

I recently read an article on prompt engineering that claimed to be current for 2026. Frankly, it was years out of date.

It recycled the advice we were all using in 2023: assign the model an expert persona, tell it to think step by step, add a stack of examples, then keep tweaking the wording until something good comes back.

I went looking for a proper guide to prompt engineering as it stands today and couldn’t find one, so I wrote it.

Prompting still matters, but I spend much less time writing prompts than I used to. Most of my effort now goes into preparing the context, working through the idea with an agent, and giving it a clear brief before I let it run.

Should this be a prompt at all?

This is the first question I ask.

Models are useful when a task needs judgement. They can interpret messy information, draft something new, compare reasonable options, or make sense of a request where the right path depends on the input.

For fixed work, I’d rather use a fixed tool. Calculations belong in a calculator. Business rules belong in code. Known information should be retrieved from its source. A repeatable series of actions is usually a workflow. A field with five valid values needs validation, not a beautifully written prompt asking the model to behave itself.

A lot of prompt problems are system problems in disguise. The model is missing data, the process hasn’t been agreed, the tool is badly designed, or nobody has defined what a good result means. Rewording the request won’t repair any of those.

Use a prompt where judgement helps. Make the predictable parts predictable by other means.

How I actually work with an agent

A few years ago, the goal was to write one beautiful prompt that gave the model everything it needed in one go. That still works for simple, contained jobs. I use it for a short email, a quick summary, or a first pass over some data.

Complex work is different. I prepare the agent, talk through the job with it, confirm what we’ve agreed, then let it run.

Say I need to put together a project plan. I’ll start by dropping in the useful material: meeting notes, emails, the proposal, known dates, existing documentation, and anything else that explains the job. Then I might say:

Review this material. We’re going to put together a project plan from it. Before we start, ask me five questions about how we should plan the project. Ask them one at a time.

That starts a conversation rather than a run.

The agent asks a question. I answer it. Its next question reminds me that we need to allow for a client approval, or that one part of the work depends on another supplier, or that a date in the proposal is no longer realistic. I add that. The agent follows the new information and asks the next question.

A few minutes of back and forth usually produces a better brief than I could have written at the start. I don’t always know every constraint until something prompts me to think about it.

Once the conversation has covered the job, I ask the agent to gather it up:

Turn everything we’ve agreed into a bullet-point brief. Include the goal, constraints, decisions, dependencies, open questions, and what done looks like. Don’t start the plan yet.

That step matters. I can read the brief and correct anything the agent misunderstood. The agent now has a list it can work through rather than a long conversation it has to reinterpret as it goes.

Once the brief is right, I tell it to go for it.

The working prompt for a complex task is the full conversation and the confirmed brief. The opening message only gets the process started.

What goes into the preparation

The conversation works because the agent has enough material to ask useful questions. I try to give it four things.

A clear result

Tell it what you need, who it is for, and what happens next. “Write a project update” leaves too much unresolved. The agent needs to know whether the reader needs information, a decision, or a warning.

Depth matters too. “Build an analytics dashboard” may produce the smallest thing that satisfies the request. If you need empty states, error handling, accessibility, tests, and deployment notes, say so. Those are part of the result.

Context that changes the answer

The agent doesn’t know your client, your internal language, what has already failed, or which compromise your team has made on purpose.

Include the facts that would cause a sensible person to answer differently. That usually means the audience, purpose, prior attempts, hard limits, and how the result will be used.

The reason behind a constraint is often more useful than the rule by itself. “Never use bullet points” handles one formatting choice. “This is a personal email and bullets feel too formal for how I write” gives the agent enough information to make related choices.

Real references

References beat adjectives.

If I want writing in my voice, I provide things I’ve written. If a new page should match an existing one, I point at the page or the design. If code must follow a local pattern, I point at the working code and its tests.

Source code is often the best technical specification available. A working implementation in another language can explain behaviour better than two pages of prose. The same goes for an HTML mock-up, a report, a marked-up example, or a proper rubric.

Permission to question the job

I want the agent to raise missing information before it starts. For technical work, I ask it to focus on decisions that could change the architecture. For writing, I ask what it needs to know about the audience, argument, and intended action.

The questions won’t all be useful. Some surface a real blind spot and others are irrelevant. Reacting to them still helps me clarify the job.

When the work repeats, turn it into a skill

If I need to do the same kind of complex task again, I don’t keep pasting a giant prompt into chat. I save the method as a skill.

The skill carries the durable instructions: what context to gather, which questions to ask, what references to load, how to confirm the brief, the expected output, and any checks that must happen before it finishes.

Next time I can say, “We’re going to write a project plan. Load my project-planning skill and start.” The agent already knows the process. It can inspect the new material, interview me about this project, confirm the brief, and build the plan.

That’s where many complex prompts belong now. The prompt still exists, but it lives in a reusable skill and loads when the job needs it. The chat message only tells the agent which job we’re doing today.

If the task stops needing judgement and becomes a fixed series of steps, I’ll move it again, into code or a workflow.

Choose the model and reasoning level

Model choice can matter as much as the prompt.

Simple extraction, classification, and formatting work may suit a small, cheap model. Architecture, difficult debugging, research, and decisions with competing constraints usually justify more reasoning effort.

I don’t add “think step by step” to every request. Wharton’s second Prompting Science report found small gains on some reasoning models, worse results on another, and response times 20% to 80% longer. Several non-reasoning models also made new mistakes on easy questions after being told to reason step by step.

Where the model exposes a reasoning setting, I use that. Where I need to review the basis for an answer, I ask for evidence, assumptions, calculations, or a short explanation I can check. A long written chain of thought isn’t proof that the answer is right.

Smaller models can also be more sensitive to format. He, Rungta, Koleczek, Sekhon and others found large swings from plain text, Markdown, JSON, and YAML on some tasks, with preferences changing between model generations. If I’m running a high-volume task on a cheap model, I test the format. For frontier models, I usually choose whatever is easiest for the surrounding system to produce and parse, then verify it on my own examples.

There is no prompt format that wins everywhere. Even current vendor advice differs. OpenAI has recommended XML-style structure for parts of the GPT-5 family, while Anthropic now favours plain language and headings for its newest models.

Make uncertainty acceptable

I tell the model what to do when the material doesn’t support an answer.

For example:

If the supplied sources don’t support a claim, say the information is missing. Separate sourced facts from your inferences and list anything that still needs checking.

This won’t make hallucinations disappear, but it removes the pressure to fill every gap with a polished guess.

You still need to check important outputs against the source.

What about the old prompt tricks?

The evidence now backs that up. Wharton tested in-domain expert personas across six models and found no significant factual improvement across almost all of them. A USC study saw MMLU accuracy fall as the persona became longer. I’ll ask for a sceptical buyer’s view, but I won’t tell the model it’s a senior physicist and expect the physics to improve.

Examples remain useful when a format is easier to show than describe. I start with one good example and check every detail. Methods such as self-consistency, Tree of Thoughts and ReAct belong in the system around the prompt because independent samples, search trees and tool loops need separate model calls.

When prompting becomes context engineering

Once you build agents or AI features, the user’s prompt is only part of what the model sees.

The rest may include system instructions, conversation history, retrieved documents, tool descriptions, tool results, memory, source code, examples, and whatever your application keeps when the context window fills.

Anthropic reported removing more than 80% of Claude Code’s system prompt for its Opus 5 and Fable 5 models with no measurable loss on its coding evaluations. Years of instructions had built up and some contradicted each other. The model had to sort those out before doing the work.

I see the same pattern in agent systems. We add a rule whenever something goes wrong and rarely remove it later. The instruction file slowly becomes a list of every problem the system has ever had.

Keep always-loaded instructions light. Put local knowledge and genuine guardrails there. Load detailed material when the task needs it. Keep tool guidance with the tool. Use working code, tests, examples, and rubrics as references instead of trying to restate them all in the system prompt.

Prompt engineering improves the request itself. Context engineering controls what the model sees around that request. Production systems need both, but context is where much of the work now sits.

If you’ll use the prompt twice, measure it

For repeatable work, I build a small eval set before I spend much time tuning the prompt.

It should contain ordinary examples, difficult ones, known failures, and the mistakes that would be expensive. Decide what a good answer looks like, run the set on the intended model and reasoning level, then make one change at a time.

This is close to the loop in OpenAI’s GPT-5.2 guidance: choose the model and reasoning effort, run evals, adjust where results fall short, then run the evals again.

Without that loop, prompt editing is mostly judgement based on a few memorable examples. A new version can look better while quietly damaging cases you didn’t test.

Once you have a useful metric, software can search prompt variations faster than a person. GEPA, an ICLR 2026 oral paper, improves prompts by reviewing execution traces and proposing new instructions. Its authors reported better results than MIPROv2 and a reinforcement-learning baseline with far fewer model runs. It can start with as few as ten examples and is available through DSPy or as a standalone library.

The metric is the hard part. If you can’t explain how you’ll score the answer, you’re not ready to optimise the prompt.

Sources

Vendor engineering

• Anthropic, The new rules of context engineering for Claude 5 generation models (24 July 2026): https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
• Anthropic, A field guide to Claude Fable 5: Finding your unknowns (6 July 2026): https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns
• Anthropic, Best practices for prompt engineering: https://claude.com/blog/best-practices-for-prompt-engineering
• Anthropic, Effective context engineering for AI agents: https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• OpenAI Cookbook, GPT-5.1 prompting guide: https://developers.openai.com/cookbook/examples/gpt-5/gpt-5-1_prompting_guide
• OpenAI Cookbook, GPT-5.2 prompting guide: https://github.com/openai/openai-cookbook/blob/main/examples/gpt-5/gpt-5-2_prompting_guide.ipynb

Controlled studies

• Meincke, Mollick, Mollick and Shapiro, Prompting Science Report 1: Prompt Engineering is Complicated and Contingent: https://arxiv.org/pdf/2503.04818
• Meincke et al., Prompting Science Report 2: The Decreasing Value of Chain of Thought in Prompting: https://arxiv.org/abs/2506.07142
• Meincke et al., Prompting Science Report 3: I’ll pay you or I’ll kill you, but will you care?: https://arxiv.org/abs/2508.00614
• Basil, Shapiro, Mollick, Mollick and Meincke, Prompting Science Report 4: Playing Pretend: Expert Personas Don’t Improve Factual Accuracy: https://arxiv.org/pdf/2512.05858
• Expert Personas Improve LLM Alignment but Damage Accuracy (USC, PRISM): https://arxiv.org/pdf/2603.18507
• He, Rungta, Koleczek, Sekhon et al., Does Prompt Formatting Have Any Impact on LLM Performance?: https://arxiv.org/pdf/2411.10541
• Does Tone Change the Answer? Evaluating Prompt Politeness Effects on Modern LLMs: https://arxiv.org/pdf/2512.12812
• Mind Your Tone: Investigating How Prompt Politeness Affects LLM Accuracy (Penn State): https://arxiv.org/pdf/2510.04950
• Agrawal et al., GEPA: Reflective Prompt Evolution Can Outperform Reinforcement Learning (ICLR 2026): https://arxiv.org/pdf/2507.19457
• AutoPDL: Automatic Prompt Optimization for LLM Agents: https://arxiv.org/pdf/2504.04365