Problem
An assistant inside a workspace answers a question about last quarter. Whether it read the one open document, the whole project, every file the viewer can access, or nothing at all is invisible, and each of those makes the answer mean something different.
Solution
Show the working set as a small, explicit list of what’s currently in scope, and let the viewer change it.
No other affordance in an in-product assistant repays its space as well, because scope is the one thing a viewer can’t infer and can’t test cheaply. PAIR’s argument about mental models applies with unusual force: people build a model of what a system can see from whatever evidence is available, and in the absence of evidence they invent one. The two inventions are symmetrical and both damaging. Assuming too much scope produces trust in an answer drawn from one file. Assuming too little means the viewer pastes in material the assistant already had.
Chips are the workable form. One per item, naming the document, project, or dataset in scope, each removable, with an obvious way to add more. Chips make scope composable rather than configured: the default is whatever context the viewer is sitting in, and adjusting it takes one click rather than a trip to settings. Where the product has a mention grammar, adding to scope by typing is faster still.
Permissions turn this from a clarity problem into a correctness problem. An assistant that can reach everything the viewer can reach is the only defensible default, and it means scope is per-person: the same question in the same document gives different answers to two colleagues. Both answers are right, and the difference between them is bewildering, so the interface has to show the boundary rather than leave someone concluding the assistant is unreliable.
HAX guideline 10 asks systems to scope their services when in doubt, and the conservative default is the narrow one. An assistant that starts with the open document and lets the viewer widen is easier to reason about than one that starts with everything and has to be reined in. It’s also cheaper, since scope and the context budget are the same resource seen from two directions.
Use when
The assistant lives inside a product with more material than fits in one window, and answers depend on which part was used.
Don’t use when
The assistant has exactly one possible scope and no way to change it. A chip showing the only document that could ever be in play is noise dressed as control.
Trade-offs
Explicit scope is comprehensible and makes the viewer responsible for a decision the product could have made. Broad default scope gives better answers and makes them unreproducible, since nobody can tell later what was read. Per-person permission scoping is correct and produces colleagues getting different answers to the same question, which reads as a bug. Scope chips occupy persistent space near the composer, competing with everything else that wants to live there.
Checklist
- Can the viewer see what’s in scope without asking?
- Can they add and remove items in one action?
- Is the default the narrow scope or the broad one?
- Is scope bounded by the viewer’s own permissions, and is that stated?
- Does the answer say which of the in-scope items it actually used?
- Does scope persist across turns, and across navigation?
- How does scope interact with the context budget?
- What happens when an in-scope document changes mid-conversation?
- Is scope carried into a shared conversation, and should it be?
- Can two colleagues tell why they got different answers?
Compare
Notion composes scope through @-mentions in the prompt, so the working set is typed into the question and visible in the text itself. Claude uses projects as the unit, where a deliberately assembled set of documents is the scope and the boundary is something the viewer built. Microsoft Copilot scopes to the tenant with permission trimming. It has the broadest reach of anything here, and the per-person boundary becomes the defining design problem. Cursor shows the working set as an explicit, editable list of files, treating scope as something to curate rather than infer and assuming a user who wants that job.
Related
Assistant sidebar is where scope is usually displayed. Attachment tray is scope the viewer supplied from outside the product. Command menu is the fastest way to add to it. Source list says which in-scope material an answer actually used. Context meter is the same constraint measured in tokens.