Panels & Orchestrators

When one agent isn’t enough, the Studio offers two coordination nodes that convene a roster of agents. Both read their members from Membership edges pointing at Agent reference nodes — you don’t list members in config, you wire them on the canvas.

Panel — round-table debate

A Panel runs a peer-to-peer deliberation. Inspired by MAI-DxO-style diagnostic panels, every member sees a shared transcript and contributes in turn.

1. For each round (up to max_rounds, default 3), each member speaks in roster order, seeing the shared transcript so far.
2. After each round, the moderator LLM reads the transcript and decides whether to stop.
3. The moderator synthesizes the final conclusion.

Config: model (moderator), max_rounds, moderator_prompt.

Use it for: diagnosis and deliberation where multiple perspectives should see each other and build on the discussion — e.g. a hospital-simulation panel of specialists.

Orchestrator — hierarchical delegation

An Orchestrator runs a planner-led hierarchy. Members never see each other; the planner is the only one with the full picture.

1. The planner LLM receives the task and decomposes it.
2. It delegates sub-tasks to member agents (up to max_delegations, default 10).
3. If adaptive is on, it re-plans based on results before delegating again.
4. It synthesizes the final answer from the collected results.

Config: model (planner), max_delegations, planning_prompt, adaptive.

Use it for: task decomposition where one coordinator routes work to isolated experts — e.g. “research this, then draft, then fact-check” handed to specialized agents.

Panel vs. Orchestrator

Aspect	Panel	Orchestrator
Topology	Peer-to-peer	Hierarchical
Visibility	Shared transcript, all see all	Members isolated; only planner sees all
Coordinator role	Moderates, decides stop, synthesizes	Plans, delegates, re-plans, synthesizes
Flow	Round-robin speeches	Delegated sub-tasks
Best for	Deliberation / debate	Decomposition / routing

Tip

To build either: drop the coordinator node, drop one Agent reference node per member (each pointing at an agent definition), then draw a Membership edge from the coordinator to each member. Each member still respects its own memory and communication policy.

Implementations live in backend/src/agents/panel.rs and backend/src/agents/orchestrator.rs.