Skip to content

design(desktop): director-first UX reset — intent home, continuity, and progressive workbench IA #537

Description

@agentfleets

Executive diagnosis

TermiPod is capability-rich, but the desktop currently has no single, human-legible interaction spine.

The first decision the product asks is effectively:

Which implementation domain do you want: Fleet, Projects, Read, Author, Inspect, Compare, Replay, Record, or Terminal?

The first decision a director actually has is:

What do I want done, what is already happening, and what needs my judgment?

That mismatch is the “something missing.” The app feels like a collection of well-built internal tools arranged as an operations IDE, while ChatGPT Desktop and Claude Desktop establish one obvious home, preserve continuity, and reveal tools and artifacts when the task calls for them.

This issue proposes a director-first UX reset: keep TermiPod's fleet, governance, provenance, multi-host, and specialist research advantages, but reorganize them around an intent → execution → attention → result → resume loop.

This is not a request to visually clone ChatGPT or Claude. It is a request to match their discipline in hierarchy, continuity, progressive disclosure, and first-run clarity while preserving TermiPod's differentiated cockpit.

Audit scope

Audit performed against the current desktop workbench at 1440 × 900, including:

  • all persistent destinations: Fleet, Projects, Read, Author, Inspect, Compare, Replay, Record, Terminal, Settings;
  • Fleet secondary surfaces: Sessions, Channels, Search, History/“Me,” Admin (Team, Hosts, Agents, Teams, Templates, Engines, Upkeep);
  • command palette, assistant dock, status bar, split-pane model, empty/offline states, light theme, and the supplied dark-theme capture;
  • Account, Display, Keyboard, Environment profiles, Data, About, plus desktop-only Assistant/Network/Vault/update categories from source;
  • relevant shell/state code and the repo's own IA and positioning documents;
  • current official product documentation for ChatGPT Desktop and Claude Desktop.

The review is intentionally about product hierarchy and task flow, not only CSS. A prettier rail would not resolve the main gap.

What already works and should be preserved

TermiPod has important advantages that a generic chat product does not:

  • fleet topology across agents, stewards, hosts, vendors, and sessions;
  • structured attention/ratification rather than treating every request as an unread chat;
  • audit, policy, budget, provenance, and operational controls;
  • research-native artifacts: papers, reports, comparisons, datasets, episodes, records, canvases, and code inspection;
  • desktop simultaneity: persistent context, split panes, keyboard access, and dense monitoring;
  • local-first/offline posture and direct infrastructure ownership.

The redesign should make these strengths easier to reach and understand, not flatten them into “just another chatbot.”

Current evidence

1. The shell is mode-first, not intent-first

desktop/src/state/workbench.ts defines nine peer rail jobs plus Settings. The rail mixes:

  • user/work scopes: Projects;
  • operational scopes: Fleet;
  • artifact/view types: Read, Author, Inspect, Compare, Replay, Record;
  • infrastructure capability: Terminal.

These are not the same level of abstraction. A document editor, an episode viewer, a fleet roster, and a terminal compete as equal top-level worlds. Their order is explained as a research lifecycle in code, but the user has to learn that internal model before doing useful work.

The result is strong feature discoverability but weak goal discoverability: everything is visible, yet there is no dominant “start here.”

2. Persistent chrome competes with the work

On the empty Fleet surface at 1440 × 900, the layout measures approximately:

Region Width Share of viewport
Activity rail 68 px 4.7%
Navigator 240 px 16.7%
Focus 796 px 55.3%
Attention dock 320 px 22.2%

When there are no agents, audit events, or attention items, nearly half the horizontal model is still committed to navigation and an empty dock. The center says “No audit events” while the right says “Nothing needs you.” This reads as an unconfigured control console, not a confident empty state.

Across the app, the user can encounter all of these spatial/control systems at once:

  • activity rail;
  • per-surface header and toolbar;
  • surface-specific navigator/sidebar;
  • focus content;
  • persistent attention/inspector dock;
  • status bar;
  • assistant dock;
  • terminal dock;
  • split panes;
  • command palette;
  • modal management panels.

Each is defensible alone. Together they dilute hierarchy and make the product feel assembled rather than composed.

3. The assistant is peripheral to a product whose user model is agent-first

The assistant is a status-bar chip that opens an optional dock. Offline it presents a connection/local-agent instruction rather than a useful product home. It is visually and conceptually detached from Projects, Sessions, attention, artifacts, and the current selection.

That creates a contradiction: TermiPod says the director expresses intent and agents operate, but the strongest intent surface is secondary chrome while manual tools occupy the primary rail.

4. Continuity is fragmented

