Idea: A native, trustworthy visual Mission Control for the OpenBot agent fleet

[criloOcom]

Summary

I would like to propose a cohesive, native visual experience that helps people understand and manage their OpenBot agent fleet.

As the number of agents, sections, tasks, and routines grows, a list of names and individual conversations is not always enough. It can be difficult to understand who does what, how a workflow connects its steps, which agents belong to a particular group, and whether the information shown on screen is current.

The idea is to bring these elements together in a visual Mission Control experience inside the existing OpenBot application.

This is not a request to duplicate the existing visual-canvas proposal in #1203 or the workflow-execution proposal in #1920. The goal is to discuss the user experience that connects these capabilities and makes them understandable, discoverable, and trustworthy.

The examples below are conceptual wireframes, not a request to reproduce a particular product's interface.

1. One native visual workspace, with several ways to understand the fleet

I imagine a dedicated Mission Control page integrated into OpenBot's normal navigation. Instead of opening a separate application or unrelated window, the user could switch between complementary views of the same underlying information.

Conceptual overview

┌───────────────────────────────────────────────────────────────────────┐
│ OpenBot                                      Mission Control          │
├───────────────────────────────────────────────────────────────────────┤
│ Server: [active server]   ● Connection   Updated: [time]               │
│ Workspace: [known context]   Scope: [all agents / filtered selection] │
├──────────────┬────────────────────────────────────────────────────────┤
│              │                                                        │
│ Overview     │  Fleet overview                                         │
│ Workflows    │                                                        │
│ Organization │  ┌────────────────┐  ┌────────────────┐                 │
│ Agents       │  │ Section A      │  │ Section B      │                 │
│              │  │ Lead + agents  │  │ Lead + agents  │                 │
│              │  │ Real status    │  │ Real status    │                 │
│              │  └────────────────┘  └────────────────┘                 │
│              │                                                        │
│              │  Agents without a section: [explicit count]             │
└──────────────┴────────────────────────────────────────────────────────┘

All names, counts, and statuses in this diagram are placeholders. A real implementation should display only information supported by OpenBot's actual data.

The main views would have different purposes:

• Overview: understand the fleet at a glance.
• Workflows: understand how steps and agents are connected.
• Organization: understand the grouping or hierarchy of agents.
• Agents: inspect the agents through a familiar list, with useful filters and details.

The purpose is not to force everyone into a new interface. The graphical view should complement the existing lists and conversations, allowing users to move naturally from a high-level overview to the information they need.

2. A graphical workflow view that explains what actually happens

A workflow should be understandable without requiring the user to read its source representation.

The diagram should display real workflow steps, relevant agents, supported relationships, and the order in which steps are connected. A legend would explain each type of relationship.

Conceptual workflow wireframe

┌───────────────────────────────────────────────────────────────────────┐
│ Workflow: [name]                         Data: [freshness / status]    │
├───────────────────────────────────────────────────────────────────────┤
│                                                                       │
│  [Step 1] ────────> [Agent A] ──delegates──> [Agent B]                │
│                         ^                         │                    │
│                         └──────── result ─────────┘                    │
│                                                                       │
├────────────────────────────────────┬──────────────────────────────────┤
│ Workflow steps                     │ Selected element                 │
│                                    │                                  │
│  1. Initial step                   │ Name                             │
│  2. Processing                     │ Role / type                      │
│  3. Delegation                     │ Source of information             │
│  4. Result                         │ Status and last update            │
│                                    │ Available tools or documentation  │
└────────────────────────────────────┴──────────────────────────────────┘

Selecting a step should highlight its corresponding connections. Selecting a node should open an inspector with the facts that are available for that element.

A few principles are particularly important:

• Distinguish dependencies, calls, delegations, inputs, outputs, and other relationship types where the data supports those distinctions.
• Never invent connections merely to make a diagram appear complete.
• If a workflow cannot be interpreted, explain what is unsupported instead of displaying a blank screen.
• Distinguish an empty workflow from loading, stale data, a disconnected server, and a failed request.
• Never imply that an animated connection means an agent is executing unless a real status confirms it.

The graphical view should initially focus on explaining and inspecting workflows. Visual editing and execution controls should be considered separately, using the existing workflow work rather than creating another independent execution system.

3. An overview that makes a large fleet easier to understand

A responsive card grid could give each actual section a compact visual summary.

Each card might show its section name, lead agent when known, number of agents, and relevant activity. Selecting a card would reveal its agents and provide access to their actual conversations.

The number of cards must follow the real fleet. It should not be fixed to an example with nine sections.

Conceptual section card

┌───────────────────────────────────┐
│ Section: Research                 │
│                                   │
│ Lead: [agent, if known]           │
│ Agents: [verified count]          │
│                                   │
│ Activity: [verified information]  │
│ Data freshness: [timestamp]      │
│                                   │
│ [View team]                       │
└───────────────────────────────────┘

The overview must account for every agent in the selected source, including agents whose section or metadata is missing.

It should make the following distinctions clear:

• Total agents versus agents represented in the current view.
• Agents without a known section or group.
• Agent status versus task status.
• A genuinely empty section versus information that is unavailable.
• Current information versus stale or disconnected data.

Metrics such as completed-task percentages, success rates, routine counts, or costs should appear only when there is a documented source for them. An unknown value must not silently become zero, and a missing agent must not disappear from the overview.

4. An optional organizational or hierarchy view

In addition to a graph and a card grid, it could be useful to offer a simple two-dimensional view of the organization.

