The Orchestrator

This page exists so you're not surprised when you see the orchestrator surface in the UI. It's internal plumbing; you don't need to know about it for any normal use.

The orchestrator in one paragraph

The orchestrator is ARDS's internal reasoning and routing layer. When it needs to make a decision that isn't a single tool call — picking which coder variant to assign, deciding whether to split a task in two, comparing two possible implementation paths — it dispatches a small research mission to its reasoning layer. That layer runs a parallel investigation (codebase, docs, web), synthesises an answer, and hands it back to the orchestrator to act on.

The orchestrator dashboard

The Orchestrator page is not in the sidebar — open the All features index (the "…" entry at the bottom of the sidebar) and look for Orchestrator. The dashboard shows an overview — expert status, queries handled, recent maintenance waves — and an Explore row of sibling surfaces:

  • Team Compositions — team composition history and recommendations.
  • Intent Expansions — intent expansion history and implication rules.
  • Living Diagrams — auto-generated system diagrams with diff tracking.
  • System Health — system harmony analysis and balance metrics.
  • Scenario Runner — system validation scenarios and test execution.
  • Validation Harness — test prompts across multiple LLMs and compare responses.
  • Email Channel — outbound notifications and inbound email processing.
  • Migration Dashboard — system migration planning and context mapping.
  • Expert Traces — debug expert routing, consultations, and response quality.

These are research surfaces, and browsing them is safe — but not everything is read-only. Trigger Maintenance on the dashboard sits behind a confirmation dialog; Scenario Runner has live Run and Run All buttons that actually execute validation scenarios; and Validation Harness has a New Run panel that sends test prompts to several LLMs (real calls, real spend), plus a Cancel on runs in flight. Leave those controls alone unless an operator asks; everything else you can explore freely without breaking anything.

When you'll see the orchestrator in the UI

  • In mission decomposition: a long-running mission may show "Investigating…" during planning. That's the orchestrator's reasoning layer at work, and it's normal. Missions that run a workflow largely skip this decomposition-time reasoning — the graph already is the plan — so the "Investigating…" behavior applies to conversation-born missions.
  • In Costs: there's an Orchestrator call-site row alongside Planning, Coder, Review Engine. Usually a small fraction of total spend.
  • In Search results: research mission outputs are searchable like conversations.

What testers can actually do with the orchestrator

Nothing you need to, in v1. There's no "start an orchestrator research" button exposed to testers; the orchestrator triggers its reasoning layer as needed. (The one active control on its dashboard, Trigger Maintenance, is for operators.)

If you want a research-style answer from ARDS — "survey the codebase and tell me what's there" — the right path is to start a Conversation and ask for that. The planner will route it through the orchestrator under the hood.