---
id: "concept-orchestrator-pattern"
type: "concept"
source_timestamps: ["07:00:00", "07:15:00", "07:30:00"]
tags: ["ai-agents", "routing", "architecture"]
related: ["concept-shift-in-callers", "concept-skill-composability", "concept-description-routing-signal"]
definition: "An agent architecture where a master 'orchestrator' skill analyzes incoming requests and routes them to specialized sub-agents."
sources: ["s43-file-format-agreement"]
sourceVaultSlug: "s43-file-format-agreement"
originDay: 43
---
# The Orchestrator Agent Pattern

## Definition

An agent architecture where a master *orchestrator* skill analyzes incoming requests and routes them to specialized sub-agents.

## The Pattern

As teams build more sophisticated agentic workflows, they are moving beyond single-agent setups to multi-agent systems managed by an Orchestrator. In this pattern:

1. A master skill (the **Orchestrator**) acts as the front door for incoming requests.
2. Its sole job is to **analyze** the high-level request and **decide** what needs to be done.
3. It then **spawns or routes** the work to specialized sub-agents:
   - a research agent
   - a coding agent
   - a UI agent
   - a documentation agent
   - etc.

## Why Descriptions Are Critical Here

The Orchestrator relies on the **descriptions** of the sub-skills to know which agent to call. This is exactly why [[concept-description-routing-signal]] matters so much: in an orchestrator topology, a vague description means a sub-agent never gets called.

## Outcome

This allows a single, vague human request to be reliably *fanned out* to a team of specialized AI workers, ensuring that complex tasks are handled by the most appropriate models and methodologies. It is the natural extension of [[concept-specialist-stack]] when stacks themselves become too large for one agent to navigate alone.

## Related

- [[concept-skill-composability]] — the substrate that makes orchestration possible
- [[concept-skills-as-contracts]] — agents must trust the outputs of sub-agents to compose them