Agent Orchestration Patterns: Sequential, Parallel and Hierarchical Workflows

When a task is too complex for a single agent, you need a way to coordinate multiple agents working together. The pattern you choose — sequential, parallel, or hierarchical — shapes your system’s speed, reliability, cost, and how easily you can debug it when things go sideways. Get this right at design time and you’ll save yourself a serious amount of rework later.

Here’s a look at the three foundational agent orchestration patterns, when to use each, and how to implement them with LangGraph and CrewAI.

What Is Agent Orchestration?

Orchestration is the coordination layer that answers: which agent runs, when, with what inputs, and what happens to its outputs. In a single-agent setup there’s no orchestration problem — the agent runs, finishes, done. Multi-agent systems introduce dependencies, parallelism, and state management that need deliberate design.

The three patterns below cover the vast majority of real-world use cases. Many production systems mix elements of all three.

Pattern 1: Sequential (Pipeline)

Structure: Agents run one after another. Each receives the output of the previous one as its input. The workflow is a directed chain: A → B → C → output.

Use this when each step genuinely depends on what came before, when you need a clear audit trail of transformations, or when the task naturally breaks into ordered stages — research → draft → review → publish, for instance. It’s simple to reason about and easy to debug. The catch: total latency is the sum of every individual step, and if step C consistently fails, you’re still burning time on A and B first.

LangGraph implementation:

from langgraph.graph import StateGraph, END

workflow = StateGraph(AgentState)

workflow.add_node("researcher", research_agent)
workflow.add_node("writer", writing_agent)
workflow.add_node("reviewer", review_agent)

workflow.set_entry_point("researcher")
workflow.add_edge("researcher", "writer")
workflow.add_edge("writer", "reviewer")
workflow.add_edge("reviewer", END)

graph = workflow.compile()
result = graph.invoke({"task": "Write a market analysis for EV batteries"})

The state object flows through each node, accumulating results. Each agent reads from and writes to shared state, so the data flow is explicit and easy to follow.

CrewAI implementation:

from crewai import Crew, Process

crew = Crew(
    agents=[researcher, writer, reviewer],
    tasks=[research_task, write_task, review_task],
    process=Process.sequential
)
result = crew.kickoff()

CrewAI’s Process.sequential handles the pipeline automatically, passing each task’s output to the next as context.

Pattern 2: Parallel (Fan-Out / Fan-In)

Structure: A coordinator agent dispatches multiple sub-tasks simultaneously. Independent agents work in parallel, and their results get aggregated by a consolidator once all (or enough) have finished.

Coordinator
├── Agent A (subtask 1)
├── Agent B (subtask 2)
└── Agent C (subtask 3)
       ↓ all results
  Consolidator → output

This is the pattern to reach for when sub-tasks are independent of each other, when speed matters, or when you’re processing multiple inputs of the same type — analysing ten documents simultaneously, say. It’s significantly faster than sequential for independent work. The downside is more complex state management: you need to handle partial failures, timeouts, and result aggregation. Debugging means correlating logs across concurrent runs, which takes a bit more effort.

LangGraph implementation (using async):

import asyncio
from langgraph.graph import StateGraph

async def parallel_research(state):
    tasks = [
        research_agent.ainvoke({"topic": t})
        for t in state["topics"]
    ]
    results = await asyncio.gather(*tasks, return_exceptions=True)
    valid_results = [r for r in results if not isinstance(r, Exception)]
    return {"research_results": valid_results}

workflow.add_node("parallel_research", parallel_research)
workflow.add_node("synthesiser", synthesis_agent)
workflow.add_edge("parallel_research", "synthesiser")

CrewAI implementation:

crew = Crew(
    agents=[agent_a, agent_b, agent_c],
    tasks=[task_a, task_b, task_c],
    process=Process.hierarchical,
    manager_llm=ChatOpenAI(model="gpt-4o")
)

Pattern 3: Hierarchical (Manager–Worker)

Structure: A manager agent decomposes a high-level goal into sub-tasks, assigns them to specialist workers, monitors progress, and synthesises the final result. Workers can themselves spawn further sub-agents, creating a tree structure.

        Manager Agent
       /       |       \
  Worker A  Worker B  Worker C
                |
           Sub-worker C1

This is the right pattern when the task is complex and its decomposition isn’t known upfront, when different sub-tasks need different specialist capabilities, or when you want dynamic routing — the manager decides at runtime which workers to engage. It’s the most flexible approach, but also the hardest to debug. Errors can occur at any level, and a manager that produces a poor decomposition compounds the problem through all its workers. The quality of your manager agent becomes a genuine bottleneck.

LangGraph implementation:

from langgraph.prebuilt import create_react_agent
from langgraph_supervisor import create_supervisor

supervisor = create_supervisor(
    agents={
        "researcher": research_agent,
        "analyst": analysis_agent,
        "writer": writing_agent,
    },
    model=claude_model,
    system_prompt="""You are a research director. Break the user's request into
    sub-tasks and assign them to the appropriate specialist agents."""
)

result = supervisor.invoke({"messages": [("user", task_description)]})

CrewAI implementation:

crew = Crew(
    agents=[manager, researcher, analyst, writer],
    tasks=[main_task],
    process=Process.hierarchical,
    manager_agent=manager
)

Choosing the Right Pattern

Here’s a useful rule of thumb: start sequential, parallelise when you measure a bottleneck, and add hierarchy only when the task decomposition genuinely can’t be determined upfront. Most teams reach for hierarchical too early and then spend weeks debugging manager reasoning failures that a well-designed sequential pipeline would have handled cleanly.

Combining Patterns

Production systems rarely fit neatly into one pattern. A common hybrid is a hierarchical manager that delegates to sequential sub-pipelines, with parallel execution within each pipeline stage. LangGraph’s graph abstraction handles this naturally — you can nest subgraphs implementing different patterns within a parent graph.

Whatever pattern you choose, the key principle is the same: make state transitions explicit, log every agent invocation with its inputs and outputs, and build your error-handling strategy before your first production deployment.