When we have DAG that represents our tasks and its dependencies do we still need Langraph nodes?
LangGraph nodes are most valuable when your flow has cycles — loops, retries, HITL resume, conditional branching back to earlier steps. A pure DAG has none of that, so LangGraph's core value proposition doesn't apply.
So are they mutually exclusive? No! They can complement each other. See the beautiful project to understand why.
LangGraph nodes for the orchestration layer: intent_parser → entity_extractor → plan_builder → hitl_plan → cot_builder → hitl_confirm. This is the stateful, cyclic part.
Your own DAG executor for task execution: takes the confirmed TaskGraph, runs a topological sort, fans out independent tasks with asyncio, collects results. Twenty to thirty lines of plain Python. No framework.
| Send API for parallel dispatch | LangGraph-native fan-out; no manual thread/asyncio management; results merged automatically |
The DAG (networkx) and LangGraph Send API solve different problems and are complementary — not alternatives. See the 'Why both networkx DAG and LangGraph Send API?' section added to the Overview. Short answer: networkx tells us WHAT to run (which steps are ready, via topological ordering and predecessor checks); LangGraph Send API handles HOW to run them concurrently (fan-out to parallel node invocations, automatic state merge on fan-in). You could replace Send with asyncio.gather inside a single node, but you'd lose per-step checkpointing (partial progress survives failures), automatic state merging, and consistency with the rest of the LangGraph pipeline.
Your mental model was almost right — let me clarify the full split:\n\n| Concern | Tool | Why |\n|---|---|---|\n| Dependency graph structure | networkx DAG | Planner builds it, CoT validator walks it, executor queries it for readiness |\n| Parallel task execution | LangGraph Send API | Fan-out ready steps as concurrent node invocations; LangGraph auto-merges results |\n| HITL + session resume | LangGraph interrupt() + PostgresSaver | Only LangGraph provides checkpointed pause/resume semantics |\n\nThe DAG is used across all pipeline stages — not just the executor — as a data structure for graph operations (cycle detection, topological sort, predecessor queries). LangGraph is the execution engine throughout. The executor uses both: DAG to decide which steps are ready, Send API to run them in parallel. Added a dedicated section in the executor design doc explaining this.
The DAG (networkx) is a data structure for representing and querying step dependencies — it lives in dag.py and is used by three different pipeline stages (planner for cycle detection, CoT validator for topological walk, executor for readiness checks). LangGraph graph nodes (validate_cot, execute_step, etc.) are the execution units in the agent runtime. They use the DAG as a utility library. There's no conflict — the DAG tells the LangGraph nodes what order/parallelism is required; LangGraph handles actually running them, checkpointing state, and managing HITL interrupts.
Top comments (0)