Orchestrator-Workers Workflow

Orchestrator-Workers Workflow patterns allows an LLM to choose the best approach to finish a task. This pattern works naturally with Agent as Tool pattern. All we need to do is to register all possible agents as tools. The LLM decides which tools to use to finish a task.

Implementation

Implementation of this pattern requires carefully crafted prompt templates and agents as tools.

Writing the prompt templates for the orchestrator used to be a hard task, which requires usage of certain prompt engineering techniques, e.g. ReAct or CoT. Now this has been dramatically simplified with the emergence of reasoning models like DeepSeek R1 and OpenAI o1. When using reasoning models, we can still simply describe the tasks to do. Even these tasks are very complicated, reasoning models can still finish these tasks.

In the Orchestrator-Workers Workflow pattern, it's natural of the orchestrator to use a reasoning model. This reasoning model acts as the planner of task executions. It plans the subtasks to execute. Subtasks are executed using normal models.

For example, when using OpenAI, the orchestrator can use o1 or o3-mini models for reasoning. Workers can use gpt-4o or gpt-4o-mini models.

Example

A good example of using this pattern is handling outages and incidents. An orchestrator uses workers to gather information from various sources, including logs, metrics, traces, deployment history, git commits. Then this orchestrator analyses these information to identify potential causes of this outage and write a report. Developers can base on this report to find the actual cause of an outage.