Skip to main content
Back to path

Welcome to a Grasp lesson

Create a free account to keep studying and create your own study path.

Lesson 82

Building Multi-Step Agents with Orchestration Frameworks

Recommended resources

Introduction

In our last lesson, you learned how to implement the backend logic for a single custom tool, enabling an LLM to perform a specific, isolated action. We saw the basic loop: the LLM suggests a tool, your application executes it, and the result is fed back to the model.

However, most meaningful tasks are not single-shot operations. Consider a request like, "Research the key differences between LLaMA 3 and Mistral Large, then draft a tweet summarizing the findings." This requires multiple steps: several web searches, information synthesis, and finally, text generation. A simple loop is insufficient for managing such complex control flow. This is where orchestration frameworks come in.

Today, we will build on your knowledge of tools to tackle this lesson's learning outcome: Build a multi-step agent that uses multiple tools to accomplish a complex goal using an orchestration framework (e.g., LangGraph, AutoGen). We will focus on LangGraph, a library that extends LangChain and allows you to build robust, stateful agents as graphs. You will learn to construct not just single agents that can loop, but entire multi-agent systems where a "supervisor" agent delegates tasks to specialized "worker" agents to achieve a complex goal.

From Simple Loops to State-Driven Graphs

A basic agent can be built with a while loop, but this approach quickly becomes brittle. As logic gets more complex—with branching, retries, and multiple tools—the code becomes difficult to manage, debug, and maintain. Orchestration frameworks provide a more structured and robust solution.

LangGraph models agentic workflows as state graphs:

  • State: A central object (typically a dictionary or Pydantic model) that holds all the information for the graph's execution, such as the conversation history, tool outputs, and intermediate results. Each node in the graph can read from and write to this state.
  • Nodes: Python functions that represent a unit of work. A node could be a call to an LLM, the execution of a tool, or any other piece of logic. Nodes receive the current state and return an update to it.
  • Edges: Define the path of execution, connecting the nodes. Edges can be conditional, allowing you to create complex control flows like loops and branches based on the contents of the state.

This graph-based approach makes complex agent behavior explicit and easier to reason about. Let's start with a foundational video from the LangChain team.

Building Effective Agents with LangGraph

First, let's understand why a framework like LangGraph is necessary and the core concepts behind it. This video introduces the distinction between a 'workflow' and an 'agent' and explains the key benefits LangGraph provides.

Watch the first 3 minutes and 24 seconds (00:00 - 03:24). Pay attention to the distinction between a 'workflow' (predefined scaffolding) and an 'agent' (unbounded decision-making), and the three key infrastructure benefits LangGraph provides: persistence, streaming, and deployment.

Implementing a Basic Multi-Tool Agent

Before building a complex multi-agent system, let's see how LangGraph represents a single agent that can choose from multiple tools and loop until its task is complete. This is the classic ReAct (Reason, Act) pattern.

The graph for this agent is remarkably simple:

  1. Agent Node: Calls the LLM with the current conversation history and available tools. The LLM's response (either a final answer or a tool call request) is added to the state.
  2. Conditional Edge: Inspects the LLM's last message.
    • If it contains a tool call, the edge directs the flow to the Tool Node.
    • If it's a final answer, the edge directs the flow to END.
  3. Tool Node: If reached, this node inspects the tool call request, executes the corresponding tool function (which you learned to build in the last lesson), and adds the output to the state as a ToolMessage. From here, the flow unconditionally loops back to the Agent Node for the next reasoning step.

The following video segment demonstrates how to build this exact structure.

Building Effective Agents with LangGraph

Now, let's see how to implement a basic agent that can use multiple tools within a loop. This video walks through creating an arithmetic agent with add, multiply, and divide tools.

Watch from 23:25 to 27:40. Focus on the three main components: The 'llm_call' node (our Agent Node). The 'tool_node' that executes the chosen tool. The 'should_continue' conditional edge that creates the loop. Notice how this simple graph structure enables the agent to chain multiple tool calls to solve a problem like (3+4)*4.

This graph is the fundamental building block for most agentic systems. It's a robust, stateful replacement for a simple while loop.

The Supervisor-Worker Pattern: Orchestrating a Team of Agents

While a single agent is powerful, it can struggle with complex, multi-stage tasks. A single system prompt trying to make the LLM an expert at research, coding, and creative writing often results in mediocre performance across the board.

A more effective and scalable architecture is the supervisor-worker pattern. Here, you create a "team" of specialized agents, orchestrated by a "supervisor" agent.

  • Supervisor Agent: A high-level planner. Its main job is to understand the user's overall goal, break it down into sub-tasks, and delegate each sub-task to the appropriate worker. It has a special tool, often called handoff, to perform this delegation.
  • Worker Agents: Specialized agents, each with its own prompt, tools, and expertise. For example, you might have a ResearchAgent with web search and document reading tools, and a ContentAgent with tools for writing tweets or blog posts.

This modular design is highly effective for several reasons:

  • Improved Performance: Each worker agent has a focused prompt and a smaller, more relevant set of tools, reducing confusion and improving its ability to perform its specific task.
  • Scalability: You can easily add, remove, or update worker agents without affecting the rest of the system.
  • Efficiency: Worker agents can potentially run in parallel on different sub-tasks.

This architecture is a common pattern for building production-grade agentic systems.

LangChain Multi-Agent Workflow
This flowchart illustrates a multi-agent architecture. A 'Planner Agent' (our Supervisor) decomposes a task and orchestrates specialized agents (like a 'RAG Agent' for research) that use specific tools to accomplish sub-goals. LangGraph manages this entire control flow.

The following video provides an excellent end-to-end demonstration and conceptual overview of this pattern.

How to Build Multi AI Agents with Langgraph

Truly complex tasks benefit from a team of specialized agents. The 'supervisor' pattern is a production-ready architecture for this. This video by Kenny Liao provides a fantastic deep dive into building such a system with LangGraph.

Please watch the following segments: Introduction & Demo (00:00 - 13:02): Watch the introduction and the full demo. Observe how the Supervisor agent first delegates to the Researcher (multiple times, refining the request) and then hands off the compiled research to the Copywriter. This shows the multi-step, multi-tool process in action. Conceptual Trade-offs (13:02 - 17:50): This section is crucial for your 'deep mastery' goal. It explains when to choose a multi-agent system over a simpler workflow or a single agent. Pay close attention to the reasons: efficiency, context management, token usage scalability, and modularity.

Implementation Deep Dive: How Orchestration Works in LangGraph

You saw the supervisor delegate tasks, but how does this work under the hood? The key lies in treating each worker agent's graph as a subgraph and using a special routing mechanism.

In the supervisor's graph, the flow is:

  1. The Supervisor LLM is called. It decides to delegate a task to a worker (e.g., the ResearchAgent).
  2. It calls its special handoff tool with the agent_name ("ResearchAgent") and the task_description.
  3. The backend logic for the handoff tool doesn't just return a string. Instead, it returns a special command object to LangGraph, using the go_to argument to specify the name of the next node to execute (e.g., go_to="call_researcher").
  4. The call_researcher node is not an LLM call; it's a node that invokes the entire compiled graph of the ResearchAgent. It passes the task_description as the initial input to that subgraph.
  5. The ResearchAgent's graph runs independently until it finishes.
  6. The final output from the ResearchAgent subgraph is then returned to the supervisor's graph, which adds it to its own state and loops back to the Supervisor LLM for the next planning step.

This explicit routing via go_to and the invocation of subgraphs is the core mechanism for orchestrating multiple agents in LangGraph.

How to Build Multi AI Agents with Langgraph

Let's examine the critical code that makes this orchestration possible. We'll revisit the same video to understand the implementation of the supervisor and its 'handoff' mechanism.

Watch the segment on the Supervisor's implementation (37:22 - 45:10). Focus on these key points: The handoff tool: Notice how it takes an agent_name and task_description. The command primitive with go_to: The tool returns a command object. This is how the supervisor explicitly tells LangGraph which node (which worker's subgraph) to execute next. Calling subgraphs: See how the call_researcher and call_copywriter nodes invoke the compiled graphs of the worker agents, passing in only the necessary context. This is how context is isolated between agents.

Test your understanding!

Imagine you need to build an agentic system for a financial analyst. The goal is to take a company's stock ticker (e.g., NVDA) and produce a short investment summary. The required steps are:

  1. Fetch the latest stock price.
  2. Search for recent news articles about the company.
  3. Analyze the sentiment of the news headlines (positive, negative, neutral).
  4. Synthesize the stock price, news, and sentiment into a 2-3 sentence summary.

Based on the supervisor-worker pattern, how would you design this system? Specifically:

  1. What agents would you create, and what would be the role of each?
  2. What specific tools would you assign to each worker agent?
Show answer

A good design would be:

  1. Agents and Roles:

    • SupervisorAgent: The main orchestrator. Its role is to take the user's request (e.g., "Analyze NVDA"), create a plan (fetch price, find news, analyze sentiment, summarize), and delegate each step to the appropriate worker.
    • FinanceAgent (Worker): A specialist for financial data. Its role is to handle quantitative information.
    • NewsAgent (Worker): A specialist for qualitative information and analysis.
    • SummaryAgent (Worker): A specialist for synthesizing information and generating the final report.

  2. Tools per Agent:

    • SupervisorAgent: Would have one tool: handoff(agent_name: str, task: str).
    • FinanceAgent: Would have one tool: get_stock_price(ticker: str) -> float.
    • NewsAgent: Would have two tools: search_news(company_name: str) -> list[article] and analyze_sentiment(headlines: list[str]) -> str.
    • SummaryAgent: Would likely have no external tools. Its "tool" is its own LLM prompt, which is designed to take structured data (price, news, sentiment) and generate a coherent summary.

This separation of concerns makes the system more robust. The FinanceAgent only needs to know about financial APIs, and the NewsAgent only needs to know about news APIs and sentiment analysis, preventing prompt contamination and making the system easier to debug and extend.

Conclusion

Today you have made a significant leap from single tool calls to orchestrating complex, multi-step, multi-agent workflows. You've seen that for any non-trivial agentic task, a dedicated orchestration framework like LangGraph is not just a convenience but a necessity for building robust and maintainable systems.

Key Takeaways:

  • Orchestration is Key: Frameworks like LangGraph provide the necessary structure (state, nodes, edges) to manage complex agentic control flow, far surpassing simple while loops.
  • Graphs Model Agent Behavior: Representing agents as state graphs makes their logic explicit, stateful, and easier to debug.
  • The Supervisor Pattern is Scalable: For complex goals, a team of specialized worker agents orchestrated by a supervisor is a powerful and production-ready architecture. It improves performance and modularity.
  • Orchestration is Implemented via Subgraphs and Routing: In LangGraph, delegation is achieved by having the supervisor's tool use a go_to command to route control to a specific node that invokes another agent's entire graph (a subgraph).

What's Next?

We've built a system where agents can collaborate, but our focus has been on the control flow of a single, complex request. In the next lesson, "Implement short-term conversational memory to maintain context within an agentic session," we'll focus on making these agents stateful across multiple turns of a conversation. You'll see how frameworks like LangGraph, with their built-in persistence mechanisms, make it straightforward to give your agents a memory of their past interactions with a user.