Context engineering: the successor to prompt engineering in AI projects

For a couple of years, prompt engineering was the star skill of generative AI. But in the serious projects I lead, the conversation has changed. What matters is no longer the magic phrase, but everything around it. We call this context engineering. In my view, it is the discipline that decides whether an AI system works in production.

From the magic phrase to the complete context

Prompt engineering focused on how to phrase the question. Context engineering goes much further: it is about designing all the information the model receives in order to respond. That includes the instructions, the retrieved data, the history, the available tools and the safety limits. The quality of the answer depends more on that context than on the skill to write a clever prompt.

Put another way: a powerful model with poor context gives poor answers, and a modest model with good context can shine. That is why the focus has shifted.

What context engineering covers

Information retrieval

Deciding which data is injected into the context and how it is selected is the foundation. This is where the architecture of secure enterprise RAG comes fully into play. Retrieving the right fragment at the right moment is pure context engineering.

Managing the context window

The space a model has to process information is limited and valuable. Knowing what to include, what to summarise and what to discard is an engineering skill, not a writing one. The point is to avoid saturating the window. An overloaded context degrades the answer just as much as a poor one.

Tools and limits

Defining which tools the model can use and with what restrictions is part of the context. This connects directly with security: good context engineering clearly separates instructions from data to reduce the risk of manipulation.

Why it matters in regulated environments

In banking, insurance or public administration, reliability and traceability are not optional. Context engineering makes it possible to control exactly which information underpins each answer, which is essential to audit the system and comply with frameworks such as the EU AI Act. Without control of the context, there is no control of the result.

Context starts with data quality

There is an uncomfortable truth in context engineering: however well you design the context injection, if the data you retrieve is bad, the answer will be bad. A system that searches outdated, duplicated or badly labelled documentation carries those defects into every answer. That is why I consider context and data governance inseparable, and I address it in my article on data governance for AI. Before optimising how information is injected, you have to make sure that information is worth it.

In my projects, much of the context engineering work is actually data work: deciding which sources go in, how they are chunked, how they are updated and who is accountable for their quality. It is not the glamorous part, but it is the one with the most impact on the final result the user perceives.

Common mistakes when building context

The most typical mistake is cramming in too much context, thinking that more information is always better. It is not. A window saturated with irrelevant data confuses the model and drives up cost without improving quality. The art lies in selecting exactly what is needed for each query, not in dumping everything in. Another frequent failing is not measuring. If you don’t check which context fragments led to each answer, you cannot improve the system or explain its decisions.

Keep context lean and current

I also see teams treat context as something static, when in reality it must evolve. Sources change, new ones appear and others become obsolete. A good context design includes a process to review and refresh those sources, just as we maintain any other critical component of a system.

My conclusion is that context engineering professionalises something that started as a trick. We have moved from hunting for the perfect phrase to designing, measuring and maintaining the entire information environment that surrounds the model. That maturity is what distinguishes the AI projects that scale from those that remain a flashy but fragile demo.

In my experience, the difference between an assistant that disappoints and one that delivers real value rarely lies in the model chosen: it lies in the context we give it. The same model, fed with the right information at the right moment, goes from giving generic answers to solving the user’s specific problem. That is why I devote so much effort to designing what information the system retrieves, how it prioritises it and how much fits in the window without diluting what matters.

That context engineering work is, moreover, what transfers best from one project to another. The techniques for selecting, summarising and ordering the relevant information survive changes of model, whereas a prompt perfectly tuned for a specific version ages quickly. Investing in context, and not just in writing instructions, means building on more durable foundations.

Conclusion: engineering beats the trick

Context engineering marks the sector’s maturity: we are leaving behind the tricks and entering engineering. Designing well the context a model receives is what separates a flashy demo from a reliable system in production. Whoever masters this discipline will have the edge in any serious AI project.

Frequently asked questions about context engineering