Is prompt engineering really dead?

The term remains useful, but a dependable application requires teams to design everything the model receives and everything that controls its actions, beyond the wording of one request. The prompt remains the visible instruction. The context adds data, examples, history, tools and rules. Evaluations determine whether the complete system works on business cases.

Should every prompt use XML?

XML can separate the parts of a complex context, while clear prose, Markdown headings or a native schema may suit other tasks better. A short request can remain in prose. Multiple documents often benefit from explicit delimiters. Machine-readable output should use the API's structured-output or tool-calling feature where available.

What is the difference between prompt engineering and context engineering?

Prompt engineering develops the instruction, whereas context engineering organises all the information and capabilities available when the model must answer or act. The instruction describes the task and its constraints. The context brings together useful references, examples, state and history. Tools, permissions and schemas bound actions and outputs.

Does a non-technical team need to learn XML?

A business team mainly needs to define a testable task, while a designated owner can translate that definition into the format suited to the model and application. Subject-matter experts supply success criteria and edge cases. The owner maintains the template and evaluation set. Users fill stable fields rather than rewriting the instruction each time.

Does a structured instruction prevent prompt injection?

Separating instructions from data reduces some ambiguity, but it is only one layer of a defence that must also limit permissions and review consequential actions. Treat all external content as untrusted. Limit accessible tools and data. Require human approval when an action has serious consequences. Test attacks that represent the actual process.

Does markup replace RAG or fine-tuning?

Markup organises a request, RAG selects references and fine-tuning changes model behaviour, so the three techniques address different problems. Use RAG to supply current or private knowledge. Use a schema to obtain machine-readable output where the API supports it. Consider fine-tuning only after examples and evaluation criteria are stable.

Transition Management

Beyond prompt engineering: designing reliable context for AI

19 May 2026 · Updated on 6 September 2026 · 8 min read · Paul-Antoine Tual

context engineering prompt engineering AI Junyr Method SME AI agents

By Paul-Antoine TUAL, AI Transformation Leader, Croissance et Transitions. Updated 6 September 2026.

A prompt is only one part of the system

ChatGPT’s conversational interface, launched on 30 November 2022, made AI accessible, but professional use depends less on a ‘perfect phrase’ than on the quality of everything supplied to the model.

A standalone request can be enough to explore, rephrase or summarise a short text.
An application adds references, examples, history, tools, permissions and an output format.
Each element consumes part of the context window and may reinforce, contradict or bury an instruction.
The discipline of assembling and testing that context is often called context engineering [1].

This development does not make prompt engineering obsolete; it places it inside an engineering cycle in which success criteria and evaluations come before instruction tuning [2].

The prompt states the task, tone, constraints and expected result.
The context supplies only the information needed for that task.
Evaluation measures quality, robustness, cost and latency on representative cases.
A persistent failure may require a different model, retrieval method, tool or business rule rather than a longer prompt.

What a leader needs to know about how an LLM works

An LLM produces a response token by token from its context and inference settings, which explains its fluency, its variability and the need to verify its output.

Tokenisation: text is divided into units that the model represents numerically.
Prediction: the transformer calculates a probability distribution for the next token.
Attention: the model weights relationships among items in the context.
Generation: the answer results from a sequence of probabilistic choices, with no inherent guarantee of truth or business compliance.

Available context length does not guarantee equal use of every item, because lost in the middle experiments show that the position of relevant information can affect performance on some long-context tasks [3].

Place the question and critical constraints where the chosen model’s guidance recommends.
Remove documents that do not directly support the requested decision.
Identify sources and separate data, examples and instructions clearly.
Test several positions and context sizes on the business evaluation set instead of applying a universal rule.

What a chat interface conceals in production

A conversation allows a user to rephrase and correct the next turn, whereas an automated process must make assumptions, inputs, outputs and error handling explicit from the outset.

