Module 4: Orchestration
When your workflow needs more than one agent, someone has to be in charge. That's the orchestrator.
The Problem
A contract processing system has multiple jobs: extract text, look up vendor history, check compliance, calculate financial exposure. Each job requires different skills, different data, and different reasoning.
You could build one massive agent that does everything. It would be slow, expensive (huge prompts), and impossible to debug. The alternative: specialized agents coordinated by an orchestrator.
What an Orchestrator Does
The orchestrator is the top-level agent that:
- Receives the incoming task
- Breaks it into subtasks
- Dispatches subtasks to the right agents
- Collects and combines results
- Decides what happens next based on what came back
In Our Contract Workflow
Contract PDF arrives
↓
┌─ Orchestrator ─┐
│ │
┌───────┼────────┐ │
↓ ↓ ↓ ↓
Extraction Vendor Compliance (waits)
Agent Lookup Agent
↓ ↓ ↓
└───────┼────────┘
↓
Orchestrator collects results
↓
Financial Analysis Agent
↓
Human Review (pause)
↓
Report Generation Agent
The orchestrator runs extraction and vendor lookup in parallel (they don't depend on each other). Compliance review starts after extraction finishes (it needs the clause data). Financial analysis runs after compliance (it needs the risk flags).
Static vs Dynamic Orchestration
Static orchestration - The workflow is predefined. Step A, then B and C in parallel, then D. The orchestrator follows a fixed plan. This is what most production systems use. It's predictable, testable, and debuggable.
Dynamic orchestration - The AI decides the workflow at runtime. "Given this contract, what agents do I need?" This is more flexible but harder to test. Use this when the workflow genuinely varies based on input (e.g., different contract types require different analysis).
For most enterprise use cases, static orchestration with conditional branches is the right balance. You define the happy path and the edge cases. The orchestrator follows the plan and adapts only where you've told it to.
Orchestration Patterns
| Pattern | When to Use | Example |
|---|---|---|
| Sequential | Steps depend on each other | Extract, then analyze, then report |
| Parallel | Steps are independent | Extract + vendor lookup simultaneously |
| Conditional | Next step depends on results | If high risk, add deeper compliance review |
| Fan-out / Fan-in | Same task on multiple inputs | Analyze 5 contracts in parallel, combine results |
What to Put in the Orchestrator vs Subagents
The orchestrator should handle routing, sequencing, and error handling. It should not do the actual analysis work.
Orchestrator's job: "Send this to the compliance agent. If it comes back with high risk, also send it to the legal review agent."
Not the orchestrator's job: "Analyze this clause for compliance with SOC 2 requirements." That's the compliance agent's job.
Keep the orchestrator thin. If your orchestrator prompt is longer than 20 lines, you're putting too much logic in the wrong place.
What's Next
The orchestrator dispatches work to specialists. In Module 5: Subagents, we cover how to design those specialists so they're fast, focused, and maintainable.
Orchestration Lab
Build a multi-agent orchestrator using AWS Bedrock and Strands SDK with parallel execution, conditional routing, and error recovery.