Orchestrator

The Orchestrator is the central intelligence of AutoResearch. It is the only entity that holds the full research vision and makes strategic decisions.

Identity

Property	Value
LLM	Claude Opus
Session	Main Claude Code session (persistent)
Lifecycle	Lives for the duration of a research session
Invocation	The user interacts with this directly

What It Knows

The Orchestrator's context is injected with:

• Pipeline state — current stage, gate configuration, stage history
• Research vision — the selected idea, high-level goals
• Agent health — which agents are alive and responsive
• Recent summaries — one-line results from the last few agent tasks
• Current task context — whatever's relevant to the active decision

Context is curated, not comprehensive

The Orchestrator does not hold the full text of papers, complete training logs, or all experiment results in context. It holds summaries and knows where to find details on disk.

What It Doesn't Know

• Full training log contents (only latest summary)
• Complete paper draft text (only outline and current section status)
• Internal reasoning of other agents
• Code implementation details (only test results)
• Literature survey raw data (only structured summaries)

This is by design

The Orchestrator doesn't need to know implementation details to make good strategic decisions. Knowing "tests pass, performance matches spec" is sufficient. Reading 500 lines of code would waste precious context.

Decisions It Makes

The Orchestrator is the sole decision-maker for:

Decision	When	Based On
Advance to next stage	After gate clears	Judge verdict + own assessment
Which agent to invoke	Every task	Current stage + task type
What context to give an agent	Every dispatch	Agent role + task needs
Whether to retry or escalate	On failure	Error type + retry count
When to involve human	At human gates or errors	Gate config + severity
Research direction pivots	When results surprise	Results + original hypothesis
Resource allocation	Multiple experiments	Priority + GPU availability

What It Controls

graph TD
    O[Orchestrator]
    O --> S[Stage Transitions]
    O --> A[Agent Dispatch]
    O --> G[Gate Decisions]
    O --> C[Context Curation]
    O --> E[Error Escalation]
    O --> R[Resource Allocation]

    style O fill:#f9f0ff,stroke:#7c3aed,stroke-width:2px

Stage Transitions

The Orchestrator is the only entity that can advance the pipeline from one stage to the next. No agent can self-promote.

Agent Dispatch

Every agent invocation originates from the Orchestrator. No agent invokes another agent.

Gate Decisions

When a gate is set to human, the Orchestrator pauses and presents the decision to the user. When set to auto-judge, it dispatches the Judge and acts on the verdict.

Context Curation

The Orchestrator decides what information each agent receives. The Writer gets clean, curated results. The Coder gets precise specifications. The Judge gets only the artifact to evaluate.

Error Escalation

When an agent fails and retries are exhausted, the Orchestrator decides whether to try a different approach, invoke a different agent, or escalate to the human.

Enforcement: omc-orchestrator Hook

The OMCC harness includes a pre-commit hook called omc-orchestrator that enforces architectural rules:

Rule	What It Prevents
No self-review	An agent cannot review its own output for gate decisions
No direct agent-to-agent	Agents cannot dispatch tasks to each other
No stage skip	Pipeline stages must be completed in order
No gate bypass	human gates cannot be auto-cleared
State consistency	pipeline.yaml must be consistent with disk state

The hook is not optional

The omc-orchestrator hook runs on every state-changing operation. It cannot be disabled during normal operation. This prevents the Orchestrator (or any agent) from accidentally violating system invariants, even under high-autonomy modes like autopilot.

# Example hook failure
# Attempted: Judge reviewing its own code output
# Hook response:
error: "Cross-LLM review violation"
detail: "Judge (Codex) cannot review artifact created by Coder (Codex)"
suggestion: "Route to Orchestrator (Claude) for code review"

Lifecycle

stateDiagram-v2
    [*] --> Init: /research init
    Init --> LoadState: Read pipeline.yaml
    LoadState --> Decide: Assess current stage
    Decide --> Dispatch: Choose agent + task
    Dispatch --> Wait: Agent working
    Wait --> Receive: Agent returns summary
    Receive --> Decide: Next decision
    Decide --> Gate: Stage complete
    Gate --> HumanWait: gate=human
    Gate --> JudgeEval: gate=auto-judge
    Gate --> AutoAdvance: gate=auto
    HumanWait --> Decide: Human approves
    JudgeEval --> Decide: Judge passes
    AutoAdvance --> Decide: Auto-continue
    Decide --> [*]: All stages complete

Next

• Planner — the Orchestrator's planning sub-agent
• Architecture — system topology
• Pipeline — the stages the Orchestrator drives