Politeness or a persona may guide tone, but cannot replace a testable task definition.
Terms such as ‘urgent’, ‘complete’ or ‘high risk’ need a business rule or threshold.
Data injected by a user or external document must be treated as untrusted input.
Output intended for software must follow a controlled schema, ideally through the API’s structured-output feature.

Vendors converge on clarity, not one universal format

Anthropic, OpenAI and Google all recommend precise instructions and clearly separated parts, but their guidance permits several valid forms depending on the model, complexity and intended output [4][5][6].

Anthropic recommends descriptive XML tags in complex prompts to distinguish instructions, context, documents and examples [4].
OpenAI emphasises simple, direct, consistent instructions and iteration based on evaluations [5].
Google presents XML tags, Markdown headings and delimiters as structural options to use consistently [6].
When software consumes JSON, structured-output or tool-calling features are safer than a textual request to ‘reply in JSON’.

Research results from one domain can inform a design without yielding a percentage that transfers to every process, model or industry.

A clinical study combines RAG and prompt engineering to interpret hepatitis C guidelines; it cannot isolate the effect of markup or predict an SME’s gain [7].
Structured-output benchmarks compare defined models, formats and tasks; their scores do not replace testing on the company’s actual documents [8].
A training decision should begin with the company’s tasks, errors and controls rather than a generic percentage of employees trained.

When markup adds little

Markup earns its place when it clarifies a real boundary or hierarchy, but adds noise when it mechanically wraps a short request that is already unambiguous.

Short prose: a simple rewrite or classification may need only one sentence and the required format.
Markdown: readable sections often suit a prompt maintained jointly by business and technical teams.
XML: descriptive tags can isolate several documents, examples or data blocks.
Native schema: an API’s structured-output feature is preferable when a downstream system requires exact fields and types.

The choice should follow a controlled comparison rather than taste, because a template is useful only when it improves a relevant criterion without an excessive cost or maintenance burden.

Build a small set of normal, difficult and prohibited cases.
Compare the simple and structured versions with the same model and settings.
Measure business accuracy, format compliance, omissions, cost and latency.
Keep the simplest form that meets the agreed thresholds.

Do more capable models reduce the need for structure?

A better model may handle more requests in prose, but governed production still requires an explicit contract among the business, the application and the model.

Structure makes variable fields and responsibilities visible to people.
Version control connects a change to a measured variation in output.
Edge cases prevent a persuasive demonstration being mistaken for stable quality.
Re-evaluation after each significant model change is more useful than predicting an arbitrary lifespan for XML.

Four practical decisions for an SME

An SME can make its use of AI more professional without turning every employee into a prompting specialist, provided that it assigns responsibility and focuses effort on processes with meaningful consequences.

Teach task specification: define the objective, authorised references, success criteria and escalation cases.
Maintain critical templates: appoint an owner, version changes and associate every version with tests.
Govern agents: restrict their tools, data and permissions, then require human approval for consequential actions.
Prepare portability: separate business logic from vendor-specific syntax and test a fallback when continuity warrants it.

Three questions for auditing your instructions

Three simple questions quickly show whether critical prompts remain personal tricks or have become managed process components.

Which prompts influence a decision, customer, payment, official document or action on a system?
Who owns each template, its sources, access rights and evaluation set?
Which regression test runs after a change to the prompt, model, retrieval or tool?

The operational foundation proposed by the Junyr Method™

At level 3, ‘Orchestra’, of the Junyr Method™, recurring uses are treated as operational assets: their instruction, inputs, controls and owner become inspectable.

A minimum template separates the task, references, processing rules and expected output.
A versioned library connects each template to an owner, history and evaluation set.
A delegation framework limits tools and provides approvals, logs and recovery procedures proportionate to risk.

The following template illustrates a multi-document task; its tags are descriptive, but their names and presence should be adapted to the model and use case.

<task> states the deliverable and the decision it should inform.
<documents> groups sources under stable identifiers.
<rules> defines the method, exclusions and escalation conditions.
<output> fixes the sections, citations and expected fields.

