Wording is half; surroundings are the other half
What the term means and where it is contested
Context engineering is a relatively new term for an old practical concern: what information the assistant can see while it works. In a single chat session with no tools and no memory, the discipline is hard to distinguish from prompt engineering. The interesting work begins when the setting is agentic — multiple turns, tool calls, retrieved documents, persistent memory, sub-agents. There, the question of what to put in the context window at each step becomes a systems discipline rather than a wording one. Whether the new term deserves the new name is debated; what matters in practice is the discipline itself.
Four levers worth knowing
The discipline comes down to a small number of levers. The system instructions that define how the assistant behaves across the session. The documents retrieved at each turn, whether by explicit attachment or by search. The conversation history, including the parts that have been compacted into summary. The persistent memory that survives across sessions, including saved corrections and user preferences. Tuning each lever — what is included, what is excluded, what is kept and what is dropped — is what separates a working agent from one that occasionally drifts.
Eviction and compression as the unglamorous core
Most of the visible weight in context engineering is on the addition side: what to include, what to retrieve, what to attach. The harder and less glamorous half is the subtraction side: what to evict when the window fills, what to compress when the conversation grows, what to refuse to include because it would crowd out something more important. A working setup spends more attention on these decisions than on the wording of any individual prompt. The lever that matters most is rarely the cleverest one.
Where it lands for a working professional
The practical implication for someone running a productivity stack is that context engineering is a set of small, durable artefacts — a project-level instruction file, a parameterised set of prompt templates, an explicit summarisation rule, a preference document that survives across sessions. These pieces are not exotic. They are the same discipline as keeping a tidy desk, applied to a different surface. The skill is not the artefact; the skill is the habit of deciding deliberately what the assistant will see, rather than letting it accumulate by accident. That habit, more than any individual technique, distinguishes a worker who gets useful results from one who keeps being surprised.
When an assistant gives a wrong answer, what is the more common cause: a poorly chosen prompt, or that it did not have access to the right information when answering?