Evidence-Based Prompt Engineering: The 2026 Update

Seven takeaways

1. 01The unit of prompt design is expanding from the prompt to the context. For long-running agents, system instructions, tools, retrieved information, history, memory, and intermediate state must be designed together.
2. 02Native reasoning controls should generally take precedence over manually forcing chain-of-thought. OpenAI, Anthropic, and Google now expose mechanisms for controlling reasoning effort or thinking behavior, and each provides guidance that reduces the need for explicit step-by-step reasoning instructions on native reasoning models.
3. 03More reasoning is not automatically better. Research has documented cases where increasing test-time compute reduces accuracy, while newer work finds that reasoning models can allocate their available compute poorly across multiple questions.
4. 04Structured output remains useful, but the cost of structure depends on model capacity and task difficulty. Constrained decoding can eliminate formatting failures, but it cannot guarantee semantic correctness. When a model is close to its reasoning limit, separating reasoning from serialization remains valuable.
5. 05Long context is not free context. Recent research suggests that model performance can deteriorate as context grows, even when the information remains technically available. The familiar "lost in the middle" phenomenon also appears to depend heavily on retrieval quality and model choice in realistic RAG systems.
6. 06Tool reliability has become a first-class prompting concern. Agents operating with imperfect tools can fail even when they perform well in clean benchmark environments. The critical capability is often diagnosing and recovering from failures rather than simply making more tool calls.
7. 07Automatic prompt optimization is becoming practical, but evaluation remains essential. GEPA demonstrates that reflective prompt optimization can substantially outperform earlier optimization methods while requiring far fewer rollouts. Its effectiveness still depends on having a meaningful feedback or evaluation signal.

Executive summary

Prompt engineering has changed considerably over the past year.

The basic discipline remains important. Clear instructions, useful context, appropriate examples, and well-defined outputs can still improve the quality of an AI system. Several findings from the earlier Promptivo research remain well supported: personas do not reliably improve factual accuracy, chain-of-thought prompting is conditional rather than universally beneficial, and rigid output constraints can interfere with reasoning on some models.

At the same time, the center of gravity has moved.

For increasingly capable models and especially for AI agents, the prompt is only one component of the system being designed. The model may receive a system instruction, conversation history, retrieved documents, tool definitions, tool results, memory, intermediate artifacts, and information gathered during previous steps. The quality of the final result depends on how that entire context is assembled and managed.

This has given rise to a broader discipline commonly called context engineering.

The change matters because many of the rules that worked well for earlier generations of language models were really solutions to narrower problems. A developer working with a one-shot text-generation model could reasonably focus on wording, examples, and output instructions. An agent conducting research over dozens of tool calls faces a different engineering problem. It must decide what information to retain, what to retrieve, what to discard, when to use a tool, how to recover from tool failures, and how much reasoning effort to spend on each step.

The research reviewed for this update suggests several practical conclusions:

1. 01The unit of prompt design is expanding from the prompt to the context. For long-running agents, system instructions, tools, retrieved information, history, memory, and intermediate state must be designed together.
2. 02Native reasoning controls should generally take precedence over manually forcing chain-of-thought. OpenAI, Anthropic, and Google now expose mechanisms for controlling reasoning effort or thinking behavior, and each provides guidance that reduces the need for explicit step-by-step reasoning instructions on native reasoning models.
3. 03More reasoning is not automatically better. Research has documented cases where increasing test-time compute reduces accuracy, while newer work finds that reasoning models can allocate their available compute poorly across multiple questions.
4. 04Structured output remains useful, but the cost of structure depends on model capacity and task difficulty. Constrained decoding can eliminate formatting failures, but it cannot guarantee semantic correctness. When a model is close to its reasoning limit, separating reasoning from serialization remains valuable.
5. 05Long context is not free context. Recent research suggests that model performance can deteriorate as context grows, even when the information remains technically available. The familiar "lost in the middle" phenomenon also appears to depend heavily on retrieval quality and model choice in realistic RAG systems.
6. 06Tool reliability has become a first-class prompting concern. Agents operating with imperfect tools can fail even when they perform well in clean benchmark environments. The critical capability is often diagnosing and recovering from failures rather than simply making more tool calls.
7. 07Automatic prompt optimization is becoming practical, but evaluation remains essential. GEPA demonstrates that reflective prompt optimization can substantially outperform earlier optimization methods while requiring far fewer rollouts. Its effectiveness still depends on having a meaningful feedback or evaluation signal.

