# Assistant sidebar > The conversation has to sit next to the work without covering the work up. - Canonical: https://patterns.konigi.com/ai-assistants/assistant-sidebar - Group: In-product assistance - Level: implementation - Status: published - Updated: September 12, 2026 - Also called: AI panel, chat drawer, side rail assistant --- ## Problem An assistant inside a product needs somewhere to live. A modal covers the work and makes the assistant the task. A separate page abandons the context entirely. Neither lets the viewer read an answer and look at the thing it's about at the same time. ## Solution A persistent panel down one edge, with the work still visible beside it. The arrangement is unremarkable; what earns it's the thing it makes possible, which is that the assistant can see what the viewer is looking at. HAX guideline 4 asks for contextually relevant information, and a sidebar that reads the open document, the selected rows, or the current issue is the only version of an in-product assistant that beats opening a general chatbot in another tab. Without that binding, a panel is a worse chatbot in a narrower column. Because the context is the point, it has to be visible. A small line naming what the assistant can currently see, and ideally letting the viewer change it, answers the question that otherwise gets answered by experiment. It also prevents the more damaging misunderstanding, where a viewer assumes the panel can see the whole workspace and asks a question that silently gets answered from the one open file. Width is a real constraint rather than a styling choice. Prose needs somewhere around 360 to 420 pixels to read comfortably, and every one of those pixels comes off the document. On a 13-inch laptop the panel and the work are in direct competition, which argues for making it resizable, remembering the size, and collapsing it to a rail rather than a full close. Dismissal deserves the same care as invocation, which HAX guideline 8 is explicit about. A panel that takes three clicks to get rid of, or that reopens on every navigation, becomes something people fight. One keystroke to open, the same keystroke to close, state remembered per document. Output routing is the last piece. An answer produced next to a document frequently belongs inside it, and the path from panel to content should be a button rather than a copy and paste. That path is also where the scope contract gets tested, since inserting into the document is the moment the assistant stops advising and starts editing. ## Use when The assistant's value depends on what the viewer is currently working on, and conversations run more than one turn. ## Don't use when The interaction is a single act on a single object. A rewrite, a summary, or a rename is better served by an inline control, and opening a panel for it costs more screen than the task is worth. ## Trade-offs Every pixel of panel is a pixel of work, and the people with the least screen are usually the ones with the most need. Persisting the panel across navigation keeps the thread alive and means the assistant follows people into places it knows nothing about. Binding to the current document makes it useful and makes its answers hard to reproduce later, since the same question in a different file gives a different answer for invisible reasons. And on a phone the whole arrangement collapses, so the panel becomes a sheet and the side-by-side reading the pattern exists for is gone. ## Checklist - Does the panel know what the viewer is looking at, and does it say so? - Can the viewer change what it can see? - Is it resizable, and is the size remembered? - Is open and close the same keystroke? - Does the conversation survive navigating to another document, and should it? - Is there a one-click path from an answer into the document? - What does this become at a phone width? - Does the panel push the content or overlay it? - Where does the history of these conversations live? - Does it reopen uninvited after being dismissed? ## Compare **Claude** keeps the conversation in the main column and pushes generated documents into the side panel, inverting the usual arrangement so the artifact takes the space rather than the chat. **Notion** binds its panel to the current page and pulls extra context through @-mentions. Scope gets typed rather than inferred. **Microsoft Copilot** in an Office application scopes to the open file and the tenant, where the panel's hardest job is explaining which of those two it is answering from. **Figma** puts the assistant against the canvas selection instead of a document, so the panel's context is a set of layers and the answers are structural rather than textual. ## Related Scoped context is the mechanism that makes the panel worth more than a browser tab. Inline assist is the lighter alternative for single acts. AI entry point is how people find the panel in the first place. Artifact panel is what happens when the output needs the space instead. Conversation history is where these threads go once the viewer closes the document. ## Related patterns - [Scoped context](https://patterns.konigi.com/ai-assistants/scoped-context) — The assistant sits inside a product full of data and the viewer cannot tell how much of it is in scope. - [Inline assist](https://patterns.konigi.com/ai-assistants/inline-assist) — The viewer wants one paragraph changed and does not want to leave the document to ask for it. - [AI entry point](https://patterns.konigi.com/ai-assistants/ai-entry-point) — The feature has to be findable inside a product people already know, without retraining them on it. - [Artifact panel](https://patterns.konigi.com/ai-assistants/artifact-panel) — The answer is a document or a program, and a chat transcript is the wrong container for either. - [Conversation history](https://patterns.konigi.com/ai-assistants/conversation-history) — The useful exchange was three days ago and the viewer remembers one word from it. ## 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 8, Support efficient dismissal](https://www.microsoft.com/en-us/haxtoolkit/guideline/support-efficient-dismissal/) - [Apple, Human Interface Guidelines, Generative AI](https://developer.apple.com/design/human-interface-guidelines/generative-ai) --- Screenshots on patterns.konigi.com are reproduced for commentary and criticism. Product names and marks belong to their owners.