There is no unified “continue where I left off” surface. Related continuity concepts are split across:

  • Projects;
  • Sessions;
  • Channels;
  • History (which opens a dialog titled “Me”);
  • the assistant dock;
  • local Author tabs;
  • per-surface project selectors;
  • Activity/Audit and Attention;
  • terminal sessions.

A returning user should not need to remember whether yesterday's work lives in a Project, Session, Channel, document tab, run, episode, or history modal. The product should remember and present the answer.

5. Project context is not the shell's spine

Projects exist as a destination, but project context does not consistently contain or follow the user through tasks, sessions, documents, runs, comparisons, datasets, agents, and decisions. Many surfaces start with their own selector or local empty state.

There is also no persistent, predictable context header answering:

Which team/hub, project, task, agent/session, and artifact am I acting on?

This weakens both orientation and safety. The same action can mean different things depending on hidden selection state.

6. Findability is split by implementation boundary

desktop/src/ui/CommandPalette.tsx is a minimal substring-filtered command list. It finds navigation/actions, not entities or content. Fleet Search explicitly states that it searches event text only, “not project/task metadata” (desktop/src/i18n/index.ts).

The user therefore has to decide which search implementation owns the thing they remember. A leading desktop product instead offers one entry point that can return recent work, entities, content, and actions.

This issue should consume, not duplicate, the unified search work in #72.

7. Empty/offline states expose architecture before value

In a fresh/offline state:

  • Fleet shows empty stewards, agents, audit, and attention;
  • Projects has no projects/workspaces;
  • Read has no items and asks the user to import/link storage;
  • Inspect says nothing is open;
  • Compare has no runs;
  • Replay has no datasets;
  • Record has an empty form and no records;
  • Terminal says the desktop app is required in the browser build;
  • primary fleet actions may be disabled until a hub is connected.

These states accurately describe missing data, but they do not teach the product's value or establish a shortest path. There is no guided sample, concise setup journey, local-only useful mode, or “do this first” action that explains how the pieces connect.

8. Vocabulary reflects implementation more than user intent

Examples visible in the current UI include J1/J2/J3/J5/J6/J8 tags, Fleet, Replay, Record, steward, channels, principals, engine families, environment profiles, raw policy YAML, “Team” and “Teams” as separate Admin tabs, and a History button that opens “Me.” The internal job id is debug while the label is Inspect.

This vocabulary is appropriate in expert/detail views, but too much of it appears before the user has a task. Technical terms should be progressively disclosed and backed by plain-language outcome labels.

9. Status and feedback lack one canonical task model

Running/paused/needs-you counts, Attention, audit rows, toasts, sync state, assistant state, terminal counts, per-session state, and surface-specific status all compete to answer:

What is happening, what changed, what needs me, and what happens next?

There is no canonical task/progress object consistently rendered across Home, Project, session, status bar, and notifications. The same underlying work therefore feels like several unrelated UI systems.

10. Management surfaces rely heavily on modal overlays

Sessions, Channels, Search, History/Me, and Admin behave like substantial screens but are opened as overlays. This weakens back/history semantics, deep linking, shareability, selection persistence, and the “one entity, one home” rule. The Admin cockpit further mixes team policy, hosts, agents, teams, templates, engines, and destructive upkeep within one modal.

Internal design-contract mismatch

This is not only an external benchmark gap. The current shell diverges from the repo's own principles:

  • docs/reference/coding-conventions.md: “User expresses intent; agents operate.” The product is a conversational + ratification surface, not a control panel.
  • docs/spine/information-architecture.md: the product should be a glanceable, director-first cockpit rather than a sprawling admin console; one entity has one home; attention and workspace are primary; plumbing/governance recede.
  • The same IA explicitly says Terminal is a capability on Hosts and in the command palette, never a competing top-level world.
  • docs/discussions/positioning.md: TermiPod's differentiation is one director coordinating agents and hosts through a steward, with a cockpit to direct and ratify without operating.
  • docs/plans/desktop-control-plane.md: desktop leverage is simultaneity, density, keyboard control, and persistent context—not necessarily an ever-growing set of peer modes.

The current desktop activity-bar model was a reasonable way to land specialist capabilities incrementally. It should now be treated as an implementation inventory, not the final product IA.

Benchmark: what leading desktop AI products do differently

The relevant lesson is not their color palette. It is their product grammar.

ChatGPT Desktop

  • establishes an instantly reachable ask/compose entry (including a companion window and shortcut) and maintains conversation history/continuity;
  • uses Projects as ongoing context containers for chats, files, instructions, and history;
  • opens Canvas beside the conversation for direct editing instead of making “editor” a separate permanent product world;
  • surfaces apps/tools contextually inside the conversation and lets users call them by name.

Official references:

