Academy

From prompt engineering to context engineering

There was a time when the art of working with a model came down to writing a good prompt. But the centre of gravity is shifting: from crafting one instruction to designing the whole context the model works in.

The Felesh team 4 min

What follows is a synthesis of a trend, not the recital of a settled verdict. When working with language models, the centre of gravity is shifting. The primary engineering challenge is no longer writing a single good prompt; today, the larger problem is designing the complete context the model operates within.

From an instruction to an environment

Classic prompt engineering focuses entirely on crafting instructions to steer model behaviour. While this remains necessary, as systems grow more complex, a model’s output relies on everything else occupying its context window: retrieved information, available memory, tool outputs, and previous state. This complete environment is the “context.”

One instruction, four more layers around itOn the left, the prompt of the past: a single instruction, reply in 2 sentences, polite, with nothing else around it. On the right, the context window of a support agent answering a customer about order 7316: the same instruction, plus a retrieved shipping policy v3, a memory that the customer asked twice, a tool output saying the order is delayed with a new ETA of Sunday, and the prior state that an apology was already sent. The same two lines now sit inside four layers of environment.then: the promptnow: the context windowreply in 2 sentences,politenothing elseno tools,no memory,no earlier turnsinstructionreply in 2 sentences, politeretrievedshipping policy v3memoryasked twice about #7316tool outputtrack #7316: delayed, ETA Sunprior stateapology already sentthe same 2 lines,4 layers around them
The instruction you used to tune alone is now one of five things the model reads, and the other four are designed too.

The principle of least knowledge

One guiding principle in this approach is least knowledge: an agent should know only what it requires to execute its specific task — no more. This shifts context management from bulk data ingestion to deliberate constraint. The engineering question changes from “what information can we provide?” to “what must we exclude?”

Choosing what to excludeSix candidate inputs sit on the left: the tracking record for order 7316, the shipping policy, a 3-year order history, other customers’ tickets, an HR leave handbook, and last year’s price list. The agent on the right has one task: where is order 7316. Only the tracking record and the shipping policy move into the agent. The other four are marked out. The agent holds two inputs and nothing extra.tracking #7316shipping policyeverything availablethe agenttracking record #7316shipping policy v33-year order historyothers’ ticketsHR leave handbooklast year’s price listoutoutoutouttaskwhere is #7316?2 inputs,nothing extra
Least knowledge in action: of everything available, the agent gets the two inputs its task needs and nothing else.

Why this shift matters

The behaviour of a complex system cannot be controlled by tweaking a standalone prompt. If incorrect data sits in the context window, even a perfect instruction gives a bad result. If the context is saturated with irrelevant information, the model’s attention degrades. Without strict boundaries, the system becomes fragile. Designing the context is now as critical as writing the instruction.

Same instruction, three contexts, three answersThe instruction, reply in 2 sentences, polite, and the question, where is my order 7316, are identical in all three rows. With stale data, tracking from last week, the agent answers it arrives today, which is wrong. With a crowded context, tracking plus 40 other tickets, it answers contact support, which answers nothing. With a designed context, tracking updated at 08:50, it answers delayed, ETA Sunday, from today’s record.identical in every rowinstructionreply in 2 sentences, politequestionwhere is my order #7316?context it was givenwhat it answeredstale datatracking from last weekcrowded contexttracking + 40 other ticketsdesigned contexttracking, updated 08:50It arrives today.last week’s statusContact support.answers nothingDelayed, ETA Sun.from today’s record
With the instruction held perfect, stale or crowded context still gives a wrong answer; only designed context gives a right one.

The instruction still matters

This does not mean abandoning prompt engineering. A precise instruction remains the backbone of an agent’s behaviour. However, the instruction is only one component of a larger architecture. Context engineering encompasses prompt engineering rather than replacing it: it requires writing clear instructions while deliberately managing the surrounding environment.

Prompt engineering inside context engineeringAn outer frame, context engineering, is everything the model reads. Inside it, a smaller frame, prompt engineering, holds the instruction: reply in 2 sentences, polite. Around that inner frame sit the four other layers, retrieval, memory, tool output and prior state, and each one is designed. The instruction is one part; the design is the whole.context engineering= everything the model readsprompt engineeringthe instructionreply in 2 sentences, politestays the backbone of the behaviouraround it: retrieval, memory, tool output, prior statethe instruction is one part; the design is the whole
Context engineering contains prompt engineering: the instruction stays, and four more decisions about what the model sees sit around it.

Putting it together

As intelligent systems grow more complex, the key skill moves from writing prompts to designing constrained contexts. This is a synthesis, not a prophecy — but it is today’s reality. The model reflects what it sees; and what it sees is the result of a deliberate design decision.