Host support for persistent (pip/pinned) app views: clinical use case where inline rendering breaks the core loop

We build an OCD treatment program (Conicia) and ship an MCP app: swipeable lesson cards patients work through inside the chat, with a conversational layer around them (the assistant discusses the material, and a guardrail routes compulsive reassurance-seeking to in-the-moment tools).

Inline rendering breaks the core loop. The patient reads a card, asks the assistant a question, and after two exchanges the deck has scrolled off-screen. Re-invoking the tool stacks duplicate decks. Clinically, the conversation around the material is the entire reason to host lessons in chat, so "either chat or view the app, not both" defeats the point.

What we have tried:

• Stable view identity: returning a constant viewUUID in _meta on repeat tool calls, hoping hosts route the result to the existing view rather than instantiating a new one. Host behavior appears to be per-call instantiation regardless.
• `requestDisplayMode("fullscreen")": works where supported, but fullscreen suspends the conversation, which is the opposite of the goal.

The ask: host support for the persistent/pinned direction the spec already gestures at (pip), or letting app views open in the persistent side panel some hosts already have for their own artifacts. A view that stays put while the transcript scrolls would fix this class of problem completely, for us and for any app whose view is a workspace rather than a one-shot result (maps, dashboards, documents).

Happy to be a design partner or demo the clinical use case.

Conicia (https://conicia.com)

Start by reviewing the persistent/pinned direction in the spec and the existing requestDisplayMode("fullscreen") behavior. Define host behavior that keeps an app view visible while the transcript scrolls, preserves the conversation, and avoids duplicate views on repeated tool calls.