Claude Desktop

  • uses Projects for durable knowledge and project instructions;
  • keeps conversation primary while opening significant outputs as Artifacts in a dedicated adjacent pane;
  • makes past-chat continuity and personalization available through natural language;
  • hides connector/MCP setup complexity behind discoverable extensions and settings.

Official references:

Inference: both products organize around one conversational home, durable recent/project context, and contextual tools/artifacts. TermiPod can adopt that hierarchy while adding structured execution, fleet topology, attention, audit, and governance that those products do not make primary.

Proposed product grammar

The primary loop should be:

Express intent
  → agree on task/plan
  → agents execute with visible progress
  → director ratifies only when needed
  → result/artifact is delivered in context
  → work remains resumable from Home and Project

Every major UI element should support one step in this loop. If a surface does not, it should be a contextual tool, inspector, or admin detail—not a peer top-level destination.

Proposed target IA

Persistent primary destinations (maximum four, plus Settings)

  1. Home / Direct — default landing: one intent composer, active work, recent work, and needs-you queue.
  2. Projects — durable context containers for tasks, sessions, files, artifacts, runs, agents, and decisions.
  3. Fleet — agents + hosts + team activity/health; operational detail, not the first-run home.
  4. Library / Artifacts — optional only if cross-project content proves important enough to deserve a home. Otherwise access through Projects + global find.
  5. Settings — pinned, device/personal preferences; team governance entered from team context.

Cross-cutting capabilities

  • Global Find / ⌘K: commands + projects + tasks + sessions + agents + hosts + documents + runs + datasets + settings + recent work.
  • Attention: a state of work, not an always-empty destination. Show it on Home and as an adaptive dock/badge when non-empty.
  • Assistant/Steward: the primary intent surface on Home and context-aware inside a Project; optional dock/shortcut remains for access from anywhere.
  • Terminal: Host action + ⌘K + bottom dock. Remove it from the permanent top-level rail, consistent with IA-A6.
  • Read, Author, Inspect, Compare, Replay, Record: artifact/view types opened from a task, project, session, result, or command. Power users may pin them temporarily; they should not all be permanent peer destinations.

Desktop shell

Prefer one stable spatial model:

Sidebar (Home / Projects / Fleet / Recents)
  | Focus (conversation, task, or artifact)
  | Contextual right pane (attention, inspector, artifact, diff)

Rules:

  • right pane collapses when it has no useful content;
  • current team/project/task/session/artifact is always visible in a breadcrumb/context header;
  • opening an artifact beside a task keeps the originating conversation/progress available;
  • overlays are reserved for short, interruptible actions—not long-lived management screens;
  • specialist views remain keyboard-addressable and pinnable for expert workflows.

Priority gaps and recommendations

Priority Gap Recommendation
P0 No obvious product home Make Home/Direct the default: composer + active/recent work + needs you + connection readiness
P0 Mode-first top-level IA Reduce permanent destinations; move specialist jobs to contextual artifacts/views
P0 Weak resume/continuity Add one recent/active work model spanning projects, tasks, sessions, and artifacts
P0 Fragmented project context Make Project the canonical container and persist context/breadcrumbs across views
P0 Siloed findability Deliver #72 as a unified command/entity/content surface, not another search dialog
P0 Blank first-run/offline experience Add a guided setup/sample flow and one useful local/offline path
P1 Static empty Attention dock Collapse when empty; become contextual inspector or reappear on demand
P1 Too many competing chrome systems Standardize one sidebar + focus + adaptive right-pane model; consolidate status/activity
P1 Implementation-facing vocabulary Remove J-tags from primary chrome; use outcome language; disclose technical terms in detail views
P1 Inconsistent task progress Define one task/progress/attention presentation reused throughout the shell
P1 Modal management screens Give substantial entities canonical routed homes with back/deep-link semantics
P1 Flat action hierarchy One clear primary action per state; secondary/rare/destructive actions move to overflow/detail
P2 Visual polish without hierarchy After IA work: de-chrome surfaces, strengthen typography/spacing, reduce hairlines and equal-weight buttons
P2 Hidden expert interactions Surface shortcuts, split/pin behavior, and alternative-click actions contextually; audit keyboard/accessibility

Phased implementation plan

Phase 0 — validate the spine before broad implementation

  • Prototype Home/Direct, Project context, and adaptive right pane at 1024 and 1440 widths.
  • Test three journeys with five representative users/operators:
    1. “Start a research/coding task and delegate it.”
    2. “Resume yesterday's work and understand its current state.”
    3. “Find and ratify something that needs attention.”
  • Inventory every current surface as home, entity detail, artifact/view, capability, or short action. Any surface without a category is a design smell.

