DAG Workflow

A plain pipeline is a straight line: one stage feeds the next, in order. That's fine as long as every step genuinely depends on the one before it. Often it doesn't: fetching test results and fetching lint results don't depend on each other, but a later “deploy” step depends on both finishing. A DAG (directed acyclic graph) workflow is the way to represent that — steps as nodes, dependencies as directed edges, with branches that split off and later merge back into a single path before the workflow continues.

The “acyclic” part matters as much as the branching: a DAG has no loops. Once an edge points from step A to step B, nothing ever points back from B to A. That's a deliberate constraint — it guarantees the graph has a well-defined starting point and finishing point, and that execution can't get stuck circling. Anything that genuinely needs to loop or revisit earlier states is a different pattern (see state-machine-agent), not a DAG.

This shape is common in build systems and orchestration tools for exactly this reason — it lets independent work run in parallel, which a strictly linear pipeline can't express, while keeping a guarantee that the whole thing terminates.

How it works

Execution typically starts at nodes with no unmet dependencies (the graph's roots) and runs them, often in parallel if the workflow engine supports it. A node with multiple incoming edges — a merge point — only runs once all of its dependencies have completed, at which point the graph continues past it as a single path again.

Example

A CI-style agent workflow: start → run linter (branch A) and run tests (branch B) in parallel → once both finish, merge → deploy. Deploy only starts once both the lint and test branches have completed, whichever finished last.

How it differs

Common misconceptions

FAQ