The practical lesson is straightforward: effective prompt engineering is becoming less about discovering a universal prompt formula and more about matching instructions, context, reasoning effort, tools, and output constraints to the actual workload.

That is the approach Promptivo takes.

01What still holds

The rapid development of reasoning models and agents has changed the field, but it has not invalidated the basic findings of prompt-engineering research.

Several conclusions from the original Promptivo whitepaper remain useful.

1.1 Personas do not buy factual accuracy

Telling a model to "act as a senior financial analyst," "act as a world-class scientist," or "act as an expert lawyer" remains a popular prompting technique.

The evidence does not support treating personas as a general-purpose accuracy intervention.

The earlier Promptivo review found that expert personas do not reliably improve factual or analytical performance. Zheng et al. tested 162 personas across four model families and found no general accuracy improvement over a no-persona control. A later Wharton replication likewise found no significant gains and several significant losses.

Personas can still serve legitimate purposes. They can establish voice, perspective, communication style, or role expectations in tasks where those characteristics matter. Creative writing, customer support, and certain forms of simulation are different from factual question answering.

The distinction is important because it prevents a stylistic technique from being mistaken for a reasoning intervention.

Promptivo therefore continues to treat personas as conditional components rather than default instructions. The question is whether the requested role changes the behavior the task actually requires.

1.2 Chain-of-thought remains useful, but only in the right setting

The early chain-of-thought literature established an important result: asking sufficiently capable language models to reason through a problem can substantially improve performance on difficult reasoning tasks.

That result remains relevant.

The problem is that the models themselves have changed.

Modern reasoning models can perform substantial internal reasoning before producing their final answer. In those systems, manually adding "think step by step" may duplicate behavior the model already performs. In some situations it can even make performance worse.

The earlier Promptivo paper already treated chain-of-thought as conditional. The 2026 evidence strengthens that position.

The correct question is no longer simply whether a prompt should contain a reasoning scaffold. It is whether the target model needs one.

1.3 Positive framing, examples, and other techniques remain conditional

The same principle applies to several other techniques that have circulated as prompting rules.

Positive instruction phrasing can outperform negative instructions in some settings. Few-shot examples can strongly shape behavior. Politeness and emotional framing can influence outputs under particular conditions.

None of these findings justify turning the technique into an unconditional rule.

The research package for this update retains these findings as areas where the evidence is useful but conditional. The larger lesson is consistent with the original Promptivo methodology: a prompting technique should earn its place through measured performance on the task at hand.

02The big shift: from prompt engineering to context engineering

The most important development in prompt engineering over the past year is conceptual.

The prompt is no longer the whole object of design.

Anthropic describes context engineering as the broader discipline of determining what configuration of information is most likely to produce the desired behavior from a model. This includes system instructions, tools, external information, message history, and other state available during inference.

A 2025 survey of context engineering similarly describes the field as encompassing context retrieval, context generation, context processing, and context management, with applications including RAG, memory systems, tool-integrated reasoning, and multi-agent systems.

This distinction becomes particularly important with agents.

Consider a research agent working on a complex assignment. Its effective input may include:

• A system prompt
• The user's original objective
• Constraints and preferences
• Previous conversation history
• Retrieved documents
• Search results
• Tool definitions
• Tool outputs
• Notes created during the task
• Intermediate conclusions
• Errors encountered earlier
• Information deliberately removed through context management

A developer who focuses only on the wording of the system prompt is designing one part of the system while leaving the rest largely unmanaged.

2.1 Context has a budget

Longer context windows create an obvious temptation: put everything in.

The research increasingly suggests that this is a poor default.

Anthropic describes context as a finite resource with diminishing marginal returns. Its guidance recommends identifying the smallest set of high-signal information that gives the model the strongest chance of producing the desired result.

The implication is subtle.

