Dynamic Agent Routing by Task Type

Introduction

In our last lesson, you designed the crucial "planning" module for our orchestrator. By combining a Zod schema with the Vercel AI SDK's generateObject function, we can now reliably decompose a complex user request into a structured plan of subtasks. Each subtask in this plan is tagged with an agent field, specifying the role of the specialist needed to execute it.

This lesson tackles the next logical step: acting on that plan. We will implement dynamic agent routing, the mechanism that interprets the agent role for each subtask and dispatches the work to the correct, executable specialist agent. This capability moves us from planning to execution, forming the very core of our hierarchical agent system's workflow. We'll explore how to build this "switchboard" and examine a powerful, production-ready pattern for making routing both intelligent and cost-effective.

From Plan to Action: The Agent Registry

Our orchestrator has produced a plan. Now, it must execute it. The central challenge is translating the agent role—a simple string like "travel_agent" from our plan—into a call to an actual, running agent implementation.

The most direct way to solve this is with an Agent Registry. In practice, this is a mapping structure (like a Map or a plain object in TypeScript) that holds references to your specialist agent implementations. The keys are the agent roles (strings), and the values are the executable agent objects or functions.

When processing the plan, the orchestrator acts as a dispatcher:

1. It iterates through the subtasks in the plan.
2. For each subtask, it reads the agent role.
3. It looks up this role in the Agent Registry.
4. If a match is found, it invokes the corresponding agent, passing the task description and any other necessary context.
5. If no match is found, it triggers an error or a fallback mechanism.

This pattern is visually represented in the diagram below, where an "Intent Classifier" and "Agent Selection & Task routing" module directs the user's request to the appropriate specialist.

Implementing a Basic Routing Workflow

Before we build a sophisticated, cost-optimized router, let's solidify the fundamental pattern with a clear, practical example. The following article demonstrates how to build a simple dispatcher that routes user queries to different specialist agents.

Inspired by that example, a basic implementation in our system would look like this. First, we define our specialist agents and the registry:

// Assume 'runTravelAgent' and 'runFinanceAgent' are functions
// that encapsulate the logic for each specialist agent.
// They would typically use streamText or generateObject.

const runTravelAgent = async (prompt: string, context: any) => {
  // ... agent logic using Vercel AI SDK
  console.log(`TRAVEL AGENT handling: ${prompt}`);
  return { result: "Flight to NYC booked." };
};

const runFinanceAgent = async (prompt: string, context: any) => {
  // ... agent logic
  console.log(`FINANCE AGENT handling: ${prompt}`);
  return { result: "Expense report filed." };
};

// The Agent Registry
const agentRegistry = new Map<string, (prompt: string, context: any) => Promise<any>>([
  ['travel_agent', runTravelAgent],
  ['financial_analyst', runFinanceAgent],
]);

Then, the orchestrator's execution logic would use this registry to dispatch tasks from the plan we generated in the previous lesson:

// Assume 'plan' is the structured object from the previous lesson
async function executePlan(plan: { plan: Subtask[] }) {
  const results = new Map<string, any>();

  for (const subtask of plan.plan) {
    // For now, we ignore dependencies. We will handle this in the next lesson.
    console.log(`Dispatching task: ${subtask.id} to agent: ${subtask.agent}`);

    const agentFunction = agentRegistry.get(subtask.agent);

    if (agentFunction) {
      const result = await agentFunction(subtask.task, {}); // Pass task and context
      results.set(subtask.id, result);
    } else {
      console.error(`Error: Agent role "${subtask.agent}" not found in registry.`);
      results.set(subtask.id, { error: "Agent not found" });
    }
  }

  return results;
}

This simple dispatcher logic is the foundation of dynamic routing. However, for a production-grade system, we can make it much more intelligent and efficient.

Advanced Routing: The Economic Classification Layer

Relying solely on a single, powerful orchestrator model (like GPT-4 or Claude Sonnet) to both decompose and route tasks can be inefficient. Simple queries might unnecessarily consume expensive tokens, and the model might misclassify a task.

A more robust, production-ready pattern is to introduce a cheap, fast classification layer at the very beginning of the process. This "economic router" uses a smaller model (like Claude Haiku) to perform an initial analysis of the user's request before the main orchestrator runs. Its job is to quickly label the request with metadata that guides the rest of the workflow.

This approach is detailed brilliantly in the following article about scaling a multi-agent system.

This pattern modifies our workflow. Instead of the orchestrator immediately decomposing the request, the flow becomes:

1. Input: User provides a raw request.
2. Classification: A fast, cheap model (e.g., Haiku) uses generateObject with a classificationSchema (like the one in the article) to label the request's domain, complexity, and suggestedTier.
3. Routing Decision: The orchestrator uses this classification to make a smarter decision.
   • For a "simple" task, it might handle it directly or use a simple, specialized agent, bypassing the complex decomposition step entirely.
   • For a "complex" task, it proceeds with the full decomposition and planning process we designed in the last lesson, potentially using the suggestedTier to select a more powerful model for the job.

This pre-routing step provides immense benefits:

• Cost Savings: Simple requests are handled by cheap models, saving significant operational costs.
• Lower Latency: Simple requests are fulfilled much faster.
• Improved Accuracy: Routing becomes more explicit and rule-based (e.g., the article's DOMAIN_TIER_OVERRIDES), reducing the chance of a single large model making a poor choice.

This hierarchical classification and dispatching is visible in more complex agent system diagrams, such as the one below.

Integrating with the Vercel AI SDK

The beauty of these patterns is that they map directly to the tools you already use in the Vercel AI SDK.

• The Classifier: Implement the economic router using generateObject with your chosen cheap model and a Zod schema for classification.
• The Sub-Agents: In the Vercel AI SDK, a powerful way to structure your orchestrator is to treat your specialist sub-agents as tools. The orchestrator, after deciding which specialist to use, would invoke it via a tool call.

This concept of an agent using other agents as tools is a cornerstone of hierarchical systems and is mentioned as the "orchestrator pattern" in the Vercel AI SDK ecosystem.

Your agentRegistry could, therefore, store tool definitions, which your orchestrator can dynamically select and provide to its underlying generateText or streamText call.

Conclusion

In this lesson, you have learned how to bridge the gap between planning and execution by implementing dynamic agent routing. We've moved beyond a static plan to a living system that can dispatch work to the correct specialists.

Key Takeaways:

• Agent Registry: A simple map or registry is the fundamental mechanism for connecting abstract agent roles (strings) to executable agent implementations.
• Direct Dispatch: The most basic routing pattern involves an orchestrator looking up an agent in the registry and invoking it directly.
• Economic Routing: A more advanced, production-grade pattern involves using a cheap, fast model to pre-classify requests. This classification (by domain, complexity, etc.) allows the orchestrator to make smarter, more cost-effective routing decisions.
• Sub-Agents as Tools: Within the Vercel AI SDK, a common way to implement the invocation of a sub-agent is to define it as a tool that the orchestrator can call.

You now have a system that can create a plan and route individual tasks. However, our current execution logic processes each task in sequence, ignoring the dependencies field in our plan. In our next lesson, we will address this by implementing logic to manage sequential and parallel task execution, bringing our orchestrator one step closer to handling complex, multi-step workflows.