Prompt engineering is about how to formulate a single request to the model. Context engineering is about what ends up in the context window by the time the model responds: system prompt, conversation history, files, tool call results, memory. The layer that collects and filters all this information before each interaction with the model, and its quality affects the result as much as the prompt itself.
It might seem logical to just throw everything into the context window since models have context windows of 200,000 tokens or more—documentation, history, results of all tools. In practice, this is worse. The longer the context, the worse the model maintains focus on truly important parts—the necessary detail gets lost somewhere in the middle of a huge text among the noise. Every extra token is also a delay with money, and irrelevant information in the context can really confuse the model, not just be ballast.
A working approach is to gradually reveal the context depending on the path the agent takes. It's like a huge tree where it's easy to get lost if you try to cover it all. But an ant crawling along one branch in a chosen direction sees exactly what's needed there at each step—a further fork, a log, a tool that can be called—and keeps in mind the path taken, not the entire map of the tree. The agent works the same way: it doesn't receive the entire project documentation at once but makes a tool call, reads the specific file needed right now, and only what's relevant to the current step remains in the context.
In agent and multi-agent systems, this is especially critical. If the orchestrator gets the full work log of each sub-agent in the context, it drowns in foreign details after just a few steps. Instead, the sub-agent works in its isolated context and returns only the summary—the result, not the entire process. This is what allows the system to scale: adding a tenth agent is much easier when each of them doesn't drag along the history of all the others.