On Agentic AI Orchestration Patterns: Deterministic Loops & Graphs for Stochastic Agents

From Interactive Prompting to Goal-Driven Agentic Workflows as Code for Long-Horizon Reasoning and Execution

TL;DR: Coding agents stop early on long tasks, so a human has to decide what happens next, even though the agent usually already knows. An automated outer loop or graph, driven by goals that are rigorously defined and evaluated from outside the agent, takes that human out of the cycle.

Every agentic workflow has a stop condition. The question is whether yours is you.

You have typed “continue” into a coding agent. You have typed “keep going”, “not like that”, “you didn’t run the tests”. You have kept a terminal open in the corner of the screen and glanced at it between other things, because the run stops the moment nobody is looking.

This is not the agentic workflow you were promised. It feels like babysitting, and babysitting is inherently defined by presence: the work moves while you sit next to it and nudge, and stops when you look away. The cost is not only the typing. It is that you cannot start anything else, because anything else would need the attention this run is spending.

That is not prompting. That is control flow, the part of a program that decides what runs next and whether it runs again. In an interactive session, that part is a person. Take the person out and nothing continues.

This makes it an attention ceiling rather than a capability ceiling. A workflow whose repeat condition is a person scales exactly as far as that person’s day, and a better model buys better steps, not more of them. Models do keep improving, and the chains of tool calls they sustain unattended keep getting longer: hours now, where it used to be minutes. But on genuinely hard work the chain still ends before the job does. The agent stops to ask a question, or announces success on something half finished, and the run is over until you come back.

The reason is the same every time, and it is the problem this whole article is about:

The agent is the one deciding whether it is done. It grades its own homework, and it marks generously.

Let us take an example. The famous P versus NP problem asks whether every computational (decision) problem whose answer is quick to check is also quick to solve; it has been open for decades. The specific theory does not matter here. What matters is the shape of it. Nobody knows a path to an answer. It may not even be reachable with the current AI technology at all. But one thing is sure: any serious attempt will run far longer than a person can sit and watch. That is the extreme end of the work this article is about, and the useful thing about an extreme is that it makes the mechanism visible.

The promise of everything below is a long horizon: reasoning and execution that keep going long after you have stopped watching, for days or weeks or months, potentially even forever if that is what the goal takes. What makes that possible is that the decision about the next step comes from something other than a person.

At Level 1 the return arrow is the control flow, and it is a person.

The ground: the model and the coding agent

Two things sit underneath everything that follows, and neither is what this article is about. No amount of orchestration replaces either.

Ground 0: the LLM. Raw capability: how well it writes code, how well it reads an error message, how much it holds in mind at once. The Claude, GPT and Gemini families, and whatever succeeds them. Everything on top is an arrangement of calls to it, and no arrangement makes a single call cleverer than the model is. A better model gets further into a hard problem before it stops. What it does not change is that the run still ends early on long work, or who decided to end it.

Ground 1: the coding agent (harness). A model plus the machinery that lets it act on your machine: standing instructions it always sees, tools it may call, a walled-off area those commands may touch, and a session, meaning one continuous conversation from start to reset. Claude Code, OpenAI Codex and GitHub Copilot CLI are the familiar ones.

Coding agents have become good at staying alive. A session that fills its context can summarise itself and carry on, so the context window is no longer the wall it once was. What no coding agent does is keep going past work it has decided is complete. It stops to ask a clarifying question, or reports success on something half done, or simply reaches its own sense of an endpoint and hands the terminal back. Those are one failure wearing different clothes: the thing doing the work is also the thing ruling on whether the work is finished.

The four levels of automation at a glance

What follows is a progression, and what moves along it is the repeating decision: do the work, check it, go again. At Level 1 you make that decision every single time. Level 2 (loops) is where you stop making it during the run. You write it down once, in advance, and an outer loop applies it while you are elsewhere. Levels 3 and 4 widen how much of the workflow you can settle in advance, and change the medium (graphs and code) you settle it in.

Each level answers a limit in the one below it. Let us take them in turn.

Level 1: Interactive Prompting

This is where agentic work happens by default these days, and it is where the babysitting is.

Level 1 is you, in a session with a coding agent, reading each result and supplying the next instruction. Two established crafts live here. Prompt engineering shapes the instruction: worked examples, reasoning before answering, a pinned output format. Context engineering, covered on the same page as the management of everything else the model is given, shapes what the call operates on, and just as much what you keep out of it.