"Give the model more context" is not a universal improvement strategy. The relevant question is whether the additional context increases useful information faster than it increases distraction, ambiguity, retrieval burden, or competition for attention.

That makes context selection an optimization problem.

2.2 Retrieval becomes part of prompt engineering

Traditional prompting treats the information supplied to a model as mostly static.

Agentic systems increasingly retrieve information dynamically.

Rather than placing an entire knowledge base into the initial context, an agent can retain lightweight references and retrieve specific information when needed. Anthropic calls this a "just in time" approach to context management.

This changes the design question from:

What should I put in the prompt?

to:

What information should the model have now, and what information should it be able to retrieve later?

That is a much broader engineering problem.

2.3 Memory and compaction

Long-running agents create another problem. The relevant history eventually exceeds the practical working context.

Two approaches have become particularly important.

Compaction summarizes an accumulated interaction and starts a new context using the condensed state.

Structured note-taking stores important information outside the active context and retrieves it later.

Anthropic also describes multi-agent architectures in which specialized agents perform focused exploration and return condensed findings to a coordinating agent.

The empirical support is starting to arrive. Lodha et al. measured an enterprise tool-using agent under four context policies and found that retaining only the most recent tool interactions, with automated summarization of the rest, matched or beat full-history retention on task completion while cutting tokens and wall-clock time substantially.

These approaches all address the same underlying constraint: a system cannot indefinitely preserve every detail in its active context and still expect the model to treat every token equally.

03Prompting reasoning models

The arrival of native reasoning models has changed how developers should think about instructions such as "show your work" and "think step by step."

3.1 Use native reasoning controls first

Major model providers increasingly expose direct controls over reasoning behavior.

OpenAI provides reasoning-effort controls that allow developers to trade off reasoning depth, latency, and token usage. Current OpenAI guidance recommends selecting reasoning effort based on the workload and validating the choice through representative evaluations rather than assuming that the highest setting is always preferable.

Google's Gemini models similarly provide thinking controls and dynamically adjust reasoning effort based on task complexity. Google's documentation recommends lower thinking levels for simple tasks and greater reasoning effort for difficult mathematical, coding, and planning tasks.

Anthropic's guidance likewise emphasizes extended thinking capabilities rather than relying on manually constructed reasoning scaffolds.

This convergence across providers is significant.

The model now has a native mechanism for allocating reasoning effort. Prompt authors should generally use that mechanism before attempting to reproduce it through elaborate instructions.

3.2 Explicit chain-of-thought can become redundant

A native reasoning model has already been trained to reason internally.

Adding a detailed instruction such as:

First identify the problem. Then list the assumptions. Then reason through each step. Then check your work. Then provide the answer.

may provide useful structure in some cases. It can also create unnecessary instruction overhead or interact poorly with the model's native reasoning process.

The practical default for native reasoning models should therefore be simpler:

State the task clearly, provide the necessary context, define important constraints, select an appropriate reasoning level, and specify the desired final output.

The model should do the reasoning it was trained to do.

Google explicitly advises that asking thinking models to expose their reasoning is generally unnecessary, while Anthropic similarly recommends using extended thinking rather than manually recreating chain-of-thought.

04More thinking is not always better

One of the more important findings in recent reasoning research is that test-time compute does not produce a simple upward performance curve.

4.1 Inverse scaling

Gema et al. found tasks where increasing reasoning length systematically reduced performance. The authors identified several failure modes, including distraction by irrelevant information, overfitting to problem framing, reliance on spurious correlations, and difficulty maintaining focus during extended deduction.

This finding matters because a common intuition is that reasoning behaves like a volume knob:

more tokens, more thinking, better answer

The evidence does not support that relationship as a universal law.

Longer reasoning can introduce additional opportunities for the model to become distracted, lock onto an incorrect interpretation, or reinforce a bad intermediate assumption.

4.2 Reasoning models also struggle with compute allocation

A separate 2026 study examined a related but distinct problem: how reasoning models allocate a limited compute budget across multiple questions.

Fan et al. found that models often behaved like greedy sequential solvers. They tended to front-load effort on earlier questions and did not reliably allocate compute according to question difficulty or value. Explicit planning prompts improved the distribution somewhat, but did not produce reliable value-aware allocation.

