Docking documents with chat

The AI chat doesn't need to "attach" to a document. Whenever you're on a document page, the assistant already knows which document you're on: its id, its title, the titles of its Section blocks and the document body itself, rendered as markdown, all reach the model. What you do control is where the chat sits on the screen: as a floating window in the corner, or as a panel docked to the right of the page.

This page covers how to open it, the two display modes, what the assistant actually sees from the document, and where its awareness ends.

Opening the chat

The chat opens from the round gradient logo button that sits in a corner of the viewport. It's draggable: grab it and drop it near any of the four corners, and the position sticks.

There is no keyboard shortcut to open the chat. The closest thing is the command palette: press ⌘K and type an action-style query ("summarise this document", "draft a methods paragraph"). If nothing in the workspace matches, the palette offers to hand the query over: it shows "Press ↵ to ask AI" when the query reads like a request, and an Ask AI instead button otherwise. Either route opens the chat with your query already sent. See Command palette.

Floating window vs. docked side panel

The chat has two display modes. The toggle is the small window/sidebar icon in the chat tab bar, beside the close button; it appears on wide screens only.

Floating window

A panel anchored to a corner of the viewport, 420 pixels wide by default and resizable up to half the width of the main view. Draggable. Good for quick questions and short replies, but it overlays the page, so it can cover content.

Docked side panel

A full-height column glued to the right edge of the page. The document reflows to make room, so editor and chat sit truly side-by-side. Same default width and resize range. Good for sustained editing while chatting.

Switching modes preserves the conversation, and your document context is sent on every message in both modes. Docking the chat is a layout preference, not a way of "giving the assistant access" to the document.

What the assistant sees from the document

Every message you send from a document page carries a small context payload alongside the text you typed, and the server adds the document itself before the model reads anything:

• Document title and id: so the assistant can name it back to you.
• Section titles: the titles of every Section block in the document. The list covers the whole document, so scrolling does not change it, and plain H1/H2/H3 headings do not contribute to it.
• The document body: the server fetches the document and renders it as markdown, in the exact format the assistant writes back. Every block carries its id, so the assistant can cite and edit specific blocks. Data-heavy blocks (registration tables, lookup tables, forms, well plates) are reduced to a pointer id rather than their contents, and a very long document is truncated at 30,000 characters.
• Where you are: the current workspace and the current path. The tabs open in the workbench are added only when the view is split; with a single pane no tab list is sent.

A few things the assistant does not get:

• Your selection or cursor position. Highlighting a paragraph does not put it in the payload. To work on one passage, name it: its section, its opening words, or the block it sits in.
• The contents of pointer blocks. A registration table arrives as an id. The assistant can read the rows with its data tools, but they are not sitting in front of it the way prose is.
• A diff of what you just changed. The assistant sees the document's current state at the moment you send the message, not what you edited thirty seconds ago. If you want it to react to a specific edit, tell it about the edit in your message.

In practice this last point matters most. If you've just rewritten a paragraph and want feedback, don't ask "is that better?": say "I just rewrote the second paragraph in the methods section; does it follow from the table above?" and you'll get a useful answer.

Patterns that work well

Drafting from what is already there

The whole document body is in the payload, so "draft a methods paragraph that follows the steps in the Preparation section" works with nothing pasted.

Pointing at a passage

Selections are not sent. Name the passage instead: "rewrite the second paragraph under Sample handling".

Calling out a recent edit

Because the chat doesn't track changes, mention edits explicitly: "I just changed the assay buffer from PBS to TBS, does the rest of the protocol still hold?".

Comparing two documents

Open document A, ask the assistant for a summary. Switch to document B, ask "how does this differ from what you just summarised?". The conversation persists across pages.

Attaching images and screenshots

On a vision-capable model (the Claude, GPT-5.x, Gemini, Gemma 4, Kimi and Mistral / Magistral families all qualify) you can drag an instrument photo, a gel scan, or a UI screenshot straight into the chat composer, or paste it with ⌘V. The image attaches to your draft and the model sees it on the next turn.

Useful pairings with a document open:

• Annotate a chart. With the document containing the chart in view, drop a screenshot and ask "where on the chart does this anomaly come from?".
• Extract from an instrument capture. Drop a plate-reader screenshot and ask the assistant to transcribe the values into the result table you have open.
• Reproduce a layout. Drop a screenshot of a published figure and ask "rebuild this as a chart block in the document I have open".

The paperclip button is never disabled by your model choice; it greys out only while a response is streaming. Non-image attachments (PDF, CSV, XLS/XLSX) upload and attach by pointer on any model. If you drop an image on a model that cannot see images, Dalea shows a toast naming vision-capable alternatives and the image is not attached; switch models from the pill at the top left of the conversation. On the default Dalea engine the image goes through anyway: the model is text-only on the wire, so the server hands the image to a vision-capable delegate through its view_image tool.

What's next