Summary / 23. Workflow and state machine / Document
Paper 2026-09-06
Shared copy: the operator's name and machine names are replaced by roles. Nothing else is changed.
Rendering…
# Component 23 — The Workflow / State Machine ## The Coding Workflow as an Executable, Evidence-Gated State Machine Under a Deterministic Control Plane --- ### Abstract This paper specifies the twenty-third component of the coding harness: the workflow itself. By component 22 the harness possesses every individual stage — reconnaissance, localization, impact analysis, decomposition, generation, editing, execution, tracing, debugging, repair, reflection, candidate generation, test execution, validation, regression protection, episodic memory, and the independent reviewer. Component 23 is the thing that *orders* those stages, and its central claim is that this ordering must not be emergent: the workflow must be a declared, executable state machine — explicit states, legal transitions, permitted tools, input/output schemas, entry and exit conditions, retry and rollback paths, and terminal outcomes — advanced by deterministic evidence wherever possible, with adaptive plan nodes inside controlled states, artifact-dependency tracking that invalidates and recomputes only affected downstream work, verified upstream state preserved across retries, and LLM calls reserved strictly for the semantic judgments made inside states. The entire control plane — the phase graph of states, legal transitions, gate predicates, per-state tool permissions, artifact-freshness and invalidation tracking, and retry/rollback/termination edges — is deterministic software on CPU holding **zero** learned entries; the single learned entry is the semantic judgment made *inside* a state. We assemble the evidence in both directions: Agentless's fixed three-stage localize→repair→validate pipeline (32.00%, 96/300 on SWE-bench Lite, $0.70 average cost, FSE 2025) as the argument that declared structure beats autonomy, and the traceability literature as the measured cost of the open floor; StateFlow (COLM 2024) separating process grounding from problem solving; CodePlan and Runtime-Structured Task Decomposition as the artifact-dependency and adaptive-plan machinery; and AFlow, ADAS, GPTSwarm, and DSPy as the tunable controller, closed by AgentSpec's runtime enforcement and the Clarke–Emerson–Sistla model-checking result that lets the phase graph be verified exhaustively for reachability, safety, and liveness before it ever runs. --- ## 1. Introduction The harness has spent twenty-two components learning how to do each *part* of the job. This component is about who decides *what happens next*, and the answer it defends is the least glamorous answer available: nobody decides at runtime. The order of operations is a graph, written down in advance, advanced by evidence, and the model is invited into it only where a semantic judgment is actually required. The inversion this paper argues for can be stated in one sentence. The model must not own planning, must not own workflow, must not own tool choice, must not own termination, must not own retry, must not own rollback, and must not own the ordering of validation. All of those are *state-management problems*, and state management is a problem that software solves perfectly and that language models solve approximately, at cost, and without any guarantee. A loop that asks the model "what should you do next?" has converted a solved problem into a probabilistic one. The single most important architectural decision of this component is therefore to *stop asking*. **The coding workflow should be an executable, evidence-gated state machine rather than an emergent LLM trajectory: define explicit states, legal transitions, permitted tools, input/output schemas, entry and exit conditions, retry and rollback paths, and terminal outcomes; let deterministic evidence advance the workflow whenever possible; allow adaptive plan nodes and branches inside controlled states; track artifact dependencies so new evidence invalidates and recomputes only affected downstream work; preserve verified upstream state across retries; and reserve LLM calls for semantic judgments within states rather than asking the model to manage its own process.** **Piper should solve the coding problem. She should not also have to remember how software development is supposed to work. The harness already knows that.** The second sentence is the human version of the first. The coding problem — "what is wrong, and what change makes the tests pass without breaking the contract" — is genuinely hard and genuinely semantic; it is where a learned model earns its place. The process problem — "after a failed test run, re-localize before regenerating, and never re-run an unaffected downstream stage" — is not semantic at all. It is a finite-state reachability question with a known answer, and forcing the model to re-derive it on every turn is a tax that produces only regression toward entropy. The harness knows the process. Piper should not be asked to remember it. **D/L invariant.** Every element of this component is classified into one of two columns: **[D]** — deterministic software running on CPU — or **[L]** — a learned model. The structural invariant that governs the entire design, and that every subsequent section is an elaboration of, is: > **the L column contains at most one entry.** The workflow **control plane** — the phase graph of states, legal transitions, gate predicates, per-state tool permissions, artifact-freshness and invalidation tracking, and retry/rollback/termination edges — is fully deterministic software on CPU [D], with zero learned entries. The single [L] entry is the **semantic judgment inside a state**: bounded reasoning and action within that state's permitted toolset. And **an empty L column is a permitted, correct state** — a purely deterministic state or gate (a syntax check, a test run, a freshness recomputation) executes with no model call at all. One further property distinguishes the phase graph from every other artifact in the harness: it is the one component small enough to **model-check exhaustively** for reachability, safety, and liveness before it runs (§6.4). Every other component's correctness is empirical; the phase graph's correctness is a theorem. The rest of this paper makes the argument concretely. §2 contrasts the open floor of the autonomous agent with the machine of Agentless. §3 specifies the phase graph. §4 adds artifact freshness and the adaptive plan. §5 confines the model to its single, bounded role. §6 assembles the machinery for tuning and *verifying* the controller. §7 closes. --- ## 2. The open floor vs. the machine Before specifying the graph, it is worth establishing that the choice between "declared structure" and "emergent autonomy" is not an aesthetic one. It has been measured, on both sides. ### 2.1 Agentless: declared structure beats autonomy The cleanest existence proof is **Agentless**, by Xia, Deng, Dunn, and Zhang [1]. Its thesis is right there in the name: an automated repair system that deliberately contains *no autonomous agent at all*. It is a fixed, three-phase pipeline — **localize** (hierarchical, tool-guided fault localization), **repair** (generate candidate patches), **validate** (select a patch through reproduction testing) — and at no point does a model decide what phase to be in, what tool to call next, whether to loop, or when to stop. The phases are declared; the transitions are fixed; the evidence (test reproduction) advances the pipeline. The result, published at **FSE 2025** in *Proceedings of the ACM on Software Engineering* (PACMSE Vol. 2, Issue FSE, DOI 10.1145/3715754), is that this fixed pipeline resolves **32.00% of SWE-bench Lite — 96 of 300 instances — at an average cost of $0.70 per instance**. It matched or beat the autonomous agents of its day while using, by design, *zero* agentic workflow reasoning. The number bears stating precisely because it has drifted in secondary sources: the paper's canonical figures are **32.00% (96/300)** and **$0.70**, not the "32.67%" and "$0.68" that appear in some voices, and it is a SWE-bench *Lite* result. A separate figure — **38.8% Verified** — is real but belongs to a *later* SWE-bench Verified leaderboard entry for Agentless (194/500, GPT-4o); it is not a claim of the FSE 2025 paper, and it must not be cited as one. The argument Agentless makes is not "no structure is too little," it is "the *right* structure is a lot." Three phases, each with a fixed method, each terminating deterministically, connected by fixed edges. The absence of an autonomy loop is precisely the feature. This paper generalizes that observation: Agentless proves the point at three states; a production harness needs twenty states and an invalidation lattice (§3–§4) — but the principle is identical. ### 2.2 The cost of the open floor: untraceability The other side of the ledger is what happens when the model *does* own its own process. The autonomous lineage — ReAct's interleaved thought/action/observation loop [3], MetaGPT's role-specialized multi-agent assembly line [4], SWE-agent's agent–computer interface [5], Magentic-One's generalist multi-agent orchestrator with a lead-agent loop [6], MASAI's modular sub-agents [7] — all share one property: the workflow is *emergent*. It is a trajectory through an implicit state space, not a declared graph, and the trajectory is whatever the model happened to produce. The cost of that design was made explicit and measurable by Ceka, Mitchell, Pujar, Buratti, Ramji, Yang, Kaiser, and Ray in their empirical study of automated program repair agents through the lens of **traceability** [2] (ISSTA 2026). Their finding, in essence, is that when the workflow is emergent, you cannot trace *why* the agent did what it did — which step of the repair actually mattered, which decisions were load-bearing, which artifacts causally produced the final patch — because there is no declared structure against which to trace it. Traceability is the property you get for free when the workflow is a graph and lose entirely when it is a trajectory. An emergent workflow is not merely unauditable; it is *un-debuggable*, because there is no place to attach a breakpoint. The phase graph of §3 is, among other things, the answer to the traceability paper: every state, edge, and artifact dependency is declared, so every decision has a name and an address. Rombaut's *Inside the Scaffold* [8] and the CoALA cognitive-architecture framing of Sumers, Yao, Narasimhan, and Griffiths [9] give the same lesson from the taxonomy side: agent architectures differ precisely in *how much* of the decision procedure is scaffolded outside the model versus left inside it. CoALA's separation — a decision procedure (the harness) operating over memory, actions, and a grounding space, with the model as one component of that procedure rather than its owner — is the theoretical statement of what this paper implements. The open floor and the machine are not two points on a spectrum of "model intelligence"; they are two answers to a single question: *where does the decision procedure live?* This paper's answer is that it lives in software, and the model is an instrument it wields. --- ## 3. The phase graph (D) The control plane is a finite graph. This section specifies it precisely, because precision is the entire point: every property this component needs — traceability, model-checkability, invalidation, retry — follows from the graph being *explicit*. ### 3.1 States, legal transitions, and terminal outcomes A **state** is a named phase of the workflow, each one corresponding to a component the harness already owns. The canonical set, in dependency order, is: `INIT`, `RECONNAISSANCE` (repository manifest and context retrieval), `LOCALIZE` (fault localization), `IMPACT` (dependency impact analysis), `PLAN` (task decomposition), `GENERATE` (patch/code generation), `EDIT` (the editing mechanism), `EXECUTE` (code execution), `TRACE` (runtime instrumentation), `DEBUG` (error interpretation), `REPAIR` (iterative repair), `REFLECT` (post-failure reflection), `CANDIDATES` (competing-hypothesis generation), `TEST` (test execution), `VALIDATE` (patch acceptance), `REGRESSION` (regression protection), `MEMORIZE` (episodic memory write), and `REVIEW` (the independent reviewer). Two states are terminal: `TERMINAL_ACCEPT` and `TERMINAL_REJECT`. A **legal transition** is an enumerated edge in the graph. The transition relation is declared exhaustively — the set of `(state, state)` pairs is written down, and any pair *not* written down is not expressible. There is no "the model may go anywhere" escape clause; the transition function is total and closed. The terminal states are sinks: no edge leaves `TERMINAL_ACCEPT` or `TERMINAL_REJECT`. The classical prior here is van der Aalst's work on workflow management. *The Application of Petri Nets to Workflow Management* [10] established that a business process is best modeled as a **Petri net** — places, transitions, tokens — with a distinguished start and end, where the correctness properties (soundness: every run terminates in the end state; no dead tasks; no livelocks) are *decidable* properties of the net. The later *Workflow Patterns* survey [11] catalogued the control-flow idioms — sequence, parallel split, exclusive choice, simple merge, cancellation, deferred choice, arbitrary cycles — that recur across real processes. The phase graph is exactly such a workflow net, with two refinements modern systems require: its transitions are guarded by *data conditions* (§3.2) rather than pure control flow, and its tokens are *typed artifacts* (§4) rather than anonymous marks. ### 3.2 Gate predicates: evidence-driven, harness-executed Every transition is guarded by a **gate predicate** — a boolean condition over *artifacts*, evaluated by the harness, never by the model. The canonical form is a conjunction over artifact existence and threshold tests, for example: > `LocalizationResult exists AND top-candidate confidence > threshold` The predicate names an artifact (`LocalizationResult`), asserts it exists, and tests a property of it against a threshold. Three properties make it a gate rather than a suggestion: - **It is evidence-driven.** The predicate reads an artifact the harness produced and stored, not a claim the model made in prose. "The model says it localized the fault" is not evidence; "a `LocalizationResult` record with a top candidate and a confidence is present" is evidence. The gate checks the latter. - **It is harness-executed.** The predicate is evaluated by deterministic code at the moment the transition is considered. The model never evaluates its own gate; indeed the model never *sees* the gate. The model produces output inside a state; the harness decides whether that output opened the door to the next state. - **It is falsifiable and inspectable.** Because the predicate is a deterministic function of stored artifacts, the answer to "why did the workflow leave `LOCALIZE`?" is always "because this predicate was true over these artifacts," and that answer can be logged, replayed, and — in a debugging context — stepped through. The gate is the mechanism by which "deterministic evidence advances the workflow whenever possible" becomes an actual property of the system rather than a slogan. ### 3.3 Per-state tool permissions Each state carries a **tool allowlist**: the exact set of tools callable from within that state. The `EXECUTE` state may call the sandbox executor; it may not call the patch generator. The `GENERATE` state may call retrieval tools; it may not call the test runner (it has nothing validated to test). A model operating inside a state can invoke *any* tool on that state's list and *no* tool off it; an off-list invocation is not routed to the tool at all — it is rejected at the boundary as an `ILLEGAL_TOOL` event. Tool choice, like workflow choice, is therefore not a model decision; it is a *state property*. The model's freedom is real but always scoped to the room it is standing in. ### 3.4 Failure, re-entry, and termination as first-class edges In an emergent workflow, failure is an exception — something the model must notice and react to, or fail to notice and corrupt. In the phase graph, failure is an *edge*. Three classes of non-happy-path edges are declared alongside the happy path: - **Retry edges** — loops within a state or between a state and its immediate repair predecessor. `TEST → REPAIR → EDIT → EXECUTE → TEST` is the canonical inner cycle; a retry edge is taken when the gate predicate at the head of the cycle is still false but a bounded retry budget remains. - **Rollback edges** — edges that return to an earlier *verified* state, carrying its preserved artifacts forward. When `VALIDATE` fails in a way that implicates the diagnosis rather than the patch, the rollback edge returns to `LOCALIZE` — but, critically, it returns with the repository manifest and localization artifacts still **VALID** (§4.2), so the recomputation is scoped to what actually changed. - **Termination edges** — edges to `TERMINAL_REJECT` (and their variants: out-of-budget, contradiction-in-specification, unrecoverable-sandbox-failure). Termination is a *decision the graph makes*, on declared evidence, never a decision the model makes or forgets to make. The key property, repeated from §1, is **preserve verified upstream state across retries**: a retry or rollback never invalidates an upstream artifact that the failure did not touch. The graph's edges carry typed artifacts, and only the downstream of a change is recomputed. That is the subject of §4. ### 3.5 This layer is [D], and the L column is empty here Every element of §3 — the state set, the transition relation, the gate predicates, the tool allowlists, the retry/rollback/termination edges, the artifact registry — is deterministic software on CPU. No learned model is consulted to advance a token through the graph, to evaluate a gate, to enforce a tool boundary, or to choose an edge. Recapitulating the invariant: > **the L column contains at most one entry.** And at this layer it is exactly zero. **An empty L column is a permitted, correct state** — and it is the *common* state, not the exceptional one. A syntax-check gate between `EDIT` and `EXECUTE` runs with no model call; a freshness recomputation after a diagnosis change (§4.2) runs with no model call; a bounded retry that re-enters `TEST` runs its transition machinery with no model call. The model is *not* the engine of the workflow. It is a called function. --- ## 4. Artifact freshness and the adaptive plan (D) The phase graph describes *which* state comes next. It does not, by itself, describe *what work* the graph should avoid redoing. That is the second half of the control plane: the artifact-dependency lattice, whose job is to make new evidence invalidate and recompute **only the affected downstream work**. ### 4.1 CodePlan: dependency-driven, adaptive work creation **CodePlan**, by Bairi, Sonwane, Kanade, Vageesh, Iyer, Parthasarathy, Rajamani, Ashok, and Shet [12] (FSE 2024, DOI 10.1145/3643757), is the prior that most directly informs this half. CodePlan addresses repository-level coding — edits that span many files — not by emitting one giant patch, but by *planning*: it synthesizes a chain of code edits with inter-file **dependencies**, feeds each edit to an LLM, and then **adaptively** analyzes the result of each edit against the plan, updating the plan's downstream steps when an edit diverges from what the plan assumed. The tasks it handles are genuinely wide: the paper reports edits spanning **between 2 and 97 files**, and it reports **5 of 6 repositories** passing validity checks (the "5 of 7" figure that has drifted in some voices is wrong — the paper says 5 of 6; the correct preprint is arXiv:2309.12499, not the transposed 2402.01712, which resolves to an unrelated paper). The load-bearing ideas for this component are two. First, **work is a plan over artifacts with dependencies** — an edit to file A that changes a signature invalidates the planned edit to file B, and the plan must know that. Second, the plan is **adaptive**: it is not a static schedule executed blindly; it is a structure that re-plans when evidence (the result of an edit) contradicts an assumption. In our terms: CodePlan is the argument that the *plan* is a first-class, dependency-aware artifact maintained by the harness, not a thought the model had once and then abandoned. ### 4.2 Invalidation dependencies: the freshness lattice The harness formalizes CodePlan's insight as a **freshness lattice** over its typed artifacts. Every artifact — `RepoManifest`, `LocalizationResult`, `Diagnosis`, `Plan`, `Patch`, `Review`, `ValidationResult` — carries a freshness status: **VALID** or **STALE**. A dependency relation records which artifacts are downstream of which, and a change propagates staleness *downstream only*. The canonical example, stated as a rule: > **Diagnosis changes → Patch / Review / Validation become STALE; RepoManifest / Localization stay VALID.** Read it as an arrow, not a sentence. When a new failure trace forces the `Diagnosis` to be revised, the artifacts that were computed *from* the diagnosis — the patch, the review of that patch, the validation of that patch — are marked STALE and must be recomputed. The artifacts that the diagnosis was computed *from* — the repository manifest and the fault localization — are upstream, were not touched by the revision, and remain VALID. This is the precise mechanism by which "new evidence invalidates and recomputes only affected downstream work" is enforced: staleness is a directed, transitive property along the dependency edges, and recomputation is triggered *only* for STALE nodes. Nothing upstream is ever re-run because something downstream changed; that would be recomputing a function whose inputs did not change. The recomputation itself is deterministic software [D]. Marking nodes stale, topologically ordering the recomputation, and re-running the affected states' deterministic gates are all CPU operations. Only when a recomputation reaches a state whose *content* requires a semantic judgment does the [L] column get its single entry (§5). ### 4.3 Runtime-Structured Task Decomposition: retry what failed, not the whole The freshness lattice tells us *what* is stale; the second half of this section tells us *how finely* to slice the work so that a failure is cheap. **Runtime-Structured Task Decomposition**, by Asthana, Zhang, DeLuca, Patel, and Mahindru [13] (arXiv:2605.15425, 2026; an arXiv preprint with no peer-reviewed venue as of this writing), measures exactly the tradeoff this component cares about. It compares three ways of decomposing an agentic coding task: **monolithic** (one undivided prompt), **static** (decomposition fixed in advance), and **runtime-structured** (decomposition discovered at runtime from what actually needs doing). The abstract's numbers are precise and worth quoting exactly: monolithic decomposition costs **904±17** tokens, static decomposition **1632±145** tokens, and runtime-structured decomposition **436±132** tokens — and, the headline, runtime-structured decomposition achieves **up to 51.7% lower retry cost than monolithic and 73.2% lower than static decomposition**. The reason is the whole point of this section: when a runtime-structured task fails, the harness re-runs **only the failed subtask**, because the decomposition makes the failure's blast radius local. A monolithic task, by contrast, must be re-run in full — every token, including the tokens that were demonstrably correct the first time. Static decomposition fails differently: it slices on *a priori* structure, which rarely matches the structure of the actual failure, so it spends tokens re-running subtasks that the failure did not implicate. Runtime structure is the empirical argument for §4.2's directed staleness: the finer the dependency lattice, the smaller the retry unit, and the lower the retry cost. The two halves of the control plane — *which state comes next* (§3) and *what must be recomputed* (§4) — are one machine viewed from two angles, and both are [D]. --- ## 5. The single L entry: semantic judgment inside states Everything so far has been about removing the model from the parts of the job it should never have owned. This section is about the part it *should* own — and about keeping that part strictly bounded. ### 5.1 StateFlow: separate process grounding from problem solving **StateFlow**, by Wu, Yue, Zhang, Wang, and Wu [14] (COLM 2024, arXiv:2403.11322), is the cleanest empirical statement of the division this component implements. Its central idea is to separate **process grounding** from **problem solving**: a state machine — built from the initial environment state, with each state holding the LLM's sub-problem to solve, the action space available, and the transition conditions — grounds the *process*, while the LLM solves the *problem* inside each state. The measured result, quoted from the abstract: StateFlow achieves **13% higher success rate than ReAct on InterCode SQL at 5× less cost**, and **28% higher success rate than ReAct on ALFWorld at 3× less cost** (and it composes with Reflexion). Two facts about this result matter. First, the comparison is *against ReAct* — the canonical open-floor agent — and StateFlow wins on **both** success rate **and** cost, on both domains. The state machine is not a tax paid for safety; it is a *performance gain*, because the model spends its budget on the problem instead of on re-deriving the process. Second, the venue is **COLM 2024** (arXiv:2403.11322) — not a NeurIPS workshop — and this paper cites the target StateFlow and no other: no collision of that name is invoked here. ### 5.2 ReAct as the bounded-action-room privilege The model is not forbidden from *thinking and acting in alternation* — ReAct's interleaved Thought→Action→Observation loop [3] is a genuine contribution and is kept, but demoted. Inside a state, the model may freely interleave reasoning and action *within that state's tool allowlist*: in `LOCALIZE` it may think, probe the code graph, read a trace, think again, and re-probe — as many times as the state's budget allows. What it may **never** do is *invent a transition*. A ReAct-style trajectory that tries to leave the state — that, for example, attempts to call a `GENERATE`-state tool while still in `LOCALIZE` — is not honored, not interpreted, not "helpfully" routed; it is rejected as `ILLEGAL_TRANSITION`, and the harness advances (or does not advance) according to the graph and its gates alone. The phrase deserves the emphasis: **the model never invents a transition.** Every edge in the graph is declared (§3.1); every gate is harness-executed (§3.2). The model's freedom is entirely *inside* the state — an unbounded action room scoped to a bounded toolset — and entirely *absent* at the boundary. This is what "reserve LLM calls for semantic judgments within states" means operationally: the LLM call is the semantic judgment (and its bounded action sequence) that *constitutes* the state's work, and nothing more. ### 5.3 The invariant, at its tightest Recapitulating the invariant with the division now fully drawn: > **the L column contains at most one entry.** The control plane — states, transitions, gates, tool permissions, freshness, invalidation, retry, rollback, termination — is [D], zero learned entries. The single [L] entry is the **semantic judgment inside a state**: one bounded model call, or a short bounded sequence of calls, each producing the typed output that state's schema demands, and each exercising only that state's toolset. When a state is purely deterministic — a syntax check, a test run, a freshness recomputation, a topological re-order — the L column is empty, and **an empty L column is a permitted, correct state.** The model is, in CoALA's terms [9], a component of the decision procedure; it is never the decision procedure. (Tree-search variants such as LATS [15] — which searches over reasoning/acting paths — sit comfortably *inside* this picture: they are controlled-search strategies over a state's bounded action space, still gated and still scoped by the graph, not a license for the model to own its own process.) --- ## 6. The tunable and verifiable controller The graph is declared, but it must be *designed*, *tuned*, and *verified*. This section assembles the machinery for all three, with one hard rule throughout: the controller is tuned and verified **offline**, before it runs, never by the model at runtime. A model that can edit its own state machine at runtime has re-imported the open floor through the back door. ### 6.1 The tunable workflow: AFlow, GPTSwarm, ADAS, DSPy The design question — what should the graph look like? — is itself a search problem, and the recent literature has turned it into a *mechanical* one. **AFlow**, by Zhang, Xiang, Yu, Teng, Chen, Chen, Zhuge, Cheng, Hong, Wang, Zheng, Liu, Luo, and Wu [16] (ICLR 2025, oral), reformulates workflow optimization as search over **code-represented workflows** — graphs whose nodes are LLM-invoking operations and whose edges are data flow — and optimizes them with **Monte Carlo Tree Search**. The result, quoted from the abstract: a **5.7% average improvement** over state-of-the-art baselines across six benchmarks, and the enabling finding that **smaller models, given a well-searched workflow, can outperform GPT-4o at 4.55% of its inference cost**. The lesson for this component is that the graph is a *searchable artifact*: the workflow's shape is not a matter of taste but of measured performance, and it can be optimized the same way one optimizes any other code. **GPTSwarm**, by Zhuge, Wang, Kirsch, Faccio, Khizbullin, and Schmidhuber [17] (ICML 2024, PMLR v235; the arXiv v1 title is "Language Agents as Optimizable Graphs," the camera-ready adds the "GPTSwarm:" prefix), makes the same move from the graph-theoretic side: agents are **computational graphs** (nodes are operations, edges are information flow), and the graph is optimized by two operators — **node optimization** (refining a node's prompt) and **edge optimization** (changing the graph's *connectivity*, i.e., the workflow itself). The edge optimizer is the deep point: it treats *the transitions* as the thing to learn, which is exactly the layer this component declares and then tunes offline. **ADAS (Automated Design of Agentic Systems)**, by Hu, Lu, and Clune [18] (ICLR 2025), goes one level up: a **meta agent** writes the agent — searches over *programs* defining agentic systems, against an archive of discovered designs, and the best-discovered agents transfer across domains and models. It is the strongest statement of the principle this section enforces: the agent's *structure* is itself a designed, versioned, tested artifact, produced by a search loop at design time — not improvised by the deployed agent at runtime. **DSPy**, by Khattab, Singhvi, Maheshwari, Zhang, Santhanam, Vardhamanan, Haq, Sharma, Joshi, Moazam, Miller, Zaharia, and Potts [19] (ICLR 2024), contributes the compile-time discipline: pipelines are **declarative modules**, and a **compiler** optimizes the pipeline against a metric. Its relevance is the verb "compile." A DSPy pipeline is written declaratively and *compiled* into its operational form; the model never re-decides its own pipeline structure at inference time. This is the exact posture the phase graph takes toward the workflow: declare it, compile/tune it offline, freeze it, and run it. ### 6.2 Runtime enforcement: AgentSpec Tuning is offline; *enforcement* is online. **AgentSpec**, by Wang, Poskitt, and Sun [20] (**ICSE 2026**; the "2025" in some attributions is the arXiv year, not the venue), specifies exactly the enforcement layer the phase graph needs. It gives a domain-specific language for **runtime enforcement of LLM-agent behavior**: structured rules of the form **trigger → predicate → enforcement**, checked at runtime against the agent's actual behavior. Its enforcement actions are four, and they must be named precisely because they are the deterministic teeth of the whole design: **`stop`** (block the action), **`user_inspection`** (require human review), **`llm_self_examine`** (force a self-reflection pass), and **`invoke_action`** (run a designated fallback action). (A three-action paraphrase — "block / require-confirmation / invoke-fallback" — omits `llm_self_examine` and flattens the semantics; the DSL has four.) AgentSpec maps onto §3.2–§3.3 nearly one-to-one: the **trigger** is a gate predicate, the **predicate** is the condition on artifacts, and the **enforcement** is the deterministic action the harness takes (a refused transition, a forced review, a scoped self-examination, a fallback invocation). The lesson is that a declared workflow is only as safe as its *enforcement* is mechanical — and enforcement is mechanical only when the rules are checked by deterministic code against the agent's observable behavior, never left to the agent's own compliance. ### 6.3 Practitioner context (explicitly non-citational) For completeness and honesty, the practitioner landscape is noted here and deliberately *not* cited as research. **LangGraph** (a LangChain library for graph-based stateful agents) and **BPMN 2.0** (an OMG standard, also ISO/IEC 19510:2013, for business process modeling) are the two mainstream artifacts that converge on the same idea from industry — graphs over states and transitions — and the Anthropic engineering post "Building Effective Agents" (December 2024) is a widely read practitioner articulation of the "workflows vs. agents" distinction. None of these is a peer-reviewed paper, and none is treated as one; they appear nowhere in the reference list. ### 6.4 The model-checking superpower The final property is the one that makes this component *categorically* different from its twenty-two predecessors, and it is the oldest idea in the paper. Clarke, Emerson, and Sistla, in *Automatic verification of finite-state concurrent systems using temporal logic specifications* [21] (ACM TOPLAS 8(2):244–263, April 1986, DOI 10.1145/5397.5399), established that a finite-state system's correctness against temporal-logic specifications — **reachability, safety, liveness** — is mechanically decidable: model checking. (The third author of this paper is A. P. **Sistla**; the often-conflated name **Sifakis** was Clarke and Emerson's co-recipient of the 2007 Turing Award for model checking, but Sifakis is not an author of this 1986 paper.) The phase graph is finite, small, and total. That means it is **the one component small enough to model-check exhaustively** before it ever runs. Reachability — "can `TERMINAL_REJECT` be reached from `INIT` on some artifact valuation?" (it must be, or the harness can hang); safety — "can the graph ever enter `GENERATE` without a VALID `Diagnosis`?" (it must not); liveness — "does every non-terminal state have a path to a terminal state?" (it must, or a live-lock exists). Each of these is a query over a handful of states and edges, answered by a model checker in milliseconds, *not* by running the harness and hoping. Every other component in the harness is verified empirically — by tests, by traces, by counterfactual execution. The workflow is verified *by proof*. That is the concrete payoff of making the control plane a deterministic finite graph: the one thing that most deserves a guarantee is the one thing that can actually get one. --- ## 7. Conclusion The coding harness's twenty-third component is the one that turns twenty-two capabilities into a single machine — and the argument of this paper is that the machine's shape must be declared, not discovered. **The coding workflow should be an executable, evidence-gated state machine rather than an emergent LLM trajectory: define explicit states, legal transitions, permitted tools, input/output schemas, entry and exit conditions, retry and rollback paths, and terminal outcomes; let deterministic evidence advance the workflow whenever possible; allow adaptive plan nodes and branches inside controlled states; track artifact dependencies so new evidence invalidates and recomputes only affected downstream work; preserve verified upstream state across retries; and reserve LLM calls for semantic judgments within states rather than asking the model to manage its own process.** **Piper should solve the coding problem. She should not also have to remember how software development is supposed to work. The harness already knows that.** The design reduces to one structural invariant, stated once more: > **the L column contains at most one entry.** The workflow control plane — the phase graph of states, legal transitions, gate predicates, per-state tool permissions, artifact-freshness and invalidation tracking, and retry/rollback/termination edges — is fully deterministic software on CPU [D], with zero learned entries. The single [L] entry is the semantic judgment inside a state: bounded reasoning and action within that state's allowed toolset. And **an empty L column is a permitted, correct state** — a syntax check, a test run, or a freshness recomputation advances the workflow with no model call at all. Agentless showed that three declared states beat an open loop on SWE-bench Lite [1]; StateFlow showed that a grounded state machine beats ReAct on success *and* cost [14]; CodePlan and Runtime-Structured decomposition showed that a dependency-aware, adaptively sliced plan makes failure cheap and local [12, 13]; and the AFlow/ADAS/GPTSwarm/DSPy line showed that the graph itself can be searched, tuned, and compiled — offline [16–19]. AgentSpec gave the enforcement teeth [20], and Clarke, Emerson, and Sistla gave the guarantee [21]: because the phase graph is finite and small, its reachability, safety, and liveness can be *proven* before it runs. The model's job is the problem. The graph's job is the process. And the harness — not Piper, not the model — knows how software development is supposed to work. --- ## References [1] Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, and Lingming Zhang. "Demystifying LLM-Based Software Engineering Agents." In *Proceedings of the ACM on Software Engineering* (PACMSE), Vol. 2, Issue FSE (FSE 2025). DOI: 10.1145/3715754. arXiv:2407.01489. [2] Ira Ceka, Hailie Mitchell, Saurabh Pujar, Luca Buratti, Shyam Ramji, Junfeng Yang, Gail Kaiser, and Baishakhi Ray. "Understanding Automated Program Repair Agents Through the Lens of Traceability: An Empirical Study." In *Proceedings of the ACM SIGSOFT International Symposium on Software Testing and Analysis* (ISSTA 2026). arXiv:2506.08311. [3] Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. "ReAct: Synergizing Reasoning and Acting in Language Models." In *The Eleventh International Conference on Learning Representations* (ICLR 2023). arXiv:2210.03629. [4] Sirui Hong, Mingchen Zhuge, Jonathan Chen, Xiawu Zheng, Yuheng Cheng, Ceyao Zhang, Jinlin Wang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, Chenyu Ran, Lingfeng Xiao, Chenglin Wu, and Jürgen Schmidhuber. "MetaGPT: Meta Programming for a Multi-Agent Collaborative Framework." In *The Twelfth International Conference on Learning Representations* (ICLR 2024). arXiv:2308.00352. [5] John Yang, Carlos E. Jimenez, Alexander Wettig, Kilian Lieret, Shunyu Yao, Karthik Narasimhan, and Ofir Press. "SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering." arXiv:2405.15793, 2024. [6] Adam Fourney, Gagan Bansal, Hussein Mozannar, Cheng Tan, Eduardo Salinas, Erkang Zhu, Friederike Niedtner, Grace Proebsting, Griffin Bassman, Jack Gerrits, Jacob Alber, Peter Chang, Ricky Loynd, Robert West, Victor Dibia, Ahmed Awadallah, Ece Kamar, Rafah Hosn, and Saleema Amershi. "Magentic-One: A Generalist Multi-Agent System for Solving Complex Tasks." arXiv:2411.04468, 2024. [7] Daman Arora, Atharv Sonwane, Nalin Wadhwa, Abhav Mehrotra, Saiteja Utpala, Ramakrishna Bairi, Aditya Kanade, and Nagarajan Natarajan. "MASAI: Modular Architecture for Software-engineering AI Agents." arXiv:2406.11638, 2024. (CoRR preprint; no formal venue.) [8] Benjamin Rombaut. "Inside the Scaffold: A Source-Code Taxonomy of Coding Agent Architectures." arXiv:2604.03515, 2026. [9] Theodore R. Sumers, Shunyu Yao, Karthik Narasimhan, and Thomas L. Griffiths. "Cognitive Architectures for Language Agents." *Transactions on Machine Learning Research* (TMLR). arXiv:2309.02427. [10] W. M. P. van der Aalst. "The Application of Petri Nets to Workflow Management." *Journal of Circuits, Systems and Computers*, Vol. 8, No. 1, pp. 21–66, February 1998. DOI: 10.1142/S0218126698000043. [11] W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kiepuszewski, and A. P. Barros. "Workflow Patterns." *Distributed and Parallel Databases*, Vol. 14, No. 1, pp. 5–51, July 2003. DOI: 10.1023/A:1022883727209. [12] Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, D. C. Vageesh, Arun Iyer, Suresh Parthasarathy, Sriram K. Rajamani, B. Ashok, and Shashank Shet. "CodePlan: Repository-Level Coding using LLMs and Planning." In *Proceedings of the ACM on Software Engineering* (PACMSE), FSE 2024. DOI: 10.1145/3643757. arXiv:2309.12499. [13] Shubhi Asthana, Bing Zhang, Chad DeLuca, Hima Patel, and Ruchi Mahindru. "Runtime-Structured Task Decomposition for Agentic Coding Systems." arXiv:2605.15425, 2026. (arXiv preprint; no peer-reviewed venue.) [14] Yiran Wu, Tianwei Yue, Shaokun Zhang, Chi Wang, and Qingyun Wu. "StateFlow: Enhancing LLM Task-Solving through State-Driven Workflows." In *First Conference on Language Modeling* (COLM 2024). arXiv:2403.11322. [15] Andy Zhou, Kai Yan, Michal Shlapentokh-Rothman, Haohan Wang, and Yu-Xiong Wang. "Language Agent Tree Search Unifies Reasoning, Acting, and Planning in Language Models." In *Proceedings of the 41st International Conference on Machine Learning* (ICML 2024). arXiv:2310.04406. [16] Jiayi Zhang, Jinyu Xiang, Zhaoyang Yu, Fengwei Teng, Xionghui Chen, Jiaqi Chen, Mingchen Zhuge, Xin Cheng, Sirui Hong, Jinlin Wang, Bingnan Zheng, Bang Liu, Yuyu Luo, and Chenglin Wu. "AFlow: Automating Agentic Workflow Generation." In *The Thirteenth International Conference on Learning Representations* (ICLR 2025), oral. arXiv:2410.10762. [17] Mingchen Zhuge, Wenyi Wang, Louis Kirsch, Francesco Faccio, Dmitrii Khizbullin, and Jürgen Schmidhuber. "GPTSwarm: Language Agents as Optimizable Graphs." In *Proceedings of the 41st International Conference on Machine Learning* (ICML 2024), PMLR v235. arXiv:2402.16823. [18] Shengran Hu, Cong Lu, and Jeff Clune. "Automated Design of Agentic Systems." In *The Thirteenth International Conference on Learning Representations* (ICLR 2025). arXiv:2408.08435. [19] Omar Khattab, Arnav Singhvi, Paridhi Maheshwari, Zhiyuan Zhang, Keshav Santhanam, Sri Vardhamanan, Saiful Haq, Ashutosh Sharma, Thomas T. Joshi, Hanna Moazam, Heather Miller, Matei Zaharia, and Christopher Potts. "DSPy: Compiling Declarative Language Model Calls into Self-Improving Pipelines." In *The Twelfth International Conference on Learning Representations* (ICLR 2024). arXiv:2310.03714. [20] Haoyu Wang, Christopher M. Poskitt, and Jun Sun. "AgentSpec: Customizable Runtime Enforcement for Safe and Reliable LLM Agents." In *Proceedings of the 48th International Conference on Software Engineering* (ICSE 2026). arXiv:2503.18666. [21] E. M. Clarke, E. A. Emerson, and A. P. Sistla. "Automatic Verification of Finite-State Concurrent Systems Using Temporal Logic Specifications." *ACM Transactions on Programming Languages and Systems*, Vol. 8, No. 2, pp. 244–263, April 1986. DOI: 10.1145/5397.5399.