This introduces a useful distinction between two questions:

1. 01How much should the model think about a particular problem?
2. 02How should a system distribute its total reasoning budget across a collection of problems?

The second remains an important unsolved engineering problem.

4.3 Calibrate reasoning effort

For practitioners, the implication is straightforward.

Do not treat maximum reasoning effort as the default.

Instead:

• Establish a baseline at a lower effort level.
• Test representative tasks.
• Increase reasoning effort when the measured benefit justifies the added cost and latency.
• Test whether additional reasoning actually improves the failure modes that matter.
• Watch for tasks where extended reasoning makes performance worse.

OpenAI's current guidance makes a similar recommendation, describing reasoning effort as a tuning parameter that should be selected according to task characteristics and validated through evaluations.

05When not to ask for explicit chain-of-thought

For native reasoning models, the old instruction "think step by step" deserves a narrower role.

There are still situations where structured reasoning instructions can be useful, particularly when a model needs to follow a specific external procedure, check dependencies, or perform a domain-specific workflow.

But asking a native reasoner to reproduce an explicit chain of thought is usually unnecessary.

Three major providers now converge on this general direction:

• OpenAI: use reasoning controls and task-specific instructions rather than relying on generic reasoning prompts.
• Anthropic: use extended thinking when deeper reasoning is needed instead of manually constructing chain-of-thought scaffolding.
• Google: thinking models reason internally and generally do not require prompts asking them to expose their reasoning.

The more useful prompt instruction is often about what must be considered, rather than how many visible reasoning steps must be written.

For example:

Before answering, verify the numerical assumptions, identify any material uncertainty, and check whether the recommendation depends on an unstated constraint.

This gives the model a quality criterion without prescribing an artificial reasoning transcript.

06Structured outputs and the format tax

Structured output remains one of the most useful capabilities for production AI systems.

Applications often need JSON, XML, SQL, typed function arguments, database records, or other machine-readable formats.

The research, however, has become more nuanced.

6.1 Structure can consume capacity

Earlier work showed substantial performance losses when models were forced into rigid output formats during reasoning tasks.

New research suggests that this phenomenon depends heavily on model capacity.

Hengxin Fan's 2026 preprint, Capacity, Not Format, found that capable models can absorb structured-output constraints with little degradation, while weaker or capacity-constrained models can suffer substantial performance losses. Across four models and five benchmarks, a model with headroom held its accuracy under JSON constraints, while smaller models lost tens of percentage points, partly through truncation and partly through the constraint itself. The study also found that schema complexity matters.

This suggests that "JSON hurts reasoning" is too broad a statement.

A better formulation is:

Structured output can impose a capacity cost, particularly when the model is already operating near its limits.

6.2 Constrained decoding solves one problem

Constrained decoding provides another important development.

It can guarantee that an output conforms to a specified structural grammar. Chavan's 2026 study found that constrained decoding eliminated structural failures in the evaluated small models, but semantic errors remained.

That distinction is fundamental.

A valid JSON object can still contain the wrong answer.

A syntactically valid function call can still invoke the wrong function.

A schema can guarantee shape. It cannot guarantee meaning.

6.3 Reason first, serialize second

For difficult reasoning tasks, the most robust pattern remains to separate the reasoning problem from the serialization problem where possible.

The system can reason about the task and then produce the required structured representation.

This approach is especially useful when:

• The model is operating near its capacity limit.
• The schema is complex.
• The task requires multi-step reasoning.
• Semantic accuracy matters more than immediate parseability.

For straightforward extraction tasks, strict structured output may carry little practical cost. The appropriate level of constraint should therefore depend on the workload.

07Tool calling: reliability becomes the bottleneck

AI agents increasingly depend on tools.

A model may search the web, query a database, execute code, read files, call an API, or modify an external system.

This creates a new category of failure that ordinary prompt benchmarks do not capture well.

7.1 A valid tool call can still produce a failed task

An agent may select the correct tool and still fail because:

