# Scoped context > The assistant sits inside a product full of data and the viewer cannot tell how much of it is in scope. - Canonical: https://patterns.konigi.com/ai-assistants/scoped-context - Group: Memory and context - Level: implementation - Status: published - Updated: September 12, 2026 - Also called: context pills, working set, what it can see --- ## 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. ## Related patterns - [Assistant sidebar](https://patterns.konigi.com/ai-assistants/assistant-sidebar) — The conversation has to sit next to the work without covering the work up. - [Attachment tray](https://patterns.konigi.com/ai-assistants/attachment-tray) — The viewer adds a file to the question and needs to see what the model will actually read. - [Command menu](https://patterns.konigi.com/ai-assistants/command-menu) — Power users need to name a tool, a file or a person without describing it in a sentence. - [Source list](https://patterns.konigi.com/ai-assistants/source-list) — The answer drew on eight pages, and the viewer needs to judge those pages before trusting it. - [Context meter](https://patterns.konigi.com/ai-assistants/context-meter) — A long conversation quietly stops remembering its own beginning. ## Sources - [Microsoft HAX Toolkit, Guideline 4, Show contextually relevant information](https://www.microsoft.com/en-us/haxtoolkit/guideline/show-contextually-relevant-information/) - [Microsoft HAX Toolkit, Guideline 10, Scope services when in doubt](https://www.microsoft.com/en-us/haxtoolkit/guideline/scope-services-when-in-doubt/) - [Google PAIR, Mental Models](https://pair.withgoogle.com/chapter/mental-models/) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.