Session Dashboards: Live Widgets for Every Thread

Every thread in the Control UI shows two sides: the conversation you already know, plus a dashboard, which is a grid of live widgets your agent constructs for you. If a thread has no widgets, it is purely chat. Once you pin a widget, a Chat | Dashboard toggle shows up in the header, and the dashboard takes over as the primary view with your chat sitting alongside it.

No configuration or separate application is required: dashboards are built into the product, belong to the thread, are saved with the agent, and persist through /new and /reset (the conversation history resets, but the board remains).

Find your dashboards

Head to /dashboards to list every thread whose preferred face is Dashboard, ordered by most recently updated first. Clicking any row takes you straight to that thread's /dashboard/<agent>/<sessionRef> URL.

The preference for Chat or Dashboard face is saved server-side for each thread. That means it carries over when you reach the same gateway from a different device. Opening a thread via the sidebar, Sessions, Tasks, Workboard, or Worktrees honors that saved face, even if the thread falls outside the set of sessions the browser has already loaded. The active dashboard tab and the remembered chat-dock placement are per-device UI state, so each browser can hold onto its own arrangement.

Build a dashboard by asking

Tell your agent what you'd like to see:

Create a widget named revenue-graph: an interactive bar chart of monthly revenue. Add "Bars" and "Trend" buttons that switch views. Pin it to my dashboard.

The agent first renders the widget inline in the chat so you can inspect it before it moves anywhere. From there:

• You pin it: hover over an inline widget and select Pin to dashboard.
• Or the agent pins it on its own when you ask, and later updates it by name. Widgets carry stable names, so "update revenue-graph with June's numbers" swaps the content in place while the board stays unchanged.

Widgets are self-contained mini applications (HTML/JS/SVG inside a strict sandbox). Buttons and view toggles within a widget respond immediately, so changing a chart view never requires the agent.

The board

• Fluid grid. Drag widgets by their handle, and everything rearranges and condenses automatically. Resize via the handle or choose a size preset (small, medium, large, extra large) from the widget menu. Nobody positions pixels, not you and not the agent.
• Tabs. A board can hold multiple pages, for example an overview tab and a focused tab with one large widget. Each tab remembers its own chat-dock position.
• Docked chat. On the dashboard face, your conversation docks to the left, right, or bottom, resizes like the sidebar, and can be hidden completely. The agent still hears you when you bring it back.
• Agent parity. Whatever you can do, the agent can do with its dashboard tool: add, update, move, resize, and remove widgets, manage tabs, switch the visible tab, and move or hide the chat dock. Ask "put the chat on the left and show the finance tab" and watch it happen.

What widgets are allowed to do

A widget that only renders needs no approval. It appears instantly, just like inline chat widgets, and its network access is entirely disabled.

Widgets that want reach must declare it, and you grant it once per widget with one tap:

• Network (net): fetch declared HTTPS origins directly from the sandbox, such as a weather card that refreshes itself from an API.
• Gateway data (data): read-only feeds like sessions, usage, or cron status, resolved by the gateway. The widget never holds your token.
• Automation (actions): trigger a specific cron job, so a button can run a real task (which may use a smaller model) without waking your main conversation.
• Prompt (prompt): send messages into your thread without the per-click confirmation that unapproved widgets require.

Enabled plugins can add their own named read-only feeds and actions to these capability lists; disabling the plugin removes those integrations.

Grants are tied to the exact widget bytes and revision you reviewed. If the agent changes the widget and asks for more than you approved, it goes back to pending; refreshing content within the same permissions keeps the grant. Widget interactions the agent should know about (filters you clicked, views you switched) reach it quietly as session notices. It stays informed without being interrupted.

MCP apps on the board

If your gateway has MCP servers configured, interactive MCP apps that appear in chat can be pinned like any widget. Pinned apps come back to life on the board with fresh sessions; by default they are display-only, and granting the widget its declared server tools makes it fully interactive, with the same one-tap, revision-bound approval as everything else.

Good to know

• Resetting a thread that has a board asks for confirmation and keeps the board.
• Deleting a thread deletes its board.
• Boards live on your gateway (in the owning agent's database) and appear on every device you connect from.
• Switching a thread to the Dashboard face adds it to /dashboards. Switching it back to Chat removes it.
• The security model, storage details, and design rationale live in Dashboard Architecture, including the documented sandbox tradeoffs.