• The tool returns an error.
• The tool specification has changed.
• The result conflicts with another source.
• The output is incomplete.
• A transient failure occurs.
• The agent misinterprets the result.
• A previous tool call changed the state of the environment.

Tian et al.'s ToolBench-X study introduced recoverable tool-environment hazards and found a substantial gap between agent performance under reliable conditions and performance when tools behaved imperfectly. The authors found that failures were driven less by the number of tool calls than by weak diagnosis and recovery.

This changes what a good tool-use prompt should contain.

A production agent needs instructions for recovery, verification, and escalation, not simply instructions for making the initial call.

7.2 Programmatic tool calling

Another emerging development is programmatic tool calling.

Patel et al. compared programmatic tool calling with conventional JSON tool calling across 14 models on the BFCL v4 benchmark and found that code-based tool use matched or exceeded JSON-based calling on 11 of the 14. The approach also performed particularly well in parallel tool-use settings.

This is still a relatively new research area, so the result should not be treated as a universal replacement for function calling.

It does, however, illustrate a broader trend: the interface between the model and its tools is becoming part of prompt and context engineering.

The best interface may depend on the model, task, tool environment, and degree of parallelism required.

08Long context, context rot, and lost in the middle

The growth of context windows has changed expectations about what language models can process.

It has not eliminated the problem of context management.

8.1 Context rot

Chroma's 2025 technical report introduced the term "context rot" to describe degradation as the number of input tokens increases. The report evaluated 18 frontier models and found performance degradation with increasing input length, including cases where coherent collections of information produced greater difficulty than shuffled material.

Anthropic's engineering guidance draws a similar practical conclusion: context should be treated as a finite resource rather than an unlimited storage area.

The important shift is from asking whether a model can accept a million tokens to asking whether supplying those tokens improves the outcome.

Those are different questions.

8.2 Lost in the middle needs a more careful interpretation

The original "lost in the middle" research established that models could perform worse when relevant information appeared in the middle of long contexts than when it appeared near the beginning or end.

That finding remains useful, but recent replication work suggests that it should not be treated as a universal law governing every RAG pipeline.

Gabín, Perez, and Parapar found that retrieval quality and model choice interact strongly with document ordering and context size. Findings from controlled settings do not always transfer directly to realistic retrieval pipelines.

This is an important correction.

Prompt designers should not simply move every important fact to the beginning or end and assume the problem is solved.

They should measure their own retrieval and generation pipeline.

8.3 Context length should be an experimental variable

For RAG systems, useful evaluation questions include:

• How does answer accuracy change as retrieved context grows?
• Does additional context introduce contradictory information?
• Does retrieval precision matter more than retrieval volume?
• Does document order affect this particular model?
• Does the model behave differently when irrelevant documents are included?
• At what context size does marginal information stop helping?

The answer will vary by model and application.

That variability is precisely why context engineering needs evaluation rather than folklore.

09RAG prompting in 2026

Retrieval-augmented generation remains one of the most common ways to provide external knowledge to language models.

The basic architecture is straightforward:

retrieve information, place it into context, generate an answer

The engineering details are considerably harder.

The new research suggests that three variables should be considered together:

1. 01Retrieval quality
2. 02Context size
3. 03Document ordering

A retrieval system that returns ten highly relevant documents may behave differently from one that returns fifty documents containing the same ten relevant documents plus forty distractions.

Similarly, a model that performs well with oracle retrieval may perform differently when the retrieval system makes realistic errors.

This means RAG prompting should be evaluated as a pipeline rather than as an isolated prompt.

A strong RAG prompt can help the model understand what retrieved information means, distinguish evidence from instructions, handle conflicts, and cite sources appropriately.

It cannot compensate indefinitely for poor retrieval.

The practical approach is therefore to measure the complete system and determine where the actual failure occurs.

10Automatic prompt optimization

Manual prompt writing is increasingly being supplemented by automated optimization.

The basic idea is simple: instead of relying entirely on a human to decide whether a prompt is good, evaluate the prompt against representative tasks and use the results to generate better candidates.

The challenge is finding an optimization method that can learn useful changes without requiring enormous numbers of model executions.

10.1 GEPA

GEPA, or Genetic-Pareto, represents an important development in this area.

