Skip to main content

​
Overview

Orchestrator mode transforms a task from a single worker into a coordinator that plans, decomposes, and delegates work across multiple child tasks. Instead of implementing code directly, the orchestrator creates subtasks that each handle a specific piece of the work in parallel.

​
Simple vs orchestrator mode

Simple modeOrchestrator mode
Agent behaviorReads, writes, and runs code directlyPlans and delegates — never implements directly
SubtasksNone (all work in one container)Spawns child tasks for each piece of work
Best forFocused, single-scope changesLarge features, multi-file refactors, complex tasks
ParallelismSequential within one agentMultiple agents working simultaneously
Toggle between modes using the mode selector in the composer toolbar before launching a task.

​
How orchestration works

When you launch a task in orchestrator mode:
1

Planning

The orchestrator analyzes your prompt and breaks the work into independent pieces. It determines which parts can run in parallel and which need to be sequential.
2

Delegation

The orchestrator creates child tasks for each piece of work using the Whim MCP tools available inside its container. Each child task gets a self-contained prompt with a clear objective, all necessary context, and scope boundaries.
3

Execution

Child tasks run in their own isolated containers, working on the same codebase branch. Each child implements its assigned piece independently.
4

Reporting

When a child task finishes or hits a blocker, it reports results back to the orchestrator. The orchestrator does not poll children — it waits for them to report in.
5

Synthesis

After all children complete, the orchestrator synthesizes the results and reports the overall outcome to you.

​
Subtask lifecycle

Child tasks created by an orchestrator follow the same task lifecycle as any other task. They appear in your workspace as nested items under the parent. The orchestrator includes its own display ID in each child’s prompt and instructs children to report back via send_prompt. This creates a natural communication loop:
  1. Orchestrator creates child with instructions + its display ID
  2. Child works on the task autonomously
  3. Child sends results or blockers back to the orchestrator
  4. Orchestrator processes the report and decides next steps
The orchestrator is instructed to wait for children to report back rather than polling them. If a child hasn’t reported, it’s still working. The orchestrator only intervenes if you explicitly ask it to check on progress.

​
Parent-child nesting

Whim supports one level of task nesting. An orchestrator (parent) can create child tasks, but children cannot nest further.
  • Child tasks appear indented under their parent in the sidebar
  • Completing a parent prompts you to also complete active children
  • You can manually nest or unnest tasks using the task context menu
If you need deeper decomposition, have a child task use orchestrator mode to coordinate its own subtasks — but the visual nesting in the UI stays at one level.

​
When to use each mode

Use Simple mode when

  • The task has a clear, focused scope
  • Work fits in a single agent’s context
  • You want direct control over execution
  • The change is straightforward (bug fix, small feature, refactor of one area)

Use Orchestrator mode when

  • The task spans multiple files or modules
  • Work can be parallelized across independent pieces
  • You want faster completion through concurrent agents
  • The scope is large enough that one agent would struggle with context

​
Example workflows

​
Large refactor

“Rename the UserService class to AccountService across the entire codebase, update all imports, and fix any tests.” The orchestrator might create:
  • Child 1: Rename the class and update the core module
  • Child 2: Update all import statements across the frontend
  • Child 3: Update all import statements across the backend
  • Child 4: Fix and re-run the test suite

​
Multi-feature implementation

“Add user profile pages with avatar upload, bio editing, and activity history.” The orchestrator might create:
  • Child 1: Build the avatar upload component and API endpoint
  • Child 2: Build the bio editing form and persistence
  • Child 3: Build the activity history timeline component
  • Child 4: Create the profile page layout that combines all three

​
Cross-cutting concern

“Add structured logging to all API endpoints in the server.” The orchestrator might create one child per route file, each independently adding logging to its set of endpoints.