# LangGraph vs AutoGen vs CrewAI vs OpenAI Agents SDK: Architecture and Implementation Guide

> Compare LangGraph, AutoGen, CrewAI, and OpenAI Agents SDK architectures. Discover deterministic graphs, dynamic conversations, role-based collaboration, and tight OpenAI integration for efficient agent development.

- Repository: [Rohit Ghumare/ai-engineering-from-scratch](https://github.com/rohitg00/ai-engineering-from-scratch)
- Tags: architecture
- Published: 2026-06-18

---

**LangGraph provides deterministic graph execution with durable checkpointing, AutoGen enables dynamic conversational multi-agent patterns, CrewAI offers ergonomic role-based collaboration with built-in validation, and OpenAI Agents SDK delivers tight OpenAI integration with minimal boilerplate for ReAct-style loops.**

Selecting the right agent framework determines whether your multi-agent system achieves production-grade reliability or remains stuck in prototyping. According to the `rohitg00/ai-engineering-from-scratch` curriculum, each framework optimizes for different trade-offs between **determinism**, **flexibility**, and **integration depth**. This guide compares the architectural primitives, memory models, and orchestration patterns of these four major frameworks to help you align technical choices with your specific use case.

## Architectural Overview

The fundamental design of each framework reflects distinct assumptions about how agents should coordinate. According to the primitive model analysis in [`phases/16-multi-agent-and-swarms/04-primitive-model/docs/en.md`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/16-multi-agent-and-swarms/04-primitive-model/docs/en.md), these frameworks differ across four core dimensions: state management, checkpointing durability, and runtime topology.

| Framework | Core Primitives | Orchestration Model | Shared State / Memory | Typical Runtime |
|-----------|----------------|---------------------|----------------------|----------------|
| **LangGraph** | *Node function, Edge condition, `StateGraph` reducer, Checkpointer* | Deterministic directed-graph (static) or Swarm architecture (dynamic) – each node is a pure Python callable that returns a state; the runtime persists a checkpoint after every super-step. | Centralised checkpoint (PostgreSQL by default) → durable, replayable, audit-friendly. | LangGraph runtime (Python) |
| **AutoGen** | *Agent pool, GroupChat manager, Tool registry* | Hierarchical "GroupChat" where a manager LLM decides which sub-agent speaks next; also supports a pool-based "Swarm" where any agent may pick up work from a shared queue. | Implicit pool-level state; each agent can read/write a shared dictionary but there is no built-in durable checkpoint. | Python library (lightweight) – runs in-process |
| **CrewAI** | *Agent, Task, Crew, Process* | Two top-level shapes: **Crew** – autonomous role-based collaboration (agents act as specialists); **Flow** – deterministic event-driven workflow (each task executes sequentially). | Optional memory types (short-term, long-term, entity, contextual) backed by embeddings; can be turned on per-Crew. | Python (or TypeScript) SDK |
| **OpenAI Agents SDK** | *Agent, Tool, Model router* | Classic ReAct-style loop – the agent calls tools via function calling, receives structured output, and continues. | No native checkpoint; state must be persisted by the user (e.g. via a DB). | Python SDK wrapping the OpenAI Assistants API |

**LangGraph** emphasizes **full control over graph topology** with fine-grained memory reducers, making it ideal when audit trails and reproducibility are required. **AutoGen** prioritizes conversational flexibility, allowing an LLM to dynamically select the next speaker rather than following a predefined graph. **CrewAI** provides a high-level abstraction where you define **roles** (e.g., Product Manager, Architect) rather than graph nodes, with built-in Pydantic validation for task outputs. **OpenAI Agents SDK** remains the thinnest wrapper, offering straightforward tool-calling semantics for teams already committed to OpenAI's model ecosystem.

## When to Choose Which Framework

The decision matrix in [`phases/16-multi-agent-and-swarms/25-case-studies-2026-sota/docs/en.md`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/16-multi-agent-and-swarms/25-case-studies-2026-sota/docs/en.md) provides concrete guidance for framework selection based on production constraints.

- **Deterministic pipelines with audit & replay** → **LangGraph**. Checkpointing after each graph transition guarantees that crashes can resume without loss; explicit graph topology makes debugging deterministic.
- **Rapid prototyping of conversational multi-agent chats** → **AutoGen**. The `GroupChat` manager lets an LLM dynamically pick the next speaker, removing the need to manually code a graph.
- **Role-based teams (e.g., "product → architect → engineer → reviewer")** → **CrewAI**. The *Crew* abstraction maps directly to specialized role agents; built-in memory types and task validation reduce hallucinations.
- **Already using OpenAI Assistants and need simple tool calling** → **OpenAI Agents SDK**. The SDK leverages function-calling under the hood, providing tool integration with minimal boilerplate.
- **Large-scale swarm where many agents pick up independent work** → **LangGraph (Swarm Architecture)** or **AutoGen pool**. Both support decentralized work queues; LangGraph adds deterministic checkpoints, while AutoGen offers lighter-weight pool semantics.
- **Need durable execution with checkpoint-driven resumes in production** → **LangGraph runtime** or **CrewAI Flow**. LangGraph’s runtime writes checkpoints to Postgres; CrewAI Flow provides a deterministic DAG that can be persisted with external tooling.

## Implementation Examples

Below are production-ready patterns extracted from the rohitg00/ai-engineering-from-scratch repository, demonstrating how each framework handles equivalent multi-agent workflows.

### LangGraph: Deterministic Graph with Checkpointing

In [`phases/16-multi-agent-and-swarms/04-primitive-model/docs/en.md`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/16-multi-agent-and-swarms/04-primitive-model/docs/en.md), LangGraph is implemented as a `StateGraph` where each node is a pure function that returns state updates. The runtime automatically checkpoints after every super-step.

```python
from langgraph.graph import StateGraph

def retrieve(state):
    # retrieve vector hits → add to state["retrieved"]

    return {"retrieved": hits}

def rerank(state):
    # cross‑encoder on top‑k → keep best

    return {"reranked": top_k}

def synth(state):
    # call Claude Sonnet, inject citations

    return {"answer": response}

workflow = StateGraph()
workflow.add_node("retrieve", retrieve)
workflow.add_node("rerank",   rerank)
workflow.add_node("synth",   synth)

workflow.set_entry_point("retrieve")
workflow.add_edge("retrieve", "rerank")
workflow.add_edge("rerank",   "synth")
workflow.add_edge("synth",    "__end__")

```

The `StateGraph` reducer handles state updates immutably, and the checkpointer (configured separately) persists to PostgreSQL, enabling **durable execution** and **time-travel debugging**.

### AutoGen: Hierarchical GroupChat

As documented in [`phases/16-multi-agent-and-swarms/05-supervisor-orchestrator-pattern/docs/en.md`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/16-multi-agent-and-swarms/05-supervisor-orchestrator-pattern/docs/en.md), AutoGen uses a manager LLM to coordinate speaker selection dynamically.

```python
from autogen import GroupChat, AssistantAgent

manager = AssistantAgent(name="manager")
agents = [
    AssistantAgent(name="researcher"),
    AssistantAgent(name="coder"),
    AssistantAgent(name="reviewer")
]

chat = GroupChat(
    manager=manager,
    agents=agents,
    max_rounds=5,
    selector="llm"  # LLM decides who speaks next

)
chat.run("Create a CLI tool that parses CSV files.")

```

This pattern excels when the conversation flow is **emergent** rather than predetermined, though it sacrifices the reproducibility guarantees of static graphs.

### CrewAI: Role-Based Sequential Crew

The CrewAI primer in [`phases/14-agent-engineering/15-crewai-role-based-crews/docs/en.md`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/14-agent-engineering/15-crewai-role-based-crews/docs/en.md) demonstrates how to structure agents by role rather than by graph topology.

```python
from crewai import Agent, Task, Crew

# Define agents

pm     = Agent(role="Product Manager", goal="Define specs", backstory="...")
architect = Agent(role="Architect", goal="Design system", backstory="...")
engineer = Agent(role="Engineer", goal="Implement code", backstory="...")
reviewer  = Agent(role="Reviewer", goal="Check quality", backstory="...")

# Define tasks

task_spec = Task(
    description="Write product specs",
    agent=pm,
    expected_output="Spec document"
)
task_design = Task(
    description="Create architecture diagram",
    agent=architect,
    expected_output="Diagram"
)

# Build the crew (sequential)

crew = Crew(
    agents=[pm, architect, engineer, reviewer],
    tasks=[task_spec, task_design, ...],
    process="sequential"
)

crew.kickoff()

```

CrewAI validates outputs against Pydantic models and supports optional memory layers (short-term, long-term, entity) backed by embeddings, reducing the need for external vector stores.

### OpenAI Agents SDK: ReAct Tool Calling

The code migration capstone in [`phases/19-capstone-projects/09-code-migration-agent/docs/en.md`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/19-capstone-projects/09-code-migration-agent/docs/en.md) implements the OpenAI Agents SDK as a lightweight ReAct loop.

```python
from openai import OpenAI
client = OpenAI()

def run_tool(name, args):
    if name == "read_file":
        with open(args["path"]) as f:
            return f.read()
    # other tools …

def agent_loop():
    messages = [{"role": "system", "content": "You are a coding assistant"}]
    while True:
        response = client.chat.completions.create(
            model="gpt-4o",
            messages=messages,
            tools=[{"type":"function", "function":{...}}]  # tool schema

        )
        choice = response.choices[0]
        if choice.finish_reason == "function_call":
            tool_name = choice.message.tool_calls[0].function.name
            args = json.loads(choice.message.tool_calls[0].function.arguments)
            tool_output = run_tool(tool_name, args)
            messages.append({"role":"assistant","content":choice.message.content})
            messages.append({"role":"tool","content":tool_output,"name":tool_name})
        else:
            print("Final answer:", choice.message.content)
            break

```

This implementation requires manual state management—checkpoints must be persisted to an external database—but provides the lowest latency path to production for OpenAI-centric workflows.

## Summary

- **LangGraph** delivers deterministic execution with built-in PostgreSQL checkpointing, making it the strongest choice for production pipelines requiring auditability and crash recovery.
- **AutoGen** provides the most flexible conversational patterns through its `GroupChat` manager, ideal for exploratory multi-agent systems where the LLM should decide the flow.
- **CrewAI** offers the most ergonomic API for role-based collaboration, with built-in validation and optional memory types that reduce hallucinations in specialized teams.
- **OpenAI Agents SDK** minimizes boilerplate for teams already using OpenAI models, though it requires custom infrastructure for state persistence and checkpointing.

## Frequently Asked Questions

### Which framework is best for production applications requiring audit trails?

**LangGraph** is explicitly designed for this use case. Its checkpointer persists state to PostgreSQL after every super-step, creating a durable, replayable execution log that satisfies compliance requirements. As implemented in [`phases/16-multi-agent-and-swarms/04-primitive-model/docs/en.md`](https://github.com/rohitg00/ai-engineering-from-scratch/blob/main/phases/16-multi-agent-and-swarms/04-primitive-model/docs/en.md), this checkpointing is native to the runtime, requiring no additional infrastructure.

### How do I handle memory and state persistence across these frameworks?

**LangGraph** uses centralized checkpoints; **CrewAI** offers configurable memory types (short-term, long-term, entity) backed by embeddings; **AutoGen** relies on an implicit shared dictionary with no built-in durability; and **OpenAI Agents SDK** requires you to implement custom persistence (e.g., writing to a database after each tool call). Choose based on whether you need **automatic durability** (LangGraph) or **flexible, optional memory** (CrewAI).

### Can I mix these frameworks or migrate between them?

Yes, though it requires architectural adaptation. The `rohitg00/ai-engineering-from-scratch` repository demonstrates hybrid patterns where **OpenAI Agents SDK** handles tool-calling while **LangGraph** manages the orchestration layer. Migration typically involves translating conversation flows (AutoGen) into static graphs (LangGraph) or role definitions (CrewAI) into explicit nodes.

### Which framework requires the least boilerplate for simple tool-calling agents?

**OpenAI Agents SDK** requires the least setup for simple ReAct loops, as it leverages OpenAI's native function-calling API with minimal abstraction. However, for applications requiring multi-agent coordination, **CrewAI** often results in less boilerplate than manually implementing graph edges in LangGraph or conversation managers in AutoGen, thanks to its high-level `Agent` and `Task` primitives.