Agrawal et al. introduced a reflective prompt optimizer that examines model trajectories, identifies failures using natural-language feedback, proposes prompt changes, evaluates those changes, and retains complementary improvements.

Across six tasks, GEPA outperformed GRPO by an average of 6 percent and by as much as 20 percent on individual tasks. It also outperformed MIPROv2 by more than 10 percent in the reported experiments while using substantially fewer rollouts.

The result was important enough to receive an Oral presentation at ICLR 2026. GEPA now ships as a built-in optimizer in DSPy 3.x, which puts reflective optimization within reach of ordinary application teams.

10.2 Optimization still needs measurement

Automatic optimization does not eliminate evaluation.

It makes evaluation more important.

An optimizer needs a signal telling it whether one prompt is better than another. That signal can be:

• Accuracy
• Task completion
• Human preference
• Factuality
• Tool success
• Latency
• Cost
• A domain-specific score

Without a meaningful evaluation signal, prompt optimization becomes a search process without a reliable definition of success.

This is why Promptivo's original emphasis on evidence and conditional rules remains relevant even as automated optimization becomes more sophisticated.

11What the major providers now agree on

One of the most useful developments in 2025 and 2026 is the increasing convergence of official guidance from the major model providers.

The providers differ in implementation, model architecture, and terminology, but several themes recur.

OpenAI

Current OpenAI guidance emphasizes:

• Choosing reasoning effort according to task requirements
• Controlling output verbosity separately from reasoning depth
• Using explicit output contracts
• Defining tool behavior and dependencies clearly
• Running representative evaluations before changing prompts
• Increasing reasoning effort only when measured performance justifies the additional cost
• Using context management for long-running workflows

Anthropic

Anthropic's guidance emphasizes:

• Clear and direct system prompts
• Appropriate examples
• Efficient tool definitions
• Dynamic retrieval
• Compaction
• Structured note-taking
• Sub-agent architectures
• Extended thinking when appropriate

Google

Google's current Gemini documentation emphasizes:

• Native thinking capabilities
• Dynamic reasoning effort
• Adjustable thinking levels
• Lower reasoning for simple tasks
• Higher reasoning for complex tasks
• Avoiding unnecessary requests for visible reasoning

The convergence is striking.

Across providers, the direction is toward less arbitrary prompting and more deliberate system design.

12The Promptivo approach in 2026

The research changes some of the implementation details of evidence-based prompting, but it reinforces the core Promptivo thesis.

A good prompt should be assembled according to the task and the model rather than copied from a universal template.

The 2026 update expands that principle.

Promptivo's six-section structure remains useful:

1. 01Role
2. 02Context
3. 03Task
4. 04How to approach
5. 05Constraints
6. 06Output format

What changes is how those sections are populated.

Role

Use role or persona instructions when they meaningfully affect the requested behavior.

Do not add an expert identity simply because it sounds authoritative.

Context

Provide the information the model actually needs.

For agentic systems, context also includes retrieved information, tool results, memory, and relevant state.

Task

State the desired outcome precisely.

A capable model still benefits from knowing what constitutes completion.

How to approach

Use this section selectively.

For a non-reasoning model performing a difficult reasoning task, an explicit reasoning scaffold may be useful.

For a native reasoning model, focus more on the substantive checks, criteria, dependencies, and decision rules that matter to the task.

Constraints

Constraints should protect important requirements without creating unnecessary competition for model capacity.

If a constraint exists because a downstream system requires a specific schema, enforce it. If it exists merely because a prompt template has always included it, test whether it is helping.

Output format

Use the least restrictive format that satisfies the actual requirement.

When structured output is necessary, use structured generation or constrained decoding where appropriate. For demanding reasoning tasks, consider separating reasoning from serialization.

13A practical decision tree for prompt engineering

The following decision process summarizes the evidence reviewed in this paper.

Step 1: Is the task simple?

If the task is straightforward extraction, classification, rewriting, or transformation, start with a concise prompt.

Do not add elaborate reasoning instructions unless evaluation shows a need.

Step 2: Is the target model a native reasoning model?

If yes, start with the model's native reasoning controls.