Phase 1 — P0 product spine

  1. Home/Direct wedge

    • default landing;
    • universal intent composer;
    • needs-you, active work, recent projects/tasks/sessions/artifacts;
    • explicit connection readiness and a productive local/offline path;
    • no empty data table on first launch.
  2. Project context wedge

    • Project canonically owns tasks, sessions, agents, documents/artifacts, runs/datasets, and decisions;
    • persistent team → project → task/session/artifact breadcrumb;
    • “open beside” keeps source context;
    • recents/resume state uses stable entity ids, not whichever surface was last selected.
  3. Unified Find wedge

Phase 2 — progressive workbench and adaptive chrome

  1. Move Read/Author/Inspect/Compare/Replay/Record from permanent peer navigation into contextual artifact/view launchers. Retain commands and optional pins for experts.
  2. Remove Terminal from the permanent rail; preserve Host action, command, shortcut, and bottom dock.
  3. Make Attention/Inspector adaptive; hide or collapse empty regions.
  4. Replace long-lived overlays with routed entity/details where appropriate.
  5. Consolidate running/paused/needs-you/sync/assistant/terminal indicators into one activity model with drill-down.

Phase 3 — onboarding, language, and visual system

  1. Add first-run/sample journeys and state-specific empty-state actions.
  2. Normalize nouns and scopes: Team vs Teams, History vs Me, Inspect vs debug, agent/steward explanations, personal vs team settings.
  3. Remove J-tags from primary UI; retain them only in internal docs/dev metadata if useful.
  4. Perform the visual pass after hierarchy stabilizes: readable measures, fewer borders, stronger content emphasis, calmer button hierarchy, both themes, reduced motion, keyboard/focus/touch audits.

Acceptance criteria

Comprehension and start

  • A first-time user can explain TermiPod's primary loop after seeing the default screen, without opening Settings or documentation.
  • A connected user can start/direct useful work from the default screen with one primary action.
  • An offline/unconfigured user sees one recommended setup path plus an optional sample/local path; the default is not four simultaneous empty regions.

Continuity and context

  • A returning user can resume any active/recent project, task, session, or artifact from Home in one click or one keyboard flow.
  • Every project, task, session, agent, host, document/artifact, run, dataset, and decision has one canonical home.
  • Every working view exposes team/project/task-or-session/artifact context and predictable Back/Open-beside semantics.
  • Project context persists when moving among conversation, artifact, inspection, comparison, and replay views.

Navigation and findability

  • No more than four persistent primary work destinations are shown, plus Settings.
  • Read/Author/Inspect/Compare/Replay/Record remain reachable through context and ⌘K, and may be temporarily pinned without becoming permanent modes.
  • Terminal remains reachable from Host detail, ⌘K/shortcut, and its dock, but is not a permanent peer rail item.
  • ⌘K returns commands, entities, recents, and content with clear type/context labels.

Attention and progress

  • The right pane collapses or becomes contextual when Attention is empty.
  • Running work uses one consistent progress model across Home, Project, session, and status/activity UI.
  • Every attention item explains the originating work, requested decision, consequence, and next step.

Empty states and visual quality

  • Every primary empty state has one recommended action, a short value explanation, and no redundant “nothing here” panels.
  • Primary vs secondary vs destructive actions are visually unambiguous.
  • The shell passes 1024/1440, light/dark, keyboard-only, focus-order, screen-reader naming, and touch-target checks.

Success metrics

Track before/after for representative journeys:

  • time and clicks from launch to first delegated task;
  • time and clicks to resume recent active work;
  • time to locate and resolve an attention item;
  • wrong-destination/backtracking rate across the current job surfaces;
  • global-find success rate;
  • percentage of sessions beginning from Home/Direct versus manual specialist navigation;
  • percentage of empty/offline launches that reach setup, sample, or local work;
  • qualitative “I know what to do next” rating after first launch.

Relationship to existing issues

Non-goals

  • Do not remove fleet/governance/audit/provenance capabilities.
  • Do not turn TermiPod into an unstructured general chat app.
  • Do not hide expert functionality with no keyboard/contextual replacement.
  • Do not begin with a theme/token-only redesign; the IA and task model must stabilize first.
  • Do not require a backend ontology rewrite before prototyping the shell. The first milestone is validating the interaction contract and navigation model.

Recommended decision

Adopt Home/Direct + Projects + Fleet + adaptive capabilities as the desktop product spine, and treat the current J1–J8 job registry as a catalog of specialist views rather than the permanent top-level IA.

This aligns the desktop with TermiPod's own director model while borrowing the strongest UX pattern from leading AI desktops: one obvious place to express intent, durable context, tools that appear when relevant, and effortless resumption.

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions