A practical framework for choosing deterministic workflows, bounded decisions, dynamic fan-out, and agentic loops—without adding more autonomy than the work requires.
Calling a whole product “a workflow” or “an agent” is usually too coarse to help. Real systems mix several control patterns. The useful decision happens one step at a time: this classification, this dispatch, this repair, this investigation.
Consider software delivery. Requirements, design, build, test, and release follow a known order. That outer process is deterministic. Inside it, fixing a failed test is iterative: inspect the failure, form a hypothesis, patch, rerun, and stop when the test passes or the budget expires. The same release contains both patterns.
Enterprise AI works the same way. Quote-to-Order should remain reproducible even if an LLM helps read an input. Talk-to-Data may use probabilistic language-to-SQL reasoning, while its Planner → Validator → Executor → Healer graph stays fixed and auditable. A cross-system investigation is different again: each finding determines the next question, so the path cannot be fully drawn in advance.
This playbook replaces the workflow-versus-agent binary with five constructs. They differ along two axes: how much of the path is known before execution, and how much context must survive while the work unfolds.
As control flow becomes less predictable, the system must carry more state, evidence, and history. That does not automatically make it better. It makes it harder to test, govern, reproduce, and stop.
The same steps run in the same order every time. Where the path branches, code resolves it — not model judgment.
The process is known, repeatable, and has to be auditable — especially when a regulator or a downstream system expects the same shape every run.
Still a fixed pipeline, but one node lets a model make a narrow, closed-set decision — a classification or intent label — which a deterministic dispatcher then routes on.
One step in an otherwise-known process needs judgment, but you can enumerate the possible outcomes in advance and pre-author what happens for each.
The subtasks aren't known ahead of time — a coordinator decides how many workers to run and what each does — but the whole thing still runs once and terminates when the fan-out closes.
Work decomposes into independent pieces, but you can't say in advance how many, or what they'll be: parallel research, multi-strategy exploration, multi-section synthesis.
A model iterates until an explicit gate says stop: a test passes, a confidence threshold clears, a turn budget runs out. Open-ended in duration, closed-ended in what each turn is allowed to do.
There's a cheap, reliable check for "is this done" — a failing test, a schema validator, a compliance rule — and revision genuinely improves the answer.
What gets looked at next depends on what was just found. Recursion, fan-out, and backtracking are all in play; termination is a judgment call, usually enforced by more than one gate.
The exploration itself is the product — the next question isn't knowable until you've seen the last answer — and a wrong turn is recoverable because nothing ships without review.
A deterministic scaffold — phase gates, a shared state file, an audit log — around one or more agentic loops running underneath it. This is a composition, not a sixth register.
Multiple autonomous loops (or coding assistants) need to share state and stay auditable without becoming a single mega-context.
No construct is universally better. Each gains flexibility by giving up some predictability, auditability, speed, or cost control. Treat the disadvantages below as the price of the capability—not as a verdict against it.
| Construct | Advantages | Disadvantages |
|---|---|---|
| 01 Deterministic | Fully auditable and reproducible; predictable cost and latency; every path can be tested exhaustively; trivial to justify to a regulator or a client's audit team; no context-rot risk, since nothing accumulates between steps. | Brittle outside the pre-enumerated cases; a genuinely new scenario needs a code change, not a prompt change; forces real ambiguity into a branch that doesn't quite fit; the branch count grows faster than the real-world variation it's modeling. |
| 02 Bounded decision | Keeps 01's auditability while absorbing exactly one ambiguous step; cheap and fast — a single narrow call on a small context; easy to monitor, since every intent label and its distribution can be logged; failure is legible: a wrong label, not a wrong plan. | Only works when the outcome set is genuinely closed in advance; an input that fits no label needs its own fallback or fails outright; a new case still means a code change (new label, new branch); doesn't help once two steps need coupled judgment. |
| 03 Dynamic | Absorbs real "how many, what kind" uncertainty without going fully open-ended; parallel workers add both speed and, via voting, confidence; each worker's context stays small and clean, so quality doesn't decay with scale; still terminates predictably in one pass. | Dispatch, timeout, and join logic are real engineering, not free; a synthesis step can quietly average away a valid minority finding; harder to audit after the fact than a fixed pipeline, since which workers ran wasn't fully predetermined; fan-out width still needs a cap or cost and latency spike. |
| 04 Bounded loop | Iteration genuinely improves the answer wherever a cheap correctness check exists; the blast radius is contained to what one turn is allowed to do; a hard budget or threshold gives a predictable worst case; the exit condition is one named, inspectable thing. | Only as good as the check — a weak or gameable test lets the loop "pass" a bad answer; a naive implementation accumulates context turn over turn and degrades before it ever hits the budget; can thrash between two wrong fixes without noticing; every retry is a real cost and latency multiplier. |
| 05 Open loop | The only construct that can do real open-ended investigation — find the next question worth asking; backtracking corrects early mistakes instead of compounding them; recursion and fan-out reach a scale a fixed pipeline was never designed to cover. | The highest context-management burden of the five — real engineering, not a setting, to keep it from rotting; hardest to audit or reproduce, since two runs can legitimately take different paths; a single soft gate is unsafe, so it needs several independent ones, which is itself extra design work; cost, latency, and outcome are all the least predictable here; needs review before anything ships. |
| + governance shell | Lets independently built loops — different assistants, different teams — share state and stay auditable without merging into one context; gives after-the-fact accountability even when the loops underneath aren't fully deterministic; scales oversight without scaling context. | Adds a coordination layer that has to be maintained and can drift out of sync with what's actually running underneath; doesn't fix a bad loop, just adds bookkeeping around it; one more moving part to fail — the shell's own state file can become the bug. |
Ask these questions in order. Compliance comes first because it can remove freedom from every choice below it. A step that benefits from exploration may still need a fixed output and explicit review when regulation or contract terms demand it.
Real systems combine constructs. A deterministic shell may contain a bounded repair loop. A dynamic coordinator may dispatch workers that each make one bounded decision. Design each node separately, then compose the system.
| System | Construct(s) | Why this shape | Context tactic |
|---|---|---|---|
| Full SDLC | 01 shell + 04 at the defect node | Phase order (requirements→design→build→test→release) is the value and must stay auditable; only "make the failing test pass" rewards iteration. | State passes between phases as structured artifacts (tickets, diffs, reports) — the loop node compacts to the last diff + failure output each turn, not the phase history. |
| Quote-to-Order | 01/02 | Pricing and contract steps must reproduce the same output for the same input; MAS's harness generalizes this shape across Q2O and Order-to-Cash. | Typed order/state object carried between stages, not conversational memory. |
| Talk-to-Data | 02 | NL→SQL parsing is probabilistic, but the Planner→Validator→Executor→Healer shape never changes — process-determinism, not output-determinism. | Healer stage sees only the failing query and its error, not the full conversation that led there. |
| Agent Adda inner loop | 02 nested in an outer 04 | Same classify-then-dispatch shape as T2D and CANON, chosen for latency, cost, and production-safety — not because the judgment was easy. | A 5-turn ContextPack rebuilt each turn instead of full history; router gets a typed RouteDecision, not raw context. |
| ATLAS | 03 + 04 | Strategy exploration is genuinely open (03); each healing/repair cycle underneath it is bounded by a check (04, shadow A/B as the gate). | Workers return condensed strategies to the arbiter, not full reasoning traces. |
| RIC | 05 | The exploration is the product: insights seed further investigation, chains narrow and fan out across four enterprise systems. | Each recursion level propagates the insight, not the trace that produced it — compaction built into the pattern itself. A 12-pattern language plus a pattern-selection algorithm governs what would otherwise be unconstrained recursion. |
| ShunyaSaarthi tutoring turn | 02/03 | Curriculum sequence is fixed (deterministic scope); diagnosing a misconception and picking a remediation path within a lesson is adaptive. | MAS's five-layer harness (memory, state object, loop controller, tool/connector, guardrail) generalized across this and Q2O/T2D, so one skeleton serves very different determinism levels. |
| Migration estimation agent | 01 behind an agentic front door | The recipe (Scope→Activities→Unit Drivers→Base Effort→Volume Efficiency→Contingency→Person-Days→Cost) is a formula; only the scoping conversation that fills it is exploratory. | Elicitation surface kept separate from the computation surface — only validated, typed scope inputs cross into the deterministic recipe. |
| Claude Code + Cursor build | governance shell over 04/05 | Each coding assistant runs its own loop; .agent-protocol/STATE.json, blast-radius analysis, and a hash-chained audit log keep the overall build auditable. | A shared state file is the handoff between agents, not a replayed conversation. |
Context is a finite working resource. A larger window does not remove the need to decide what the model should see now. Four practices do most of the work: compaction summarizes and resets; structured notes keep durable state outside the prompt; worker isolation gives detail tasks clean windows; and just-in-time retrieval fetches evidence only when needed. More open constructs depend on these practices more heavily.
An agentic loop is a reinforcing loop — each turn's output becomes next turn's input, and small errors compound the same way small gains do. A reinforcing loop with no balancing condition isn't stable, it's just early: it hasn't diverged yet.
Practically: 04 and 05 both need their governor named before the first iteration runs, not discovered after one runs long. RIC's answer is to never rely on one — confidence threshold, depth limit, and human approval have to clear together, precisely because a single soft gate can be reasoned past ("confidence is close enough"). The other common failure isn't runaway iteration but runaway context: a loop that never compacts gets slower and worse every turn long before it gets more expensive — the failure shows up as quality decay, not a cost alert.
Architecture mistakes often come from granting too much freedom, too little freedom, or no reliable stopping rule. These failures are visible before production if the team knows what to look for.
Cost and variation rise without improving the answer. Replace model judgment with a rule or typed branch.
Novel cases get forced into the nearest known path. Move only the uncertain step into a dynamic or open construct.
The model revises toward its own preferences rather than correctness. Add an external test, validator, or human gate.
Noise accumulates, contradictions survive, and later turns inherit obsolete assumptions. Compact to state and evidence.
Workers repeat the same reasoning and return correlated errors. Give each worker a distinct scope and clean context.
A model can reason past “close enough.” Combine hard budgets, confidence evidence, depth limits, and review.
| Construct | Graph known upfront? | Context load | Governor needed? | One example |
|---|---|---|---|---|
| 01 · Deterministic workflow | Yes, fully | No | Swing Playbook's 9-step process | |
| 02 · Bounded-decision workflow | Yes, except one closed-set call | No | Talk-to-Data's Healer stage | |
| 03 · Dynamic workflow | No — fan-out decided at runtime | Join/timeout only | ATLAS strategy planning | |
| 04 · Bounded agentic loop | No — but has a cheap "done" check | Yes — one explicit gate | Defect-fix loop against a test suite | |
| 05 · Open agentic loop | No — the graph is the output | Yes — multiple gates together | RIC recursive investigation |
Before adding an agentic step, answer these questions in writing. If the answers are vague, the architecture is not ready.
Classify one decision or activity—not the whole product.
What cannot be resolved reliably with code, rules, or a known workflow?
Use the least freedom that still handles the uncertainty honestly.
Specify what enters, what changes, and what leaves the step.
Grant only the systems and actions required for this step.
Define completion, retry budget, timeout, escalation, and human approval.
Decide what is compacted, stored, retrieved, isolated, and discarded.
Preserve decisions, inputs, outputs, checks, and state transitions—not hidden reasoning traces.
Simulate wrong labels, stale state, failed tools, disagreement, timeout, and non-convergence.
Move left when rules become clear; move right only when fixed paths repeatedly fail.