Designing an Agent Orchestrator

Introduction

In our previous lesson, we focused on the final step of a multi-agent workflow: how a supervisor agent can aggregate and synthesize results from multiple workers into a single, cohesive response. We learned to manage both sequential and parallel sub-tasks, effectively building the "join" part of a fork-join pattern.

This lesson takes a crucial step back to address the "fork" itself. Before an orchestrator can synthesize results, it must first determine what work needs to be done. This lesson focuses on the very first responsibility of our central orchestrator: decomposing a complex, high-level user request into a structured plan of discrete, actionable subtasks. This "planning" phase is fundamental to transforming a monolithic query into a manageable workflow for your agent hierarchy.

The Orchestrator as a Planner

In any sophisticated system, whether human or artificial, complex goals are achieved by breaking them down into smaller steps. Your orchestrator agent must function as an expert project manager. When it receives a request like, "Book a flight to New York for next Tuesday, find a hotel near Central Park, and add a reminder to my calendar," it doesn't try to solve it all at once. Instead, it creates a plan.

This planning stage is where the orchestrator's intelligence is first applied. It must:

1. Analyze the user's intent to identify all the distinct objectives.
2. Decompose the overall request into a set of specific subtasks.
3. Structure these subtasks into a formal plan that the rest of the system can execute.

This "Orchestrator-Worker" model is a common and powerful pattern in agentic design. The orchestrator plans the work, and the specialized worker agents execute it.

The Core Mechanism: From Intent to Structured Plan

The key to implementing this planning phase is to have the orchestrator LLM generate not a text-based answer, but a structured data object—the plan itself. Within the Vercel AI SDK, the most effective way to achieve this is by combining the generateObject function with a Zod schema.

You've worked with structured outputs before, but now we'll apply this technique to define the very blueprint of our agentic workflow. To ensure you're comfortable with this core mechanism, it's worth briefly revisiting the fundamentals.

Designing the Task Plan Schema

The "design" part of this lesson's outcome lies in creating a robust Zod schema that captures all the necessary information for a task plan. A well-designed schema is the contract between your orchestrator (the planner) and the execution engine (which we'll build in subsequent lessons).

A complete plan is typically an array of subtask objects. Each subtask object should contain at least the following fields:

• id: A unique identifier for the task (e.g., a UUID), which is crucial for tracking dependencies.
• task: A clear, natural-language description of what the worker agent needs to accomplish. This will serve as the core prompt for the worker.
• agent: The role or type of specialist agent best suited for the task (e.g., flight_booker, hotel_finder). This field is the key to our next lesson on dynamic routing.
• dependencies: An array of task ids that must be completed before this task can begin. An empty array signifies a task that can start immediately.

Here is what such a schema might look like in Zod:

import { z } from 'zod';

// Schema for a single subtask within the plan
const subtaskSchema = z.object({
  id: z.string().describe('A unique identifier for this task.'),
  task: z.string().describe('The specific instruction or prompt for the worker agent.'),
  agent: z.string().describe('The role of the specialist agent required for this task (e.g., "financial_analyst", "travel_agent").'),
  dependencies: z.array(z.string()).describe('A list of task IDs that must be completed before this one can start.'),
});

// Schema for the complete execution plan
const planSchema = z.object({
  plan: z.array(subtaskSchema).describe('A list of subtasks to be executed.'),
});

With this schema, the orchestrator can take the user's request ("Book a flight, find a hotel, set a reminder") and produce a structured output like this:

{
  "plan": [
    {
      "id": "task-1",
      "task": "Find and book a flight to New York for next Tuesday.",
      "agent": "travel_agent",
      "dependencies": []
    },
    {
      "id": "task-2",
      "task": "Find a hotel near Central Park for the same dates.",
      "agent": "travel_agent",
      "dependencies": ["task-1"]
    },
    {
      "id": "task-3",
      "task": "Add a calendar reminder for the booked flight.",
      "agent": "personal_assistant",
      "dependencies": ["task-1"]
    }
  ]
}

Notice how this plan captures not just the tasks but also their relationships, enabling both parallel (task-2 and task-3 can run concurrently) and sequential (task-2 depends on task-1) execution.

Implementing the Planning Agent

Now, let's look at a practical implementation. The following article provides a clear TypeScript example of an orchestrator that creates a work plan, perfectly illustrating how to combine the prompt, schema, and generateObject function.

The system prompt is the other half of this equation. While the Zod schema defines the structure of the plan, the system prompt provides the reasoning logic for the decomposition. A good prompt for our orchestrator would be:

"You are an expert project manager AI. Your primary function is to analyze a user's request and decompose it into a detailed, step-by-step execution plan. For each step, define a unique ID, a clear task description, the required specialist agent role, and any dependencies on other tasks. You must generate the plan in the provided JSON schema format."

By combining this explicit instruction with the planSchema, you give the LLM both the "what" and the "how" to generate a perfect task plan.

The "Orchestrator-Workers" pattern described in the article below provides another, slightly different real-world analogy of a "Tech Lead" agent breaking down a feature request for its team. This reinforces the universality of the decomposition pattern.

Conclusion

You have now designed the "brain" of the orchestrator—its planning module. By leveraging the Vercel AI SDK's generateObject function with a carefully constructed Zod schema and a precise system prompt, you can reliably decompose complex user requests into a structured, machine-readable execution plan. This plan forms the foundation upon which all subsequent agentic actions—routing, execution, and synthesis—will be built.

Key Takeaways:

• Orchestrator as Planner: The first role of an orchestrator is to act as a planner, decomposing complex requests into a series of smaller, manageable subtasks.
• Structured Plans: The output of the planning phase is not text but a structured data object (a plan), which is best generated using generateObject and a Zod schema.
• Task Schema Design: A robust task schema should include a unique ID, a task description, the required agent role, and a list of dependencies.
• Prompting for Decomposition: The system prompt for the orchestrator must clearly instruct it to analyze the user request and create a plan according to the specified schema.

We now have a structured plan that tells us what needs to be done. The next logical step is to execute it. In the upcoming lesson, we will implement dynamic agent routing, where we'll learn how to interpret this plan and dispatch each subtask to the correct specialist agent in the hierarchy.