Router and Orchestrator Patterns

Beyond ReAct and planning, there are two meta-patterns for structuring how agents handle diverse requests: routers and orchestrators.

The Router Pattern

A router classifies the input and dispatches to a specialized handler:

Input: "Schedule a meeting with the design team"
  → Classify: CALENDAR_ACTION
  → Route to: CalendarAgent (has Google Calendar tools)

Input: "What did we decide about pricing in last week's meeting?"
  → Classify: MEETING_SEARCH
  → Route to: MeetingAgent (has Granola + Circleback tools)

Input: "Create a project brief for the new client"
  → Classify: DOCUMENT_CREATION
  → Route to: WritingAgent (has Notion tools + writing style guides)

Routers are fast and predictable. The classification step is cheap (can use Haiku), and each handler is specialized — it only has the tools and context it needs.

Your skills/ system is a router. When you invoke /post-meeting, Claude Code routes to a specialized behavior with specific tools and instructions.

The Orchestrator Pattern

An orchestrator dynamically decides the next step based on current state:

User: "Prepare me for tomorrow's meetings"

Orchestrator:
  Step 1 → Check calendar for tomorrow's meetings [Calendar MCP]
  Step 2 → For each meeting, find relevant notes [Granola/Obsidian]
  Step 3 → Check Linear for related open issues [Linear]
  Step 4 → Compile into prep brief [Write to Obsidian]

Unlike a router, the orchestrator doesn't classify-then-dispatch. It reasons about what to do next based on what it learned so far. The number and order of steps is dynamic.

Your /prep-meetings skill is an orchestrator. It chains multiple tools in a sequence that depends on what it finds.

The Pipeline Pattern

A fixed sequence of stages, each transforming the output of the previous:

Raw meeting transcript
  → Stage 1: Extract action items
  → Stage 2: Categorize by project
  → Stage 3: Create Linear tickets
  → Stage 4: Send Slack summary

Pipelines are the simplest pattern. No dynamic routing, no decision-making between stages. Just data flowing through transforms.

When to use which:

Pattern	Use When	Example
Router	Input type determines the handler	Skill system, chat intent classification
Orchestrator	Steps depend on intermediate results	Meeting prep, research tasks
Pipeline	Fixed sequence, no branching	Transcript → action items → tickets

Combining Patterns

Real systems mix these. An orchestrator might route individual steps to specialized handlers. A pipeline might have an orchestrator at one stage.

Your Claude Code workspace is a hybrid: the skill system acts as a router, each skill internally operates as an orchestrator or pipeline.

❓ Quiz 1

Your /post-meeting skill extracts action items, then saves to Obsidian, then creates Linear tickets. What pattern is this?

A fixed sequence of transformations (transcript → items → save → tickets) is a pipeline. No branching, no dynamic decisions between stages.

Answer to continue ↓

⚖ Decision 1

A client asks: 'Can you prepare a summary of what we've done this month and what's planned for next?' This requires: pulling Linear issues, checking meeting notes, reviewing calendar, and writing a narrative. Which pattern?

A A router dispatches to ONE handler. But this task needs multiple data sources and adaptive logic — the router pattern is too simple here.

B ★ The orchestrator can decide: 'I got the Linear data but there are no meetings this month, let me check Slack instead.' It adapts to what it finds.

C A pipeline works if the stages never change. But what if there are no Linear issues? The pipeline runs empty stages. No adaptation.

Make your choice to continue ↓

🛠 Exercise 1

Design an orchestrator for handling inbound client requests at Muno Labs. It should: identify the client, check their project status (Linear), review recent meetings (Granola), check any pending action items (Obsidian), and draft a response. Describe the decision points — where might the orchestrator take different paths based on what it finds?

✓ Saved