Agentic Planning for Complex Requests

Why Simple Agents Fail at Complex Tasks

Before we build a planner, we must understand why we need one. A simple ReAct agent, which operates in a Thought -> Act -> Observation loop, often struggles with complex requests like "Research the market for electric vertical take-off and landing (eVTOL) aircraft, identify the top 3 companies, and draft a competitive analysis."

Such a task overwhelms a simple agent for several reasons. To get a solid theoretical foundation for this problem, let's explore why task decomposition is not just a nice-to-have, but a necessity.

As the article highlights, by breaking a large problem into smaller, well-defined sub-goals, we make the task more manageable for the LLM. This allows us to:

• Fit within context window limits.
• Isolate points of failure for easier error handling and replanning.
• Map specific sub-tasks to the most appropriate tools.
• Create a more predictable and debuggable workflow.

This decomposition is the primary job of the planner.

The Orchestrator-Worker Pattern

One of the most intuitive ways to conceptualize a planning agent is the Orchestrator-Worker pattern (also called Plan-and-Execute). In this model:

1. The Orchestrator (Planner): An LLM that receives the user's high-level goal. Its sole responsibility is to think strategically and break that goal down into a structured plan of executable sub-tasks. It does not execute the tasks itself.
2. The Workers (Executors): These are the components that carry out the individual sub-tasks defined by the planner. A worker could be another LLM call, a tool (like a search engine or calculator), or a simple function.

This separation of concerns is powerful. The orchestrator can be a powerful, "smart" model (like GPT-4), while the workers can be cheaper, faster models or deterministic tools, optimizing for both cost and performance.

The key takeaway is that the planner's output is not a final answer, but a program for other parts of the system to run. This program can be a simple list, as seen in the video, or something far more complex.

From Simple Plans to Advanced Execution Graphs

Now that we have the conceptual model, let's explore how to implement and enhance it using LangGraph. We will look at three increasingly sophisticated planning architectures.

The video below demonstrates the implementation of these concepts. We will break it down into three stages.

1. The Basic Plan-and-Execute Agent

First, let's see how the basic pattern is implemented. The graph consists of a planner, an executor, and a conditional edge to decide if replanning is needed.

Action: Watch the "LangGraph: Planning Agents" video from 02:32 to 10:21.

This segment covers:

• The conceptual breakdown into a planner, executor, and optional replanner.
• The LangGraph implementation, showing how State holds the plan, how nodes execute or update the plan, and how conditional logic handles the flow.

Notice that the planner LLM is only invoked at the beginning and when replanning is necessary. The executor runs through the task list, which is more efficient than calling the main LLM after every single tool call.

2. ReWOO: Enabling Smarter Plans with Variable Substitution

The basic plan-and-execute model has a limitation: each step in the plan is independent. What if step 3 needs the output from step 1? The basic model would require a replanning phase.

The ReWOO (Reasoning WithOut Observations) architecture solves this by allowing the planner to create a plan with explicit dependencies.

Action: Watch the "LangGraph: Planning Agents" video from 10:21 to 16:59.

The key innovation here is variable substitution. The planner can generate a plan like:

1. E1 = Search("Super Bowl winner")
2. E2 = Search("Quarterback for team #E1")

The executor understands that #E1 is a placeholder for the output of the first step. This allows for creating more complex, multi-step tasks in a single plan, reducing the need for costly replanning loops. Your background in programming makes this concept of variable assignment and dependency straightforward.

3. LLMCompiler: High-Performance Execution with DAGs

ReWOO is powerful but still executes tasks sequentially. For a top-tier applied engineer, optimizing for latency is critical. The LLMCompiler architecture pushes this further by treating the plan not as a list, but as a Directed Acyclic Graph (DAG).

Action: Watch the "LangGraph: Planning Agents" video from 19:40 to 31:43.

This section is more advanced and speaks directly to system design and optimization:

• Streaming and Parallelism: The planner streams out tasks, and a "task fetching unit" immediately schedules them for execution. If two tasks (e.g., two different web searches) have no dependencies on each other, they can be run in parallel.
• DAG Representation: This formally models the dependencies between tasks, allowing an execution engine to optimize the path, similar to how build systems or query planners work. This connects directly to the theoretical concept of representing decomposed tasks as a DAG, which you saw mentioned in the "LLM Agent Task Decomposition Strategies" resource.

This architecture represents a significant step towards production-grade agentic systems where performance is a primary concern.

Conclusion

In this lesson, you have moved from simple reactive agents to sophisticated planning agents. You learned how to design workflows that decompose complex problems into manageable sub-goals, leading to more robust and efficient systems.

Key Takeaways:

• Decomposition is Essential: Complex tasks require breaking down into smaller steps to manage reasoning complexity, context limits, and error handling.
• The Plan-and-Execute Pattern: Separating a "planner" (strategist) from an "executor" (worker) is a powerful design pattern for building agents. The planner's output is effectively a program for the executor to run.
• Planning is an Evolving Field: You traced the evolution of planning architectures from simple lists to plans with variable substitution (ReWOO) and finally to parallel-executable Directed Acyclic Graphs (LLMCompiler).
• LangGraph for Orchestration: You saw how LangGraph provides the tools (nodes, state, conditional edges) to implement these complex planning and execution flows.

What's Next?

You can now design agents that remember conversations and intelligently plan their actions. As these systems grow, with multiple planners, workers, and tools interacting, a new challenge emerges: standardization. How do you ensure all these different components can communicate effectively without custom, brittle integrations for each one?

In the next lesson, we will explore this very problem by learning about the Model Context Protocol (MCP), an emerging standard for structuring communication between agents and tools to create more interoperable and scalable AI systems.