The context is a design decision.

A window is capacity. Context is a choice.

A system can have room for a large amount of text and still miss the one fact required to answer a question.

Think of a document assistant answering a policy question. The designer decides which sources are searchable, how versions are represented, which passages are selected, and which reader can access them. Those decisions shape the evidence before the model generates its first word.

Make the selection visible

Write down a context contract:

• What information is required for this task?
• Where does it come from?
• How fresh must it be?
• Who is allowed to see it?
• What should happen when it is missing?

Do less, deliberately

For a narrow question, a small set of relevant passages may be easier to inspect than an entire document collection. Conversely, removing context too aggressively can hide exceptions or dependencies.

Retrieval-augmented systems provide one way to select external evidence; the original RAG paper explores that connection between retrieval and generation. The design responsibilities remain in the surrounding application.

The next question

Instead of asking only “How much can the model read?”, also ask “Why is each piece of information here?”

That question connects context engineering to architecture, access control, and evaluation. It turns an invisible prompt-building step into a system boundary you can reason about.