Both are real skills with real gains, but neither touches the problem. A better prompt does not stop an agent concluding it is finished. A better-assembled context does not either. You still learn that the run ended by looking at it. Put P versus NP to a coding agent this way and the session is over long before the problem is, not because the model gave up on the mathematics, but because it reached the end of what it considered a reply.

Level 2: Loop Engineering

The obvious fix is to repeat.

When the agent stops early it rarely stops silently. It signs off with a paragraph describing what it would do next: the line of attack it would try, the file it would look at, the experiment it would run. So you type “go go go”, and it does exactly that. You have added no information. You have supplied a decision the agent had already made and was not permitted to act on.

That is all that is left of your involvement, and it is trivially automatable, except at three in the morning when nobody is there to type it.

So automate it. That is Loop Engineering: an outer loop that runs the coding agent (the inner agent), looks at what came back, and runs it again.

Those two terms carry the rest of this article. The inner agent is the stochastic part: one session, doing the work, then ending. The outer loop is everything around it: which role to run, whether to run again, when to stop. Level 2 is the observation that these are different jobs, and that they should belong to different things.

A lap is not a single step

A loop does not mean one instruction repeated. What laps is the cycle, and a cycle can have several steps in it, each one a role: a session with its own brief, and if you want its own model and its own budget.

Take P versus NP. A researcher goes and reads: what has been attempted, which barriers are known, what the field already proved impossible. A prover takes the strongest surviving line and pushes it. A critic attacks the current attempt looking for the gap, briefed to be unkind and given the strongest model you are willing to pay for, because catching a flaw is worth more than producing another one. Round the cycle, then round again.

None of that needs anything beyond a loop. A fixed cycle of three roles is still a loop: the same roles, in the same order, every lap. What a loop cannot do is choose. It cannot decide that this lap should skip the prover and go straight back to the researcher. That is the only thing Level 3 adds, and it is worth being precise about, because the roles themselves are available here.

State: what one session leaves for the next

Every session begins empty. That is deliberate: it is how the run avoids the drift that accumulates inside one long conversation. But a run that starts empty and ends empty is not a run; it is a hundred unrelated attempts at the same problem, where the hundredth is no further along than the second.

What links them is state: everything the run has produced that outlives the session that produced it. In practice it is two things. The first is the artefact and its version history: the work itself, and the record of how it came to look that way. The second is a written account of the run, covering what has been tried, what it cost, what failed and why, and where the next session should start.

Both halves of the system write to that account, and they write different things. The inner agent records what it learned, not by appending to a log but by revising: folding a new finding into what was already there, correcting what turned out to be wrong, dropping what no longer matters. The outer loop records what the inner agent cannot be relied on to record about itself: which role ran, what the check returned, what was kept and what was rolled back.

That division is not housekeeping. An account that only ever grows becomes, within a few dozen laps, longer than the context it has to fit inside; at which point the next session skims it, misses the finding that mattered, and repeats a failure from four laps ago. Curation is the mechanism that keeps the run’s memory smaller than its history, and it is why the account is something the loop maintains rather than something you are expected to tidy up afterwards.

Who decides it is finished

One thing remains, and everything in this article turns on it. Something must answer is this done?, and it must not be the inner agent.

Loops already exist inside coding agents: the internal run-a-command, read-the-error, retry cycle; a goal feature that keeps working until it judges the goal met; you, re-prompting by hand. All of those are loops, and all of them still stop early, because the thing deciding whether to go round again is the model. So the question is not where the loop sits. It is who is bound by its answer, which sounds like one question and is three.

Authority: who is bound by the answer? Three positions, and only the last of them lets you leave:

• Inside the session. The evaluation arrives as text in the context, and the model decides what it means. However rigorous the content, it is advice.
• At the edge of the coding agent. Some agents let an external script refuse to let a session stop. That genuinely binds, but only on stopping, only within that one session, and the script’s own configuration sits in the repository the worker is editing.
• Outside the agent entirely. A separate process runs the check and owns the continue-or-stop decision. Nothing the inner agent writes reaches it and nothing it says overrides it. This is the position that buys what the other two cannot: the right to be absent.

Determinism: how is the answer computed? Two ways, and the question only becomes meaningful once you are in that third position:

• By execution. A build, a test suite, a proof checker. The same input gives the same answer every time.
• By an LLM-as-a-judge, scored against criteria written in advance. Useful where nothing executable exists, and honest about its limits, since running the same rubric twice can produce two different answers.

Inside a session the distinction collapses entirely. An agent that runs the test suite and reads the output has performed a perfectly deterministic check, and then decided for itself what it meant. The check is deterministic; the decision is not.

Integrity: can the inner agent reach the check, or its result? Both halves matter, and the second is the one usually missed. The check is a script on disk, and a coding agent edits files for a living: an agent that cannot make a test pass can make the test not run. Delete it, comment out the assertion, widen the tolerance. Each of those is locally reasonable to something under instruction to finish. But the result is on disk too. A verdict the inner agent can write is worth exactly as much as a check it can edit, because the loop reads the verdict, not the intention behind it. Being deterministic protects neither, and neither does being external, if both sit where the worker writes.

Deterministic Loop Engineering

When all three hold, the arrangement has a name.

Deterministic Loop Engineering: the decision made outside the agent (authority), by code rather than by a model (determinism), over a check and a result the worker cannot reach (integrity).

The name puts the determinism where it belongs: on the loop, not on the evaluator. What must be code is the thing that decides. What that code consults can be either kind of check, and a model scoring a rubric is entirely admissible. It simply brings its own variance, which is why an executable check is the better answer whenever one exists. Loop engineering as commonly defined permits any answer to all three questions. DLE is the subset where leaving the room is defensible.

Panel B is DLE. The boundary moved; nothing else did.

Only the third arrangement clears all three questions.

What it asks of the goal

All of this rests on one precondition: the goal must be describable in advance, precisely enough that something other than the inner agent can rule on it.

P versus NP is the pure case. Nobody knows the path, and probably no amount of prompting will conjure one, yet the goal is stateable with total rigour, and a proof checker will rule on a candidate without being talked round. Perfectly unknown, perfectly checkable. The same shape appears far outside mathematics: an implementation whose output must match a reference, a strategy that must beat a named baseline on historical data, a design a simulator scores. In every case the verdict is a fact rather than an opinion.

Vague goals work less reliably. “Make the code nicer” leaves so much slack that almost anything satisfies it, and the run falls back on the model’s own taste, which is Level 1 wearing a loop. A model scoring a written rubric can rescue a goal with no executable form, and sometimes it is the only instrument available. Treat it as the last resort rather than the default: a fact you can execute does not have a mood.

What it buys, and where it stops short

What it buys. The long horizon, which was the whole promise: something other than you now types “go go go”. Because each lap starts fresh and everything that matters is in state, the run is no longer bounded by the size of one context window. It is bounded by the goal.

Where it stops short. A loop laps in a fixed order. It cannot skip the prover when the researcher has just overturned the premise, cannot decline to pay for a slow check that obviously cannot pass, and cannot tell the difference between an attempt that failed and an approach that is wrong. The moment the run needs a choice rather than a repetition, it needs you again.

Historical notes

None of this is new. Frameworks have worked this way for years:

• **AlphaCode** (2022) generated many candidate programs and filtered them by execution against tests.
• **FunSearch (2023) made the loop explicit: a model proposes, an automated evaluator scores, and the best-scoring programs return as the next prompt. [AlphaEvolve](https://en.wikipedia.org/wiki/AlphaEvolve)** (2025) is the same architecture with stronger models. Integrity is free in all three, because the thing being graded is a function with no reach.
• **The Ralph loop** (2025) is a shell loop feeding one prompt file to a fresh session, over and over, with all state in the repository. This is why long-horizon runs became practical at all. It has no stop condition; the person is still the loop condition, one level up.
• **“Loop engineering”** (2026) named the practice of building the system that prompts the agent instead of doing it yourself. It is deliberately permissive about the evaluation: a test suite qualifies, and so does a model call. Only one of them lets you leave.
• **The Gauntlet Loop* (2026) pairs builders with blind critics and judges each part against a real-world reference. It externalises the standard while leaving the judgment* inside, and its own documentation is plain that the loop will not finish on its own. You are the brake.

The property was never argued away. It was dropped quietly, when the thing being graded stopped being a function and became a repository. A repository is hard to grade by execution, and a model that will grade anything is always at hand.

Level 3: Graph Engineering

A loop laps in a fixed order. A graph chooses.

What it is. The workflow made explicit: the roles, and the transitions the run is permitted to take between them. A loop is the special case where those transitions form one fixed cycle, the same roles in the same order every lap. Drop that restriction and the run can branch: skip a role whose output would now be pointless, take a different route when the current one is exhausted, run two lines of attack in parallel and rejoin them, or hand the work to a person.

Everything from Level 2 carries over: the inner agent, the state, and the three questions about who is bound by an answer. What is new is that some transitions now carry conditions of their own. Most edges are unconditional; the few that are not are the entire value of the graph, and each of them faces those same three questions of authority, determinism and integrity. A workflow with a rigorous exit condition but model-chosen routing has quietly re-admitted at those junctions exactly what the exit condition was built to exclude.

The research literature reached the same place from the other side, when “flow engineering” named the move from one clever call to a written-down sequence of steps and checks.

A loop is a cycle of roles. A graph decides which role comes next.

For P versus NP the difference is concrete. In a loop, a stall check can only report that nothing is moving. In a graph it can route: three laps with no progress sends the run to the researcher instead of the prover, which is the difference between a search and a grind.

Where it stops short. A graph is a program. It has branches, joins, state that survives between steps, and conditions evaluated while the run is still in flight. Expressing that in a configuration format means designing a small language for control flow, and small languages written under deadline acquire a conditional, then an expression syntax, then variables, then some way to reuse a fragment. They arrive eventually at a bad programming language with no type checker and no debugger. Which raises the obvious question, given that languages built for control flow already exist and have for half a century.

Level 4: Agentic Workflows as Code

What it is. Programming languages are the notation for control flow, and they have had decades poured into loops, conditionals, early exit, retries, error handling, scoping, composition and tests. Agentic Workflows as Code declines to reinvent any of it: the workflow becomes an ordinary program, and the prompts stay prompts.

The checker is the only thing that can end the run. The critic can only send work back.

In plain English: a proof checker, and nothing else, decides whether the run is finished. Three roles share one piece of machinery and differ only in their brief, with the critic given the strongest model available. Each runs in a fresh session, receives the state and returns a new one, so what one role learned is what the next role gets and nothing else crosses the boundary. And when three laps produce nothing, the run goes to the researcher rather than back to the prover.

Note what the critic is allowed to do. It is a model passing judgment, which this whole article has been warning about, but here it can only send work back, never declare the run finished.

A model’s opinion is admissible exactly when it can add work and never end it.

The proof checker keeps the only authority that matters.

A while, an if, function calls, four values. Every construct already existed. Programming languages are Turing-complete, so whatever control flow the run turns out to need can be written. That is the point at which the notation question stops being interesting, and the problems that remain are no longer about structure at all.

Where else this fits: use case examples

The general concept of a goal-driven agentic run is not specific to code. Whatever the domain, the architecture has the same three parts:

• The artefact: The thing being improved: a repository, a proof, a molecule, a strategy.
• The check: Something outside the inner agent that rules on the artefact and cannot be argued with.
• The tool the check runs on: a proof checker, a compiler, a simulator, a backtest, a game engine.

Swap the artefact and the tool, and the machinery is unchanged.

If no such tool exists for your problem, there is nothing for the loop to stand on, and no amount of orchestration around it will change that.

Some shapes it fits:

• A proof. The artefact is a Lean file and the tool is its proof checker, which accepts or rejects and has no opinion about how hard you tried. P versus NP is the extreme version; every formalisation project has the same shape.
• A program. The default case, and the reason most of this article is about code: a test suite, a compiler, a benchmark that has to beat a recorded number.
• A molecule. The artefact is a candidate compound and the tool is a simulator, with the goal stated as properties inside stated bounds.
• A trading strategy. The artefact is the strategy, the tool is a backtest over historical data, and the goal is beating a named baseline out of sample.
• A chess strategy. The artefact is the policy and the tool is an engine, with the goal set to beating the best version this run has produced so far.

That last one is worth pausing on, because the check does not have to be a fixed target. Point it at the run’s own previous best and the loop becomes a ratchet: every success raises the bar the next lap has to clear, and the run improves against itself without anyone adjusting anything.

And the artefact is not the only output. Every lap leaves behind a record of what was tried and what the tool said about it. That record is what the next lap starts from, and it is why a run that never reaches its goal still returns something: a map of where the goal is not.

Self-improvement, and the recursive kind

Nothing said so far stops the artefact being software you rely on. Point the loop at a codebase, give it a check, and it improves that codebase while you are elsewhere. The “self” in self-improving software refers to the autonomy rather than to the identity of the target: no person is driving the improvement.

The recursive case is the one people mean when they get excited. There, the artefact is the improver: the loop is pointed at its own repository, adds a capability to itself, and the next run is performed by the improved version. That is a real thing to build, and much closer than it sounds, because it needs no machinery beyond what this article already describes.

Two things keep it from being magic.

The first is that the model does not improve. The weights are fixed. What accumulates is workflow, state and checks, so each round starts from a better system, never a better mind. That is a real ceiling, and worth stating plainly, because “recursive self-improvement” borrows its drama from a scenario in which the reasoner itself gets sharper each time, and that is not what is on offer here.

The second is the integrity question, arriving at its sharpest. A run improving its own repository has, by construction, write access to everything about itself, including the checks that decide whether a change counts as an improvement and the results those checks produce. A run that can edit its own success criteria will sooner or later discover that editing them is the cheapest way to succeed. Everything above about putting the check and its result beyond the worker’s reach applies here at volume, and it is the difference between a system that improves and a system that learns to look improved.

And one thing does not automate at all: which goals are worth having. A loop will drive toward the goal you set it. It cannot tell you the feature was not worth building. Hand goal selection to the run as well and you get a system that grows relentlessly in directions nobody asked for, which is the oldest failure in software, now running unattended.

Comprehension collapse

There is a cost to leaving the room and letting the agents work on their own that no amount of engineering removes.

While you were babysitting, understanding was a by-product. You read every result because you had to approve the next step, so you learned the shape of the thing being built without setting out to. Level 2 removes exactly that by-product. A gap opens between what exists and what you understand of it. That much is nothing new, and already well described: comprehension debt, also called the comprehension gap, is the distance between what a team knows about its codebase and what it would need to know to change it safely. What is new here is that it does not stay a gap.

Each unattended lap builds on the last. The second changes work you never read, on decisions you never saw; the third changes that. Nothing pulls the two back into line, so the divergence compounds instead of settling. A graph makes it worse again: you no longer know which path ran, so you cannot reconstruct the order things happened in. Debt implies a balance you could choose to pay down.

What accumulates here is better called comprehension collapse. The thing that turns one into the other is iteration.

The failure is not that the artefact is wrong. It may be right, and verified. The failure is that you can no longer review it, change it safely, or say why it works.

Three mitigations bound the loss, and they belong in the design from the start rather than after the first run you cannot read.

• Periodic reflection. Short accounts of what the run is doing, emitted while it happens rather than assembled at the end. Cheap, and they leave a thread you can pick up.
• Intervention injection. Session boundaries are natural seams: a queued message the next lap will read lets you steer without having to be present at the moment it matters.
• Retrospective comprehension. Once the goal is met, have the run explain what it did and why, and where the stakes justify it, rebuild the result cleanly from that explanation. Of the three, only the rebuild restores understanding; the other two ration its loss.

Blast radius

The second cost is that agents play havoc.

Any agent running in an automatic mode, with permission prompts waived and commands executed as it sees fit, will sooner or later take a step whose reach you did not intend. The internet is full of the results: deleted working directories, force-pushed branches, production credentials used exactly as instructed. Not necessarily from malice; each step looked locally reasonable to something under instruction to finish, and nothing was there to disagree. Above Level 1 that mode is not a choice but a technical prerequisite. An unattended run is automatic mode, by definition, for as long as it lasts, so confinement stops being a preference and becomes a precondition.

Two mitigations, and they compound. Shrink what the inner agent is responsible for: every decision moved into the deterministic part of the loop is one the agent no longer makes, and reach follows responsibility. Then confine what is left with an operating-system sandbox, a container, and an explicit account of what may be read, written, and reached over the network.

Confinement is not only about damage. It is what makes the integrity property real: the check sits beyond the inner agent’s reach, and so does the result it produces, because something enforces that they do. Without enforcement, “the agent cannot edit the check” is a hope.

What this looks like implemented: AgenticGoGo

There are plenty of implementations of the loop idea. Check out my own implementation of a Deterministic Loop / Graph Engineering framework: AgenticGoGo.

Workflows are YAML while a sequence is enough, and an ordinary Rust program once the flow has to branch. That is the Level 3 to Level 4 move, made concrete. A check can be any script, or a model call against a written rubric; what it is matters less than that the outer loop consults it and the inner agent cannot.

Around that: boolean composition of checks into a definition of done, a fresh session every cycle with state carried in Git and a cross-linked wiki, isolation by OS sandbox or container, automatic rollback of a cycle that fails its checks, terminal and web dashboards, intervention injection at session boundaries and periodic reflection against the comprehension problem above, and support for Claude Code, Codex and Copilot CLI. And many more features ;-)