Sequential Pattern: Agents in a Pipeline

~10 min read

Each agent adds value step by step — one generates, the next reviews, a third deploys — the straightforward pipeline pattern used in workflow automation, ETL chains, and multi-step reasoning.

The Sequential pattern is the most intuitive of the 7 multi-agent orchestration patterns: each agent adds value step by step, in a fixed order, where one agent's output becomes the next agent's input. This course's own example is concrete: one agent generates code, another reviews it, and a third deploys it — each stage builds directly on the previous one's completed work, rather than all three working on the task simultaneously.

This is the multi-agent equivalent of a well-designed software pipeline or assembly line: each agent has a narrow, well-defined responsibility, and the overall system's behavior emerges from the specific sequence of transformations each agent applies. You'll see this pattern in workflow automation (a document goes through extraction, then validation, then formatting stages), ETL chains (extract, transform, load — each naturally a distinct stage), and multi-step reasoning pipelines where a complex task genuinely decomposes into ordered, dependent phases.

The pattern's core strength is exactly its simplicity: it's easy to reason about (you can trace a single, linear path from input to output), easy to debug (a failure is isolated to whichever stage produced bad output), and each agent can be specialized narrowly for its one job, often performing better at that narrow task than a single generalist agent trying to do everything.

Its main limitation is exactly the flip side of that simplicity: because each stage depends on the previous one completing first, the total latency is the SUM of every stage's individual latency — there's no parallelism to exploit, even when some stages could theoretically run independently. Sequential is the right choice specifically when stages genuinely have a hard dependency on each other's output (you can't review code that hasn't been generated yet); when stages are actually independent, the Parallel pattern (the next subtopic) is the better fit.

💻 Code example

from openai import OpenAI

client = OpenAI()

def generate_code_agent(task: str) -> str:
    resp = client.chat.completions.create(model="gpt-4.1", messages=[
        {"role": "user", "content": f"Write Python code for: {task}"}
    ])
    return resp.choices[0].message.content

def review_code_agent(code: str) -> str:
    resp = client.chat.completions.create(model="gpt-4.1", messages=[
        {"role": "user", "content": f"Review this code for bugs and style issues:\n{code}"}
    ])
    return resp.choices[0].message.content

def finalize_agent(code: str, review: str) -> str:
    resp = client.chat.completions.create(model="gpt-4.1", messages=[
        {"role": "user", "content": f"Apply this review's feedback to the code:\n{code}\n\nReview:\n{review}"}
    ])
    return resp.choices[0].message.content

def sequential_pipeline(task: str) -> str:
    # Each stage strictly needs the previous stage's output — a hard
    # dependency chain, run in fixed order, no parallelism possible
    code = generate_code_agent(task)
    review = review_code_agent(code)
    return finalize_agent(code, review)

print(sequential_pipeline("a function that reverses a linked list"))

💬 Deep Dive with AI

Key points

  • Each agent adds value step by step, in fixed order — one agent's output feeds directly into the next
  • The book's example: generate code -> review it -> deploy it, each stage building on the previous one
  • Used in workflow automation, ETL chains, and multi-step reasoning pipelines with genuine stage dependencies
  • Easy to reason about and debug, since there's a single linear path from input to output
  • Main limitation: total latency is the SUM of every stage's latency — no parallelism, even where some stages could theoretically run independently