Orchestration App

Why Visibility Matters

A multi-agent system that works perfectly but shows users a spinner for 30 seconds will not be trusted. Users need to see what's happening: which agent is working, how confident it is, which tasks are blocked, and what the final output looks like before it's delivered.

This isn't just UX polish — it's a trust requirement. Enterprise buyers won't deploy a black box that sends emails and writes memos on their behalf. They need to see the agents' reasoning, approve individual outputs, and understand why a particular decision was made.

The Orchestration UI

The orchestration interface has three layers:

1. Chat Interface

Users submit queries in natural language. The interface looks like a chat — because that's the mental model users already have for AI interactions. But under the hood, it's not a chatbot. It's a command center that dispatches to multiple agents.

2. Agent Execution Panel

When the orchestrator processes a query, the UI shows each sub-task as a row:

✅ researcher   Research NovaTech Platform 3.0          (80%)
✅ analyst      Analyze market impact                    (75%)
⏳ coder        Build performance benchmark             (pending)
🔄 writer       Draft response strategy memo            (running)

Each row shows: status icon, agent role, task title, and confidence score. Status updates as tasks complete. This gives users real-time insight into the orchestration — they can see which agents are working, which are done, and which are waiting on dependencies.

3. Result Assembly

When all tasks complete, the assembled output appears as the assistant's response. Each agent's contribution is labeled so users can trace any statement back to its source.

Request/Response vs. Streaming

The current implementation uses request/response: submit a query, wait for the entire orchestration to complete, then render all results. This works for demos but fails in production where orchestrations take 10-60 seconds.

Streaming is the production pattern. The API sends Server-Sent Events (SSE) as each milestone occurs:

With streaming, users see progress in real-time. The researcher starts working at second 2. The analyst lights up at second 8. The writer finishes at second 25. The experience transforms from "waiting for a black box" to "watching a team collaborate."

The API Route

The server-side endpoint bridges the UI to the orchestrator:

In production, the route also:

Approval UX

For enterprise deployment, the UI needs approval workflows:

Inline Approval

Each agent output shows "Approve / Revise / Reject" buttons. The user can approve the research but request revisions to the memo before it's assembled into the final output.

Confidence Thresholds

Outputs above a configurable confidence threshold (e.g., 0.85) can auto-approve. Outputs below the threshold require explicit user approval. This reduces friction for high-quality outputs while maintaining control over uncertain ones.

Batch Approval

For experienced users, a "Review All" mode shows all agent outputs on one screen. The user scans, approves or flags, and the orchestrator proceeds. This is faster than approving one-by-one.

Task Timeline Visualization

Beyond the flat task list, a timeline view reveals the orchestration's structure:

Time (seconds)  0    5    10   15   20   25
researcher     [==========]
analyst                    [=======]
coder                      [====]
writer                                  [========]

This shows parallelism (analyst and coder overlapping), dependency bottlenecks (writer waiting for all three), and agent speed (coder is fastest, writer takes longest). This is the view that helps you optimize — if the writer consistently takes 3x longer than other agents, maybe its system prompt is too verbose or it's getting too much context.