Problem statement
Assist is a modal dialog. Opening it blocks everything behind it, which is fine for quick (voice) commands, but increasingly limiting as the assistant takes on more complex management tasks. A maintainer who wants help while editing an automation cannot see the automation while talking to the assistant. Additionally, when they close the dialog, the conversation is gone, and they have to start over.
These two problems will only grow as Assist's management capabilities expand (see AI in Home Assistant vision document, TODO: Add link). Addressing it now, before those capabilities deepen, avoids compounding a structural problem and sets up a better foundation for what comes next.
In this opportunity, we will address the first part of the problem: the fact that whatever is being talked about is being obscured by the chat itself rather than remaining visible.
Community signals
There are no direct feature requests specifically for a non-blocking Assist surface. But the frustration that motivates it shows up in adjacent places.
A March 2026 forum post titled "Too easy to swipe away Assist window while scrolling" describes a user who keeps accidentally closing Assist while trying to read a long response, losing the conversation entirely each time. The poster explicitly proposed persistent conversation history as a solution, a workaround for the underlying problem that the dialog is fragile and disposable. This is a concrete signal that the current modal interaction model is limiting as conversations get longer and more substantive.
More broadly: the entire pattern of users turning to external tools like Claude or ChatGPT (with their persistent chat interfaces) for HA management help, rather than using Assist, reflects a preference for a surface that stays open, remembers context, and allows back-and-forth.
Scope & Boundaries
In scope
- Redesigning the Assist surface from a blocking modal dialog to a non-blocking form, such as a side panel or overlay that allows interaction with the UI behind it
- Preserving the conversation as long as it is open so that it is not lost when the maintainer switches focus (e.g. to change something in an automation)
- Ensuring the redesign works well for both control and management use cases
Not in scope
- Persistent session storage across page loads or devices — that is a separate opportunity
- Any changes to the assistant's capabilities or the context-passing architecture
- Changes to the voice input or Assist pipeline behaviour
Foreseen solution
Replace the modal dialog with a non-blocking surface, a collapsible side panel or similar, that allows the maintainer to interact with the rest of the UI while the assistant is open. The conversation persists as long as the panel is open. The maintainer can refer back to what was said, ask follow-up questions, and act on suggestions without losing their thread.
We have not made any design explorations yet, but are considering a model similar to Gemini in Google Workspace products:
Risks & open questions
- Layout impact: A persistent side panel changes the layout of every page it can appear on. This needs to be designed carefully to avoid crowding the main interface.
- Mobile: A side panel pattern may not translate well to smaller screens. Mobile behaviour needs its own consideration.
- Voice interaction: The existing dialog has a strong association with voice input. The redesign should not degrade that experience for users who rely on it.
Appetite
Medium — 1 cycle. The redesign is primarily a frontend investment. The main risk is layout impact across a large number of pages.
Execution issues
No response
Decision log
Problem statement
Assist is a modal dialog. Opening it blocks everything behind it, which is fine for quick (voice) commands, but increasingly limiting as the assistant takes on more complex management tasks. A maintainer who wants help while editing an automation cannot see the automation while talking to the assistant. Additionally, when they close the dialog, the conversation is gone, and they have to start over.
These two problems will only grow as Assist's management capabilities expand (see AI in Home Assistant vision document, TODO: Add link). Addressing it now, before those capabilities deepen, avoids compounding a structural problem and sets up a better foundation for what comes next.
In this opportunity, we will address the first part of the problem: the fact that whatever is being talked about is being obscured by the chat itself rather than remaining visible.
Community signals
There are no direct feature requests specifically for a non-blocking Assist surface. But the frustration that motivates it shows up in adjacent places.
A March 2026 forum post titled "Too easy to swipe away Assist window while scrolling" describes a user who keeps accidentally closing Assist while trying to read a long response, losing the conversation entirely each time. The poster explicitly proposed persistent conversation history as a solution, a workaround for the underlying problem that the dialog is fragile and disposable. This is a concrete signal that the current modal interaction model is limiting as conversations get longer and more substantive.
More broadly: the entire pattern of users turning to external tools like Claude or ChatGPT (with their persistent chat interfaces) for HA management help, rather than using Assist, reflects a preference for a surface that stays open, remembers context, and allows back-and-forth.
Scope & Boundaries
In scope
Not in scope
Foreseen solution
Replace the modal dialog with a non-blocking surface, a collapsible side panel or similar, that allows the maintainer to interact with the rest of the UI while the assistant is open. The conversation persists as long as the panel is open. The maintainer can refer back to what was said, ask follow-up questions, and act on suggestions without losing their thread.
We have not made any design explorations yet, but are considering a model similar to Gemini in Google Workspace products:
Risks & open questions
Appetite
Medium — 1 cycle. The redesign is primarily a frontend investment. The main risk is layout impact across a large number of pages.
Execution issues
No response
Decision log