2026-08-13
How to design conditional branches in agent loops without creating spaghetti
Branches accumulate quietly until a loop's control flow resembles a plate of spaghetti. Seven patterns — centralized routing, flat conditions, converging branches, mandatory defaults, logging, pruning, and splitting — keep branching legible.
← Back to BlogEvery agent loop starts clean: one path, a handful of nodes, predictable behavior. Then reality arrives. Some items need a second model call, premium accounts skip the queue, malformed input must be quarantined, and half-finished batches need a resume path. Each fix adds a branch, and branches have a habit of accumulating until the control flow resembles a plate of spaghetti — legible only to whoever wrote it, and often not even to them. After building dozens of production loops in LoopCraft, we keep coming back to seven patterns that prevent this. Pattern 1: centralize routing. A loop should make its routing decisions in one place, typically a single Condition node near the top of the iteration body, with one well-named loop variable per decision. When conditions live inside five different nodes, nobody can answer the simplest question: under what circumstances does this loop take path B? Pattern 2: keep conditions flat. A branch condition should be readable at a glance: score below 0.6, retry count above 3, status equals needs_review. If your condition needs parentheses inside parentheses, compute the answer in an upstream node, store it in a well-named boolean such as needs_review, and branch on that. Complexity belongs in data preparation, never in the routing decision itself. Pattern 3: every branch must converge. Each path either exits the loop with a result or rejoins the main flow at a named merge point. Never let a branch spawn its own branches indefinitely. If you need more than two levels of routing, extract the deeper logic into a sub-loop with a single responsibility, so the parent loop stays readable at a glance. Pattern 4: always have a default. Model outputs are unpredictable by design, and a condition that covers 99 percent of cases will reliably meet the remaining 1 percent in production. Every branch point needs an else that does something explicit — quarantine the item, flag it for review, or hand it to a human — because a missing default is a silent failure waiting to happen. Pattern 5: treat branches like hypotheses. Log every evaluation — the values it saw and the path it took — and review those logs weekly. A route that never fires for a month is dead weight; remove it. Dead branches are a leading source of spaghetti, because nobody dares to delete them and everyone builds around them. Pattern 6: split when branches exceed five. If one loop accumulates five or six branches, it is doing several jobs. Split it into a router that fans out to focused sub-loops, each carrying at most two or three branches. The router stays trivially understandable, and each sub-loop can evolve independently. Pattern 7: make it visible. In LoopCraft, this whole recipe maps directly onto the builder: one Condition node acting as the router, labeled edges to each branch, and the trace view recording every evaluation for debugging. Start with a single router, keep conditions flat, converge every branch, default everything, log and prune. Full guide available at https://getloopcraft.com — sapsap@qq.com.
Reading time: 6 min