Planner

The Planner takes a research direction and turns it into a concrete, actionable experiment design. It is a thinking agent — it reasons about experimental methodology but never writes code or runs experiments.

Identity

Property	Value
LLM	Claude Opus
Invocation	Sub-agent (spawned by Orchestrator)
Lifecycle	Per-task — created for a planning task, terminated when done
Context	Inherits partial context from Orchestrator

When Invoked

The Planner is called at specific points in the pipeline:

Stage	Trigger	Planning Task
Design	Idea selected	Full experiment plan — baselines, ablations, metrics
Implementation	Plan approved	Task decomposition for Coder
Analysis	Results ready	Analysis strategy — what comparisons, what visualizations
Writing	Analysis approved	Paper outline and section structure
Review	Reviews received	Revision plan — what to address, what to rebut

The Planner is invoked multiple times

It's not a one-shot agent. Each pipeline stage may invoke the Planner to decompose the next phase of work. The Planner adapts its output format to the task.

What It Receives Per Task

The Orchestrator curates context for each Planner invocation:

Design Stage

inputs:
  - selected_idea: ideas/selected.yaml
  - related_work: papers/related_work/summaries.yaml
  - constraints: infrastructure.yaml (GPU count, memory, time budget)
  - venue_target: "ICML 2025"

Implementation Stage

inputs:
  - experiment_plan: design/plan.md
  - baselines: design/baselines.yaml
  - codebase_summary: "PyTorch, 3 existing modules, ~2k LOC"

Analysis Stage

inputs:
  - experiment_results: experiments/summary.yaml
  - original_hypotheses: design/plan.md (hypothesis section)
  - metrics: design/metrics.yaml

What It Outputs

All output goes to disk in .omc/research/. The Orchestrator receives a one-line summary.

Output	File	Contents
Experiment plan	design/plan.md	Hypotheses, method description, experiment structure
Baselines	design/baselines.yaml	Name, paper, code link, expected performance
Ablations	design/ablations.yaml	What to ablate, expected impact, priority
Metrics	design/metrics.yaml	Primary/secondary metrics, statistical tests
Task list	design/tasks.yaml	Numbered tasks for Coder, with dependencies
Paper outline	papers/outline.md	Section structure, target lengths, key claims
Revision plan	reviews/revision_plan.md	Review-by-review response strategy

Output is structured, not prose

The Planner writes structured YAML and focused Markdown — not open-ended essays. This makes outputs machine-readable for other agents and scannable for humans.

Example: Baselines Output

# design/baselines.yaml
baselines:
  - name: "Vanilla Transformer"
    paper: "Vaswani et al., 2017"
    code: "https://github.com/..."
    expected_ppl: 18.0
    purpose: "Standard attention baseline"
    
  - name: "Linear Transformer"
    paper: "Katharopoulos et al., 2020"
    code: "https://github.com/..."
    expected_ppl: 20.5
    purpose: "Linear attention baseline — our method should match or beat"
    
  - name: "RetNet"
    paper: "Sun et al., 2023"
    code: "https://github.com/..."
    expected_ppl: 18.5
    purpose: "Recurrent baseline — our method combines this with flash attention"

What It Does NOT Do

Clear boundaries

The Planner has strict boundaries. Violating these is an architectural error caught by the omc-orchestrator hook.

The Planner Does NOT	Why
Write code	That's the Coder's job
Run experiments	That's the Coder's job
Evaluate results	That's the Judge's job
Search literature	That's the Scout's job
Write paper text	That's the Writer's job
Make strategic decisions	That's the Orchestrator's job
Decide which experiment to prioritize	That's the Orchestrator's job

The Planner designs. It says "we should run experiment X with config Y and expect result Z." It never executes that design.

What if the Planner needs literature?

If the Planner needs information about a baseline paper, it flags this to the Orchestrator in its output: "needs_info: [baseline paper X details]". The Orchestrator then dispatches Scout to fetch the information and re-invokes the Planner with the additional context. The Planner never calls Scout itself.

Next

• Writer — the other Claude Opus agent
• Coder — who implements the Planner's designs
• Design Stage — where the Planner does most of its work