[Design] Supervisor support in the frontend — manage endpoint UX and end-to-end implementation

[sami-marreed]

What you want and why

The CUGA frontend today is built around a single-agent experience: one agent, one set of policies, one chat interface. As the supervisor (multi-agent orchestration) matures on the backend, the frontend needs a first-class way to:

1. Configure a supervisor — define which sub-agents it orchestrates, set supervisor-level policies, and toggle plan approval.
2. Connect to the right endpoint — the supervisor exposes a different entry point than a standalone agent; the frontend must know which mode it is in and route requests accordingly.
3. Experience the supervisor at runtime — show the operator/user which sub-agents are running, display the plan approval gate when it fires, and surface per-agent status inline.

This issue covers proposing a design and then implementing it, keeping the manage-endpoint experience central to the proposal.

How it could work

Areas to address in the design

1. Manage endpoint integration

• How does the frontend discover whether it is connected to a standalone CugaAgent or a CugaSupervisor?
• Should the /manage endpoint return a capability manifest (e.g. { "mode": "supervisor", "agents": [...], "policies": [...] }) that the UI reads to adapt its layout?
• What changes, if any, are needed in the manage endpoint to support supervisor metadata?

2. Supervisor configuration screen

• Where in the existing UI does supervisor setup live? (New top-level tab? Extension of the existing agent config panel?)
• How does a user add/remove sub-agents, set their order, and assign routing rules?
• How are supervisor-level policies (intent guard, playbook, routing, sequencing, approval) configured visually — reuse the existing policy panel or a new supervisor-specific one?
• Plan approval toggle: where does it live and what does enabling it look like at runtime?

3. Runtime / chat experience

• When the supervisor is active, how is the multi-agent execution surfaced? (Collapsible sub-agent trace? Step-by-step timeline? Status chips?)
• Plan approval gate: how does the UI pause, display the proposed plan, and collect operator approval before the supervisor dispatches sub-agents?
• Error and partial-failure states: one sub-agent fails — what does the user see?

4. Mode switching

• Can a user toggle between standalone-agent mode and supervisor mode in the UI, or is the mode fixed at deploy time via the manage endpoint?

Proposed deliverables

1. Design document / wireframes — covering all four areas above, with a recommended approach for the manage endpoint contract
2. Manage endpoint changes — any backend additions needed to surface supervisor capabilities to the frontend
3. Frontend implementation — supervisor config screen, runtime trace, and plan approval UX

Links or extra context

• Supervisor policy system v1 (SDK): [Feature] Supervisor policy system v1 — intent guard, output formatter, playbook, routing, sequencing, approval + plan approval step #100
• Policy document parser epic: [Epic] Parse a policy document into structured policy definitions for agent and supervisor #99
• Existing manage endpoint and policy UI are the reference starting points — the design must be additive and not break the standalone-agent experience