diff --git a/Graph-Agents.md b/Graph-Agents.md
index 2189714..76e8440 100644
--- a/Graph-Agents.md
+++ b/Graph-Agents.md
@@ -92,7 +92,7 @@ variables:                           # optional; agent variables
     default: "."                     # via `--agent-variable` at runtime
 
 settings:
-  max_loop_iterations: 100     # PER-NODE visit cap; default 100 (see below)
+  max_loop_iterations: 100     # PER-NODE visit cap; default 100, 0 = no cap (see below)
   log_state_snapshots: true    # log state JSON before each node executes
   validate_before_run: true    # run the graph validator on startup
   timeout: 600                 # optional overall timeout in seconds; 0 = no bound
@@ -150,7 +150,20 @@ nodes:
 - **`max_loop_iterations`:** This is a **per-node visit cap**, not a total
   graph-step cap. If the same node id is entered more than this many times,
   execution aborts with `Node 'X' visited N times (max_loop_iterations=...)`.
-  Default: 100.
+  Default: 100. `0` disables the cap. Use it when a node is legitimately
+  re-entered a data-dependent number of times — e.g. a reflexion loop that
+  pulls jobs from a list re-enters `review` once per job × per round, so no
+  fixed cap is right. If the job list is known up front, prefer a `map` over
+  it — each item forks fresh visit counts, so the cap then measures per-job
+  non-convergence (use `max_concurrency: 1` if jobs must be sequential); use
+  `0` when the list is discovered mid-run or the loop needs `approval`/`input`
+  gates (disallowed inside branches). With the cap off, a non-converging loop
+  is stopped only by `settings.timeout`, an enclosing agent node's `timeout`,
+  or Ctrl-C; if you also set `timeout: 0`, nothing bounds the run but
+  completion. The validator warns on the explicit `0`. The `0 = no bound`
+  rule applies to `timeout` and `max_loop_iterations` only —
+  `max_iterations: 0` on an `llm` node runs zero turns and fails, and
+  `max_concurrency: 0` is a validation error.
 - **`timeout`:** Wall-clock cap on the entire graph run. Checked before each
   super-step **and** enforced during super-steps: if the budget elapses while
   nodes are still running, the in-flight branches are aborted and the run
@@ -1051,9 +1064,11 @@ Rules for the loop:
   review_file). Script `_next` targets inside a map branch must stay within
   the branch.`
 - Each node's per-item visit count is bounded by
-  `settings.max_loop_iterations` on the fork; exceeding it fails the item
-  and names the node and the count. Keep your own budget (`retry_count`)
-  under that hard cap.
+  `settings.max_loop_iterations` on the fork (`0` = no cap); exceeding it
+  fails the item and names the node and the count. Keep your own budget
+  (`retry_count`) under that hard cap. `0` disables that cap too; since there
+  is no per-item timeout, a runaway `_next` loop in a branch is then stopped
+  only by `settings.timeout`, the enclosing agent node's `timeout`, or Ctrl-C.
 - Item errors are fail-fast and carry the chain position:
   `map node 'review_each_file': sub-branch [2] failed at node 'check_review' (step 2): ...`.
 - A `script` step that fails consults its `fallback:` (a branch-local node)