Avoid automatically adding "think step by step."

Step 3: Does the task require substantial reasoning?

If yes, test reasoning effort levels against representative examples.

Do not assume maximum effort is optimal.

Step 4: Does the output need a strict schema?

If no, allow the model to use a natural output format.

If yes, determine whether the model has sufficient capacity and whether constrained decoding is available.

For difficult reasoning tasks, consider separating reasoning from serialization.

Step 5: Does the task involve external information?

If yes, design retrieval and context selection as part of the system.

Do not assume that more retrieved information is automatically better.

Step 6: Does the task run across many turns or tool calls?

If yes, design context management.

Consider:

• Compaction
• Persistent notes
• Selective retrieval
• Tool-result pruning
• Sub-agents
• Explicit state tracking

Step 7: Does the system use external tools?

If yes, define recovery behavior.

Test not only successful calls but:

• Invocation failures
• Missing results
• Conflicting results
• Changed tool specifications
• Partial failures
• Invalid outputs

Step 8: Can the prompt be evaluated automatically?

If yes, establish an evaluation set.

Once a reliable evaluation signal exists, consider automatic prompt optimization.

Promptivo runs this decision process for you: the prompt builder keys persona, reasoning scaffold, and format strictness on the task and the target model, replaces the scaffold with task-specific verification checks on native reasoning models, ends every prompt with a testable Done when block, and, for agents, adds tool recovery and context-management rules.

14The new standard: evidence over prompt folklore

The central lesson of the 2026 research is methodological.

Prompt engineering is moving away from universal rules.

The field has accumulated enough evidence to show why this matters. Personas help some tasks and fail to improve others. Chain-of-thought can improve reasoning in one model class while reducing performance in another. Structured output can be harmless for a capable model and costly for a constrained one. Longer reasoning can improve difficult tasks while hurting others. More context can provide valuable information while simultaneously reducing the model's ability to use that information effectively.

These findings can appear contradictory if prompting is viewed as a collection of techniques.

They become much easier to reconcile when prompting is treated as an engineering discipline.

Every intervention changes the information and constraints presented to a model. The effect depends on the model, the task, the context, and the available computational budget.

That is why the same prompt can perform differently after a model upgrade.

It is also why copying a prompt from another application can produce disappointing results.

The prompt was designed for a different system.

15Conclusion

Prompt engineering has entered a more mature phase.

The early discipline focused heavily on discovering effective phrases: assign a persona, ask the model to think step by step, provide examples, specify a format, and place important information in particular positions.

Those techniques still have value. The evidence simply shows that their effects are conditional.

The larger change is that modern AI systems have become complex enough that the prompt can no longer be treated in isolation.

For an agent, the effective input includes its instructions, available tools, retrieved information, history, memory, intermediate state, and the results of actions taken during the task. Managing that information is now part of the engineering problem.

Reasoning models add another layer. Native reasoning controls make it possible to allocate computational effort directly, while recent research shows that additional reasoning can sometimes reduce accuracy or be allocated poorly. Structured outputs remain valuable, but their cost depends on model capacity and task difficulty. Tool use requires recovery strategies, not merely function schemas. Long contexts require active management. RAG systems need to be evaluated as complete pipelines. Automatic prompt optimization is becoming increasingly effective, but only when paired with meaningful evaluation.

The practical consequence is a change in mindset.

The goal is not to write the longest prompt, the most sophisticated prompt, or the prompt containing the largest collection of established techniques.

The goal is to construct the smallest, clearest, most appropriate set of instructions and context that reliably produces the behavior the task requires.

That is the standard Promptivo applies.

Evidence should determine which techniques are used. Model capability should determine how they are applied. Evaluation should determine whether they work.

As AI systems become more capable, that discipline becomes more important, not less.

Sources and further reading

Evidence status is marked for each entry. Every arXiv identifier was re-fetched and matched on title, authors and date before publication.

This paper incorporates the September 2026 Promptivo research package, which identifies peer-reviewed research, arXiv preprints, provider documentation, and industry technical reports by evidence status, and recommends distinguishing peer-reviewed work from preprints and provider or industry material when presenting conclusions.

Frequently asked questions