Orchestrator-Worker Pattern

Up till now, we have seen powerful agents, but all of them had a limitation: they only worked when the steps were fixed and predictable.

But what about complex problems where the necessary steps change with every request? Imagine asking an expert to “research the market for electric bikes.” They wouldn’t follow a rigid, pre-defined script. Instead, they would first create a custom plan based on your specific goal. This is where we level up to a more dynamic and intelligent design: the orchestrator-worker pattern.

Think of it like hiring a savvy general contractor for a complex project. A central “orchestrator” LLM acts as the contractor, analyzing the main goal, dynamically breaking it down into smaller jobs, and delegating those jobs to specialized “worker” LLMs. Once the workers are done, the orchestrator gathers their contributions and synthesizes them into a single, cohesive final product.

This pattern unlocks a new level of agentic capability, allowing our systems to tackle problems that require genuine planning and adaptation. In this lesson, we’ll build an agent that embodies this very pattern, designing an orchestrator capable of reasoning about a task, defining its own sub-tasks, and dispatching them to workers. You’ll see how to manage this dynamic flow, handle the results from multiple workers, and piece them together to solve a problem that a single LLM call would struggle with. Let’s get ready to build our first true agent project manager.

How is this different from other patterns?

To understand its unique strengths, let’s first clarify how this powerful pattern is distinct from the workflows we’ve already discussed. In a simple prompt chain, the workflow is a predictable, linear assembly line: Task A’s output becomes Task B’s input, and so on. This is perfect when you can decompose a problem into a fixed sequence of steps, like writing an outline and then writing a document based on that outline. The orchestrator-worker pattern, however, doesn’t follow a rigid script.

This might also sound a bit like the parallelization pattern we just built, but there’s a critical difference. In our previous lesson, the subtasks were pre-defined and static: we always ran a support check and a security check. The orchestrator pattern is far more flexible. The central orchestrator LLM doesn’t just execute a list of known tasks; its primary job is to create that list based on the user’s unique request. The number of workers and what each one does is decided in real-time.

When to use this design pattern?

This dynamic flexibility makes the orchestrator pattern perfectly suited for complex, open-ended problems where the solution path isn’t known in advance.

For a coding agent, imagine a user requests, “Refactor our app’s authentication to use JWTsJSON Web Token instead of session cookies.” A simple LLM call would likely fail. An orchestrator, however, would first act as a project lead, generating sub-tasks like:

1. “Scan the codebase to identify all files that handle user ...