Context is part of the product
An assistant can understand every word of a question and still answer the wrong question. The missing ingredient is often the situation around it.
“Explain this” might refer to a highlighted sentence, the argument of a paper, a confusing figure, or an error in a codebase. The same words call for different answers. A product has to decide which parts of the user’s situation become visible to the model.
That decision deserves the same attention as the answer itself.
The interface makes a claim
When someone selects a paragraph and opens an assistant, the interface implies that the assistant can see the paragraph. If the user asks a follow-up, it implies that the earlier context still matters. If the answer cites a document, it implies that the cited passage supports the claim.
Each implication is a product promise. A failure anywhere along that path can feel like a model failure, even when the model was never given what it needed.
This suggests a practical way to investigate bad answers. Trace what the user saw, what they selected, what the product extracted, and what the model received. Then examine the response. Starting at the response alone can hide the actual problem.
More context has a cost
Sending everything is an attractive shortcut. But a larger context can contain stale instructions, duplicate documents, irrelevant details, and conflicting versions. It also makes it harder for a person to understand why the assistant made a particular choice.
A useful context system should answer three questions:
- What information is relevant to the task right now?
- Which source should take precedence when information conflicts?
- How can the user notice and correct a mistaken selection?
These questions connect retrieval, product design, and user control. A visible file selection, a precise citation, or an easy way to remove a source can matter as much as a larger context window.
Make the reasoning inspectable
A citation is most useful when it reduces the effort of checking an answer. Showing a file name is a start. Showing the relevant passage and letting the reader jump to it closes more of the loop.
The same principle applies beyond documents. A coding assistant can point to the function it relied on. A work assistant can identify which version of a plan informed its answer. The user gains a way to distinguish a misunderstanding from missing information.
The broader product lesson is to design the path from situation to answer as one experience. Evaluate whether the assistant received the right context, whether its answer used that context correctly, and whether a person could recover when either step failed.
Better models expand what is possible. Better context design determines how much of that possibility reaches the user.