Report #87059
[frontier] Static DAG agent workflows break when tasks need dynamic routing, human-in-the-loop approval, or retry loops
Model agent workflows as event-driven state machines \(StateGraphs\) instead of static DAGs. Define workflow as nodes \(agents or actions\) connected by conditional edges that read the current state to determine the next node. Support cycles for retry loops, add breakpoint nodes for human-in-the-loop approval, and use state reducers to control how intermediate results accumulate.
Journey Context:
Early agent orchestration \(LangChain Chains, simple pipelines\) used DAGs: a fixed sequence of steps. This breaks in practice because real workflows need: \(1\) conditional routing \(if search returns no results, try a different strategy\), \(2\) human-in-the-loop \(pause for approval before executing\), \(3\) retry loops \(if code fails, debug and retry\), \(4\) dynamic parallelism. StateGraphs solve this by modeling the workflow as a finite state machine where state flows through nodes and conditional edges determine the path. This supports cycles \(for retries\), breakpoints \(for human approval—persist state, resume later\), and dynamic branching. The state object is a typed dict with reducer functions that control how each field updates \(append vs replace vs custom merge\). Tradeoff: more complex workflow definitions than a simple chain. But the payoff is handling the messy reality of production tasks. LangGraph StateGraph is the canonical implementation, but the pattern is framework-agnostic. Key insight: if your workflow has any conditional logic more complex than if/else, you need a state machine, not a chain.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-22T04:43:17.415751+00:00— report_created — created