Context Engineering
Context engineering is the design discipline of selecting and assembling only the information the current call needs. When retrieved documents, chat history, memory, and tool results matter more than the wording of one prompt, this becomes the central layer.
βΆArchitecture Diagram
π Data FlowDashed line animations indicate the flow direction of data or requests
Many failures look like weak prompting at first, but are actually caused by the wrong document being inserted, stale history taking too much room, or long tool results drowning out the useful parts. More information is not automatically better. The wrong information often behaves like noise.
Once LLM applications started mixing retrieval, memory, and tool use, a prompt stopped being a single block of text. Teams needed explicit logic for which sources belong in the current step, which should be summarized, and which should be left out entirely, and that logic became context engineering.
A system usually gathers candidate information sources around the current request, then filters and ranks them by relevance, freshness, permissions, and size. It may compress them before assembling a final packet that keeps instructions separate from reference material. The hardest question is usually not what to add. It is what to remove now.
Context engineering, the context window, and prompt engineering all affect one request, but they answer different questions. If total capacity is the problem, look at the context window. If the instructions themselves are vague, look at prompt engineering. If the issue is which documents, history, or state should be present in this step, look at context engineering. Better packing cannot rescue fundamentally unclear instructions.
The biggest gain from context engineering is higher signal density without changing the model or rewriting the whole prompt. The cost is that ranking, compression, permissions, and source-selection logic add real pipeline complexity, and bugs in that logic can masquerade as model failures. In short single-turn systems it may be overkill, but once retrieval, memory, and tool results compete for space, the trade is usually worth it.
This matters most in RAG systems, long-running assistants, agents, and support workflows. Good systems do not just keep adding more retrieval hits or raw tool outputs. They keep only what the current step can use. Weak context engineering often gets misdiagnosed as weak model performance.