For example:

                   ┌─────────────────┐
                   │ Coordination    │
                   │ [agent, if real]│
                   └────────┬────────┘
                            │
                   ┌────────┴────────┐
                   │   Sections      │
                   └────────┬────────┘
                     ┌──────┼──────┐
                     │      │      │
                 ┌───┴──┐ ┌─┴───┐ ┌┴─────┐
                 │ Team │ │Team │ │ Team │
                 │  A   │ │  B  │ │  C   │
                 └──────┘ └─────┘ └──────┘

This could help a user understand the structure of a large fleet at a glance, particularly when section names alone are not sufficient.

However, an organizational drawing must not invent a management hierarchy, permissions, or delegation relationships that do not exist in the underlying data. A purely visual arrangement should be identified as such, or be based on an explicitly configured presentation.

The first version could remain a read-only view. If rearranging agents becomes useful, a drag-and-drop interaction could initially provide a local preview rather than immediately changing the saved configuration.

Move agent to another section
           │
           ▼
┌──────────────────────────────┐
│ Preview only — not saved      │
│                              │
│ Original section: A           │
│ Proposed section: B           │
│                              │
│ [Reset preview]               │
└──────────────────────────────┘

Any future persistent change would need a separate, explicit confirmation and a clear explanation of what will change.

5. Make the application context impossible to misunderstand

A graphical overview is only useful if the user knows what they are looking at.

The active server, known workspace or project context, connection state, last successful refresh, and current filters should be visible or easy to discover.

For example:

Server: Production             ● Connected
Workspace: /workspace/project  Last update: 10:32
Showing: 12 of 18 agents       Filter: Research

The interface must not invent a project identity if the current data does not contain one. When the project context is unknown, it should show what is known, such as the active server, and explain the limitation.

The user should be able to distinguish the whole fleet from a filtered selection without having to infer it from the displayed cards.

6. Navigation and accessibility are part of the feature

A graphical control center should not become another page that can only be operated with a mouse.

It would be useful to support:

• A keyboard-accessible command palette, such as Ctrl+K, for finding an agent or opening a page directly.
• Visible focus, predictable keyboard navigation, and accessible names for interactive elements.
• A layout that remains usable in a narrow desktop window.
• The existing OpenBot visual language, shared components, and design tokens.
• Complete translations for the supported interface languages.

The same underlying element should remain recognizable whether it is accessed from a graph, a card, a list, or a conversation.

7. Make Tasks and model choices easier to understand

Two additional UX opportunities fit this wider direction.

Tasks: the page should explain that Tasks is where a human assigns work to agents and follows its progress. It should clearly distinguish agent tasks from scheduled routines and personal to-do lists. Its empty state should explain the first action without suggesting that work has already been sent.

Model selection: a future Model Advisor could help the user understand why a particular model is suitable for a task, based on the required capabilities, tools, context, availability, measured quality, latency, and effective cost.

The advisor should explain its recommendation in human terms rather than asking everyone to compare dozens of model names.

It must distinguish API charges from subscription usage and quota consumption, and disclose when evidence is missing. It should never invent prices or claim that a model is better or cheaper without evidence.

This advisor is a longer-term extension, not a requirement for the first visual overview. Any automatic routing should be evaluated separately, beginning with recommendations that do not change the running agent or provider.

8. Suggested implementation approach

I would not expect every view to be implemented in a single release. The proposal is a common direction for the user experience, which can build on existing work.

First: integrate a useful overview into the existing application, with clear server context, real agent data, accurate counts, and access to the actual agents.

Second: connect the graphical workflow view to real workflow data, with a relationship legend, step selection, an inspector, and honest states for missing or unsupported information.

Third: refine the organization view, safe visual rearrangement previews, keyboard navigation, and the explanation of Tasks.

Later: evaluate a Model Advisor and any more advanced workflow-editing experiences against their own requirements and existing proposals.

This order is a suggestion, not a demand. The maintainers should decide which pieces best fit the current architecture and roadmap.

9. Definition of done: the screen must work inside OpenBot

A graphical component on its own is not the finished user experience. The user needs to be able to reach it and use it in the real application.

For an initial implementation, I would consider the following important:

• The view is reachable through OpenBot's actual navigation, not only through a standalone demo or an unconnected component.
• The information comes from actual available data, and the interface clearly reports missing, stale, or unavailable information.
• Every agent in the relevant source is visible or explicitly accounted for.
• Selecting an element provides useful details and a natural path to its real conversation or workflow.
• Navigation, focus, keyboard access, and responsive layout are usable.
• A screenshot of the running application and a short human UX review accompany the implementation, in addition to automated tests.
• No backend, database, or production changes are introduced merely to make an illustrative diagram look complete. Any necessary data-contract work is identified separately.

Relationship to existing work

I see this proposal as complementary to existing OpenBot discussions and issues:

• #1203 — Add a visual canvas for connecting agents and building workflows
• #1920 — Workflows for agents (triggers, conditions, approvals) on top of routine flows
• #269 — Add groups for organizing agents and conversations

If some parts of the proposal already fit those existing efforts, I would prefer to connect the work to them rather than create duplicate implementation requests.

Questions for the community

Would a native visual Mission Control help you understand and navigate a larger OpenBot fleet?

Which view would be the most useful starting point: the fleet overview, the workflow graph, or the organizational view?

I would also appreciate feedback on which information OpenBot can already expose reliably enough to support these views, and which elements should remain read-only until their underlying data and behavior are clearly defined.