Multi-Agent Workflow Design with Task Routing and Delegation

Recommended resources

The freely available resources this lesson will direct you to.

Welcome back! In our last lesson, you built your first single-purpose AI agent, learning how the Thought -> Action -> Observation loop is implemented through tool calling. This is the foundational skill for creating agents that can interact with the world. However, just as in software engineering, a single monolithic entity can only scale so far before it becomes inefficient and difficult to maintain.

Today, we take the next logical step: moving from a single agent to a team of agents. You will learn how to design multi-agent workflows where specialized agents collaborate to solve complex problems. We'll explore two powerful orchestration patterns for task routing and delegation, which are central to building the kind of scalable AI systems you're aiming for. Understanding these patterns is not just about writing code; it's about making architectural decisions that have major implications for cost, reliability, and flexibility—key topics in any AI Engineer interview.

From Solo Agent to a Team of Specialists

A single agent trying to perform a complex, multi-step task like "research, write, and optimize an article" faces several challenges:

Context Overload: The system prompt becomes incredibly long and convoluted, trying to describe every possible task.
Tool Collision: An agent with dozens of tools might get confused about which one to use.
Mediocre Performance: A "generalist" agent is often a master of none, producing lower-quality results for each sub-task compared to a specialist.

The solution is to decompose the problem and assign parts to a team of specialized agents, much like a software team has frontend, backend, and database specialists. For our article-writing task, this might look like:

ResearchAgent: Expert at using web search tools.
WriterAgent: Expert at drafting content from research notes.
EditorAgent: Expert at refining tone and structure.
SEOAgent: Expert at keyword analysis and metadata generation.

The critical question then becomes: how do these agents coordinate? This coordination is called orchestration, and we will explore three common patterns for it.

