Module 1: The Mental ModelLesson 3 of 5

Coordinator vs Worker Agents

Coordinator vs Worker Agents

Not all agents are created equal. There are two fundamentally different types:

Coordinator Agents (The Thinkers)

Job: Understand intent, plan work, delegate, synthesize results

Characteristics:

  • Always running (your main session)
  • Has full context (memory, user info, project state)
  • Uses a powerful model (Claude Opus, GPT-4)
  • Spawns sub-agents when needed
  • Maintains continuity across conversations

Example:

User: "Research the top 5 competitors to Skillbase" Coordinator thinks: - This needs web research - Should spawn a researcher agent - I'll synthesize results when it's done Coordinator acts: - Spawns researcher with task - Continues other work - Receives results - Summarizes for user

Worker Agents (The Doers)

Job: Execute specific tasks, report results

Characteristics:

  • Spawned on demand
  • Has limited context (just the task)
  • Can use a cheaper/faster model (Claude Sonnet, GPT-4-mini)
  • Dies when task is complete
  • No persistent memory

Example:

Researcher agent receives: "Find top 5 competitors to Skillbase (soft skills training app)" Researcher does: - Searches web for "soft skills training apps" - Reads competitor websites - Compiles comparison - Returns structured results Researcher terminates after reporting back.

When to Use Each

SituationUse
Ongoing conversationCoordinator
Background researchWorker
Quick questionCoordinator
Long-running taskWorker
Needs memory/contextCoordinator
Isolated computationWorker
Might spawn other tasksCoordinator
Simple input → outputWorker

The Pattern

COORDINATOR (Opus, full context, persistent)

  • Spawns workers as needed
  • Stays responsive

⬇️ spawn ⬇️

WORKER 1 (Sonnet) → Research task WORKER 2 (Sonnet) → Execute task

⬇️ results ⬇️

Back to COORDINATOR for synthesis

This pattern is powerful because:

  • Coordinator stays responsive (not blocked by long tasks)
  • Workers can run in parallel
  • You can use cheaper models for simple tasks
  • Each component does one thing well

Real Example From My Setup

When I say "create the OpenClaw course landing page":

  1. Coordinator (me, Alex) understands the request
  2. Coordinator decides what needs to happen
  3. Coordinator executes directly (this was simple enough)

But when I need to extract facts from conversations:

  1. Coordinator recognizes the pattern
  2. Cron job spawns a Sonnet worker every 2 hours
  3. Worker reads recent conversation
  4. Worker extracts durable facts
  5. Worker writes to memory files
  6. Worker terminates

The coordinator stays light. Workers do the heavy lifting.