<task>Compare the documents and produce a decision brief.</task>
<documents>
  <document id="1">…</document>
  <document id="2">…</document>
</documents>
<rules>
  Cite each discrepancy using the document identifier.
  Flag insufficient information rather than filling the gap by assumption.
</rules>
<output>Summary, discrepancies, missing information, recommendation.</output>

Conclusion: specify, test and govern

The durable skill is neither a magic phrase nor XML itself, but the ability to turn a business need into controlled context, verifiable output and a process with a named human owner.

Start with a short instruction and observable success criteria.
Add context, examples or tags only when they resolve an identified failure.
Use native schema and tool features when the model must interact with software.
Rerun evaluations after every change that could affect behaviour.

Review your position in 30 minutes

The free Junyr AI maturity audit is a no-commitment, 30-minute video call that positions the business on the scale, identifies its principal blocker and first sensible project, then provides a one-page follow-up.

Book the audit
Prepare one concrete process, its owner and an example of the current output to make the discussion more useful.

Sources

[1] Andrej Karpathy, post on context engineering, 25 June 2025. x.com
[2] Anthropic, Prompt engineering overview. platform.claude.com
[3] Liu et al., Lost in the Middle: How Language Models Use Long Contexts, 2023. arxiv.org
[4] Anthropic, Prompting best practices. platform.claude.com
[5] OpenAI, Prompting. developers.openai.com
[6] Google, Prompt design strategies. ai.google.dev
[7] So et al., Optimization of hepatological clinical guidelines interpretation by large language models, 2024. Nature
[8] Jiao et al., StructEval: Benchmarking LLMs’ Capabilities to Generate Structural Outputs, 2025. arxiv.org

Paul-Antoine TUAL is an AI Transformation Leader. He heads Croissance et Transitions and develops the Junyr™ suite.

Frequently asked questions

Is prompt engineering really dead?: The term remains useful, but a dependable application requires teams to design everything the model receives and everything that controls its actions, beyond the wording of one request.

The prompt remains the visible instruction.
The context adds data, examples, history, tools and rules.
Evaluations determine whether the complete system works on business cases.
Should every prompt use XML?: XML can separate the parts of a complex context, while clear prose, Markdown headings or a native schema may suit other tasks better.

A short request can remain in prose.
Multiple documents often benefit from explicit delimiters.
Machine-readable output should use the API's structured-output or tool-calling feature where available.
What is the difference between prompt engineering and context engineering?: Prompt engineering develops the instruction, whereas context engineering organises all the information and capabilities available when the model must answer or act.

The instruction describes the task and its constraints.
The context brings together useful references, examples, state and history.
Tools, permissions and schemas bound actions and outputs.
Does a non-technical team need to learn XML?: A business team mainly needs to define a testable task, while a designated owner can translate that definition into the format suited to the model and application.

Subject-matter experts supply success criteria and edge cases.
The owner maintains the template and evaluation set.
Users fill stable fields rather than rewriting the instruction each time.
Does a structured instruction prevent prompt injection?: Separating instructions from data reduces some ambiguity, but it is only one layer of a defence that must also limit permissions and review consequential actions.

Treat all external content as untrusted.
Limit accessible tools and data.
Require human approval when an action has serious consequences.
Test attacks that represent the actual process.
Does markup replace RAG or fine-tuning?: Markup organises a request, RAG selects references and fine-tuning changes model behaviour, so the three techniques address different problems.

Use RAG to supply current or private knowledge.
Use a schema to obtain machine-readable output where the API supports it.
Consider fine-tuning only after examples and evaluation criteria are stable.

Paul-Antoine Tual

AI Transformation Leader · Junyr Method™ · Transition manager specialising in AI for French SMEs and mid-caps. Engineer from the École des Mines de Nantes, lawyer, developer since 1993.

Free AI Maturity Audit →

← All articles