This diagram shows three different patterns for coordinating agents: `@Delegate` (which we'll cover conceptually as agent-as-a-tool), `AgentGraph` for structured workflows, and `Supervisor` for dynamic workflows.

Let's dive into the two main architectural patterns: AgentGraph and Supervisor.

Pattern 1: AgentGraph — The Deterministic Pipeline

The most straightforward way to orchestrate agents is to define a fixed, predictable workflow. This is perfectly modeled by a Directed Acyclic Graph (DAG), a concept that should be familiar from your software engineering experience with data pipelines or build systems.

In this model, each agent is a node in the graph, and edges define the hand-off from one agent to the next. This creates a deterministic assembly line for processing a task. A great library for implementing this in a way that feels natural to a TypeScript/JavaScript developer is HazelJS.

Multi-Agent AI Orchestration in TypeScript: AgentGraph, Supervisors ...

This article provides an excellent, code-driven overview of multi-agent patterns in TypeScript. We will focus on the AgentGraph pattern first.

Please read the section titled "Pattern 1: AgentGraph". As you read, pay close attention to: The Code: Look at how the content-pipeline graph is built by adding nodes (.addNode) and connecting them (.addEdge). This is the declarative structure of the workflow. State Management: Understand the roles of inputMapper and outputMapper. These functions are critical for managing the GraphState that flows between agents, ensuring each agent gets the precise data it needs and its output is correctly integrated back into the shared "scratchpad". Control Flow: Note how addConditionalEdge allows for simple branching logic, and how a parallel node can be used to execute independent tasks concurrently, similar to Promise.all.

The AgentGraph pattern you just read about is a powerful architectural choice. A similar concept is implemented in Python's LangGraph library, which is widely used in the industry. To see this same DAG architecture in action again, you can review this video's explanation of a multi-source research agent.

How to Build an Advanced AI Agent with Search (LangGraph, Python, Bright Data & More)

This video by "Tech With Tim" builds a research agent using LangGraph in Python. While we are focusing on JS/TS, the architectural principles are identical.

Watch the segment from the architecture explanation. Notice how the diagram shows parallel searches (Google, Bing, Reddit) that then converge on subsequent analysis and synthesis steps. Then, skim through the code scaffolding from creating the graph to connecting nodes. Don't worry about the Python syntax; focus on how graph_builder.add_node() and graph_builder.add_edge() are used to translate the architectural diagram into a runnable workflow. This reinforces the universality of the DAG pattern for agent orchestration.

An AgentGraph is ideal for tasks where the sequence of operations is known and repeatable. It's predictable, efficient, and easier to debug. But what about tasks where the path forward is uncertain?

Pattern 2: Supervisor — The Dynamic Router

For open-ended problems, a fixed graph is too rigid. Instead, we can use a more flexible pattern where an LLM itself acts as the orchestrator. This "supervisor" agent doesn't perform the task; its sole purpose is to understand the overall goal and delegate sub-tasks to a team of "worker" agents.

At each step, the supervisor assesses the situation and decides which specialist is best suited for the next action. This creates an emergent workflow that is decided at runtime by the LLM's reasoning.

This is a real-world example of a supervisor architecture. A "Supervisor agent router & coordinator" receives a user query and decides which specialized agent (Plan advisor, Billing account, Technical support) should handle it.

Let's explore how this is implemented.

Multi-Agent AI Orchestration in TypeScript: AgentGraph, Supervisors ...

We'll return to the same article to understand the Supervisor pattern.

First, read the section "Pattern 2: SupervisorAgent". Focus on how it differs fundamentally from the graph: the workflow is not defined in code. Pay special attention to the "worker descriptions," as these are the primary tool the supervisor uses for routing. Next, briefly review "Pattern 3: @Delegate". This is another way to think about delegation, where one agent can call another as if it were a simple tool. This shows how tightly integrated agent-to-agent communication can become.

The LangGraph framework also provides a clean way to implement this pattern in JavaScript. The concepts are identical to what you just read.

@langchain/langgraph-supervisor - npm

This NPM package documentation provides a concise example of a supervisor in action.

Read the introduction and the Quickstart example. Note how it creates two specialist agents (mathAgent, researchAgent) and a supervisor to manage them. The supervisor's prompt explicitly tells it when to use each specialist, demonstrating the importance of clear instructions for effective routing.

Choosing the Right Pattern: A System Design Trade-off

As an AI Engineer, knowing how to build these systems is only half the battle. Knowing which pattern to choose for a given problem is what distinguishes a senior engineer. This is a classic architectural trade-off.

Multi-Agent AI Orchestration in TypeScript: AgentGraph, Supervisors ...

The final section of this article provides a direct comparison.

Read the section "Choosing the right pattern". This summary provides clear guidelines on when to use each pattern.

Let's consolidate those ideas, keeping your goal of acing system design interviews in mind.

Pattern	AgentGraph (Deterministic DAG)	Supervisor (Dynamic LLM-Router)
Control	You control the workflow in code.	The LLM controls the workflow at runtime.
Use When...	The process is predictable and repeatable (e.g., data processing, content generation).	The task is open-ended or the path is unknown (e.g., research, complex customer support).
Pros	- Predictable & Reliable: Always follows the same path. - Lower Cost/Latency: No extra LLM call for routing. - Easier to Debug: The flow is explicit.	- Flexible & Adaptive: Can handle unexpected inputs and devise novel plans. - More Powerful: Can solve more complex, less-structured problems.
Cons	- Inflexible: Cannot adapt to tasks outside its predefined flow.	- Less Predictable: Harder to debug when it makes a "wrong turn." - Higher Cost/Latency: Requires an LLM call at each step to decide the next route. - Risk of Loops: Can get stuck in cycles if not managed properly.

In a production system like the customer support agent described in the system design video from Manifold AI Learning, you would likely use a hybrid approach. A cheap, fast classifier model first routes a ticket to a specific AgentGraph (e.g., the "Billing Issue Graph"). If the issue is too complex for the graph, it could then be escalated to a powerful, generalist Supervisor agent for dynamic problem-solving.

Conclusion

You have now moved beyond single agents and into the world of multi-agent systems. You've seen that designing these systems is fundamentally about designing the communication and control flow between them.

Key Takeaways:

Decomposition is Key: Complex tasks are best solved by a team of specialized agents.
Orchestration Patterns: You have two primary tools for orchestration:
- AgentGraph (DAGs): For predictable, structured workflows where you define the path in code.
- Supervisor: For flexible, dynamic workflows where you empower an LLM to choose the path.
It's an Engineering Trade-off: The choice between these patterns is a decision based on the specific problem's requirements for predictability, flexibility, cost, and latency.

We've designed the high-level workflow, the "control plane" of our agent team. But for agents to collaborate effectively, they need a shared understanding of the task's state. In our next lesson, we will focus on the "data plane" by diving into state and memory management for long-running agent interactions.