From Agent Loops to Structured Graphs:A Scheduler-Theoretic Framework for LLM Agent Execution

Motivation

• Agent Loops are single-ready-unit schedulers whose opaque LLM decisions leave dependencies unverifiable, recovery unbounded, and execution plans difficult to audit.In a survey of 70 open-source projects, 42 (60%) adopted the Agent Loop pattern, while recent enhancements did not fundamentally make control flow explicit or execution commitments stable.Source: §1 · pp. 1–2

Framework

• The scheduler-theoretic framework compares Agent Loops and graph executors using ready-set cardinality (|U|) and policy explicitness, while identifying non-deterministic outputs, semantic validation, and reasoning errors as LLM-specific challenges.The formalization builds on classical DAG scheduling literature [Topcuoglu et al., 2002, Cormen et al., 2009].Source: §1 · pp. 2–3

Design proposal

• Graph Harness lifts control flow into an immutable static DAG, separates planning, execution, and recovery, and constrains recovery through strict escalation.The design excludes competitive parallelism, recursive sub-graph expansion, and parent-chain rollback to prioritize controllability, verifiability, and implementability.Source: §1 · p. 3

Contributions

• The paper contributes a four-principle design methodology from 70 surveyed systems and a formal three-layer execution model with immutable plan versioning and termination and soundness guarantees under explicit fairness assumptions.The methodology analyzes trade-offs among controllability, expressiveness, and implementability, including observed failure-loop behavior across orchestration systems.Source: §1 · p. 3

Scope and evaluation

• A seven-group protocol isolates the effects of Gplan, Gscaffold, Ggraph, Gpatch, and Greplan for future empirical validation, but the paper reports no production implementation or empirical results.Internal verification covers consistency and state-machine completeness; engineering details and experimental validation remain outside scope.Source: §1 · p. 3

Motivating example

• In the motivating bug-fix example, Graph Harness reduces execution from 11 serial turns to 6 scheduling rounds by structurally enforcing dependencies and parallelism, whereas recovery remains ad hoc in the Agent Loop.The example assumes the planner identifies all parallel structure, dependencies are known at planning time, and the LLM executes nodes correctly.Source: §1 · p. 3, Figure 1 · p. 4

2.1 Agent Loop Paradigm

• Agent loops dominate production systems, but Graph Harness formalizes their single-ready-unit, LLM-controlled scheduling limitation while restricting expressiveness to improve controllability and verifiability.ReAct [Yao et al., 2023], Chain-of-Thought [Wei et al., 2022], and Plan-and-Solve [Wang et al., 2023] motivate the paradigm; approximately 60% of 70 surveyed projects use iterative tool loops.Source: §2.1 · pp. 4–5

2.2 Plan-Then-Execute and Separated Architectures

• Separated planning systems improve reliability, but TDP [Li et al., 2026] remains sequential and mutable, whereas Graph Harness enables concurrent ready-node dispatch, immutable plan versions, and escalated recovery.TDP reports up to 82% lower token consumption through scoped contexts, while Graph Harness requires retry and local patch before full replanning.Source: §2.2 · p. 5

2.3 LLM-Based Workflow Optimization

• AutoGen [Wu et al., 2023], CrewAI [Moura and crewAI Inc., 2024], and Semantic Kernel [Microsoft, 2023] structure coordination or skill reuse, but Graph Harness adds deterministic scheduling, immutable plans, and formal recovery.These alternatives remain primarily single-ready-unit schedulers with implicit or semi-deterministic policies.Source: §2.3 · pp. 5–6

2.4 Graph-Based Agent Orchestration

• Graph frameworks such as LangGraph [Team, 2024] support parallel execution and flexible runtime modification, whereas Graph Harness prioritizes immutable plans and bounded recovery without claiming empirical superiority.LangGraph uses semi-deterministic routing because conditional edges depend on runtime LLM output; the comparison is structural, not evaluative.Source: §2.4 · pp. 6–7

2.5 Multi-Agent Task Decomposition and Scheduling / 2.6 Structured Execution for Scientific Agents

• Multi-agent systems demonstrate graph-structured coordination, while Graph Harness fixes topology during each plan version, trading runtime adaptability for controllability guarantees.DynTaskMAS [Yu et al., 2025] reports 21–33% lower execution time, and WorfBench [Qiao et al., 2025] finds a 15% sequence-versus-graph planning gap; El Agente Gráfico [Bai et al., 2026] supports structured execution for complex scientific workflows.Source: §2.5 · p. 7, §2.6 · p. 8

2.7 Classical DAG Scheduling

• Graph Harness applies classical list scheduling and topological ordering to LLM execution, while identifying non-deterministic nodes as requiring extensions beyond traditional DAG theory.Its default policy is equivalent to zero-communication-cost list scheduling with a 2 − 1/m approximation ratio for m identical processors when execution times are approximately constant.Source: §2.7 · pp. 8–9

2.8 Workflow Engines: Airflow, Luigi, and Prefect

• Unlike Airflow, Luigi, and Prefect, Graph Harness addresses LLM-specific failures through contract validation, three-level recovery, and separated execution and diagnostic contexts.LLM nodes can hallucinate, misinterpret inputs, and produce different outputs on retries, so infrastructure-oriented crash handling and compile-time type checks are insufficient.Source: §2.8 · p. 9

2.9 Systematic Comparison / 2.10 Positioning

• Graph Harness is positioned as the only surveyed LLM-agent design combining multi-ready-unit scheduling, deterministic policy, immutable plan versions, and bounded recovery for verifiable engineering tasks.LangGraph supplies parallel scheduling, TDP supplies DAG decomposition, and classical engines satisfy structural constraints but lack LLM-specific validation and recovery.Source: §2.10 · p. 10, §2.9 · p. 10

3.1 Execution Systems

• Execution systems are formalized with node states, dependency-derived ready sets, scheduling policies, execution outcomes, and state transitions that recompute eligibility.A node becomes ready only after all predecessors execute; deterministic policies are functions, while nondeterministic policies are relations.Source: §3.1 · pp. 11–12

3.2 Single-Ready-Unit Schedulers

• Agent Loops are nondeterministic single-ready-unit schedulers: each step produces one action, while identical contexts can yield different actions.Parallel tool calls can create multiple ready operations, but the LLM still determines them ad hoc rather than through explicit topology-based scheduling.Source: §3.2 · pp. 12–13

3.3 Multi-Ready-Unit Schedulers

• Multi-ready-unit schedulers have states with more than one eligible node, making policy a genuine choice among topological, priority-based, or parallel dispatch strategies.Graph-based executors operate in this regime, where different policies can produce different traces from the same ready set.Source: §3.3 · p. 13

3.4 The Scheduler Continuum

• The scheduler continuum classifies systems by ready-set cardinality, policy explicitness, and policy determinism, from implicit LLM inference to explicit state-machine control.It is presented as an analytical classification framework rather than a theorem.Source: §3.4 · p. 13
• The framework predicts benefits from multi-ready-unit scheduling, increasing with dependency complexity, and benefits from recovery escalation specifically on failure-prone tasks.These predictions are logical consequences of the model, not empirical findings, and require prototype-based experiments and curated benchmarks.Source: §3.4 · p. 13
• Adding a planner increases policy explicitness but does not change ready-set cardinality; only graph-based execution reaches structurally guaranteed multi-ready-unit scheduling.Figure 2 extends the continuum with Parallel Loop systems, which support |U| ≥1 but retain nondeterministic policies.Source: §3.4 · p. 13, Figure 2 · p. 14

3.5 Why Unification Matters

• The unification framework compares Agent Loops and graph executors by asking whether moving from |U| = 1 to |U| ≥1 with deterministic P improves performance and by how much.It characterizes expressiveness as the range of ready-set configurations and controllability as the functionality of P plus explicitness of S.Source: §3.5 · p. 14
• The framework yields testable hypotheses about graph benefits, complexity effects, and recovery gains, but provides semantic rather than complexity-theoretic guarantees.Formal scheduling complexity, including whether optimal budget-constrained scheduling is NP-hard, remains future work.Source: §3.5 · p. 14

3.6 Worked Example

• The worked DAG contains independent searches, alternative fixes joined by any_of, and documentation parallel to the fix/test path, translating formal scheduling definitions into concrete behavior.The task covers authentication debugging and documentation updates through ten dependency-constrained steps.Source: §3.6 · p. 15

3.6.1 Agent Loop Execution

• The Agent Loop uses implicit dependencies and ad-hoc alternatives, revises its plan after failure, and permits unbounded recovery without structured escalation or auditability.Its growing context drives sequential decisions, including trying patch B only after patch A fails, with no bound, diagnosis, protocol, or plan-version trail.Source: §3.6.1 · pp. 15–16

3.6.2 Graph Harness Execution

• SGH produces ready sets of size 2 for searches and reads, and size 3 for concurrent fixes and documentation, whereas the Agent Loop remains sequential.The DAG exposes independent tasks and parallel execution that the single-ready-unit Agent Loop cannot achieve by design.Source: §3.6 · p. 15, §3.6.2 · p. 16
• Graph Harness encodes “try either patch” through an any_of join, so successful fix B lets the system skip failed fix A without a wasted retry.The transient failure triggers Level 1 recovery, but the satisfied join makes further recovery unnecessary.Source: §3.6.2 · pp. 16–17
• 11 sequential Agent Loop turns become 10 Graph Harness dispatches across 6 rounds, including 4 rounds with parallel dispatches.The example states that wall-clock time is reduced proportionally to available parallelism.Source: §3.6.2 · p. 17

3.7 Planning Failures and Their Consequences

• Missing dependencies trigger runtime contract failures, while spurious dependencies silently reduce parallelism from |U| = 2 to |U| = 1 without affecting correctness.The former prevents corrupt data from proceeding; the latter causes sequential execution and wasted time.Source: §3.7 · p. 17
• Incorrect join semantics can repeatedly retry an infeasible branch, escalate through patch generation, and require full replanning, wasting execution time and tokens.Using all of instead of any of is especially damaging when only one patch is viable.Source: §3.7 · p. 17
• Over-decomposition adds node-level coordination and serialization overhead, whereas under-decomposition loses parallelism and makes error attribution difficult; neither is automatically repaired without replanning.Graph Harness executes each node separately and cannot recover parallelism lost by combining operations.Source: §3.7 · pp. 17–18

3.7.1 Scheduler-Framework Mapping

• The worked example instantiates SGH’s formal scheduler: deterministic dispatch reaches ready sets of 2 and 3, treats any-of alternatives structurally, skips unnecessary recovery, and recomputes progress from DAG state.When fix B succeeds, the transition function cancels fix A and enables testing, without relying on LLM scheduling inference.Source: §3.7.1 · p. 18

4.1 The Trade-off Space

• Graph Harness targets verifiable engineering tasks by favoring controllability over maximal expressiveness, unlike simple Agent Loops and highly expressive graph systems.The survey of 70 systems maps execution patterns to scheduler properties and reports that graph/flow systems combine high expressiveness with lower controllability and greater implementation risk, while Agent Loops lack structural guarantees.Source: §4.1 · p. 19

4.2 Principle 1: Controllability First

• Controllability comes first: uncertain benefits do not justify sacrificing predictability and verifiability, even though parallel races, recursive expansion, and parent-chain rollback are excluded.The survey qualitatively observed failure-loop behavior in 3 of 4 graph/flow projects versus 0 of 7 state-machine projects, but the classification was subjective and not formally quantified.Source: §4.2 · pp. 19–20

4.3 Principle 2: Stable Execution Commitment

• Execution plans remain immutable after validation, making a plan version the minimal accountability unit for debugging.The runtime cannot add or remove nodes, redirect edges, or rewrite the plan during execution; structural changes require a controlled replan that creates a new version, and the supporting observation was manual and may not generalize.Source: §4.3 · p. 20

4.4 Principle 3: Bounded Recovery

• Recovery uses explicit triggers, bounded scope, and a fixed escalation ladder to prevent both infinite retries and premature replanning.An LLM may diagnose failures, but retry, patch, and replan actions are protocol-controlled rather than freely selected by the execution loop.Source: §4.4 · p. 20

4.5 Principle 4: Side-Effect Classification

• Scheduling respects side-effect classifications: high-risk writes, deletions, and notifications cannot be speculatively dispatched in parallel and receive tighter retry budgets.This reduces parallelism for some task structures while preventing safety violations associated with treating irreversible operations like freely retryable reads.Source: §4.5 · pp. 20–21

4.6 Summary of Trade-offs

• Together, these sacrifices define an expressiveness boundary intended for verifiable engineering tasks rather than as a universal design limit.The paper notes that the boundary may be relaxed in future work and discusses it further in Section 10.Source: §4.6 · p. 21

5.1 The Execution Plan as Commitment

• An execution plan assigns node configurations and an output contract to a directed graph whose structure remains immutable throughout each plan version.A different topology requires creating a new plan version through the replan protocol.Source: §5.1 · pp. 21–22
• Plan immutability makes traces attributable to a specific plan version, fixes the ready set, and permits pre-execution validation of structural constraints.The stated checks include cycles, unreachable nodes, and unsatisfiable dependencies.Source: §5.1 · p. 22

5.2 Why a Static DAG?

• The static DAG guarantees acyclic dependencies, finite execution over a fixed node set, and topological scheduling that policy may refine but cannot violate.Acyclicity ensures that some node with satisfied predecessors remains available for progress.Source: §5.2 · p. 22

5.3 Three-Layer Separation

• Three layers assign distinct responsibilities: the planner produces a validated DAG, the runtime executes it and reports failures, and recovery diagnoses failures and selects actions.The runtime does not decide how reported failures are handled, while recovery decisions use diagnostic context separate from runtime execution context.Source: §5.3 · p. 22

5.4 Context Separation

• Execution and diagnostic contexts are disjoint during node execution, with diagnostic information entering execution only through a newly planned version.This prevents failure history from becoming an implicit input that couples recovery decisions to execution logic and weakens predictability and auditability.Source: §5.4 · p. 23

6.1 Node State Machine

• Under finite DAGs, node timeouts, retry budgets, and human-review timeouts guarantee progress and termination with probability 1, with every node eventually reaching a terminal state.Terminal states are absorbing, and the progress guarantee ensures that either a node becomes ready or reaches executed, failed, or cancelled.Source: §6.1 · pp. 23–25
• Contract validation gates execution, but overall correctness remains bounded by validation reliability, especially when semantic validation relies on LLMs.SGH mitigates this validation gap through code-based checks for high-impact nodes, human review, downstream failure detection, and auditability of validation methods.Source: §6.1 · pp. 25–26

6.2 Three-Level Recovery Protocol

• Recovery must exhaust each level before escalation, ensuring least-disruptive actions precede patching and full replanning as the last resort.The API mechanically rejects patch or replan requests that violate the per-node escalation state, while bypassing the API falls outside SGH guarantees.Source: §6.2 · pp. 26–27

6.3 Error Classification and Diagnosis

• A diagnoser maps observed failures to root-cause hypotheses and recovery actions using diagnostic context rather than execution context, preventing reasoning leakage and preserving auditability.Diagnoses include the observed failure, hypothesized cause, recommended action, and diagnostic confidence; the diagnoser may be rule-based or LLM-assisted.Source: §6.3 · p. 27

7.1 Supported Join Modes

• Graph Harness supports all-of and any-of joins, while deliberately excluding a third mode from its current specification.A node enters the ready set only under the selected join mode’s stated completion conditions.Source: §7 · p. 27, §7.1 · p. 27
• All-of waits for every predecessor to succeed; any-of dispatches candidates deterministically, propagates the first success, skips siblings, and fails only if all candidates fail or cancel.Any-of therefore supports alternative-path execution while preserving a fixed dispatch order.Source: §7.1 · p. 27

7.2 Impact on the Ready Set

• All-of keeps a successor pending until every predecessor executes, whereas any-of makes it ready after the first successful candidate and skips the remaining candidates.These modes govern dependency-satisfying and alternative-path execution, respectively.Source: §7.2 · p. 28

7.3 The first of Exclusion

• Graph Harness excludes first-of joins because loser cancellation, commit-point ambiguity, and non-deterministic ready sets require complex compensation and consensus mechanisms.The exclusion is a controllability-first choice, though competitive parallelism remains a possible future extension with an explicit trade-off.Source: §7.3 · p. 28

7.4 Expressiveness Boundary

• The two supported joins and static DAG establish an expressiveness boundary whose expansion would require relaxing design principles and acknowledging controllability trade-offs.Excluded capabilities are tied to specific violations of one or more design principles.Source: §7.4 · pp. 28–29

8 Attributable Experimental Framework

• The framework is a protocol for falsifiable design analysis and future empirical evaluation, not completed experimental validation.Its stated contributions are theoretical framework and design analysis rather than empirical results.Source: §8 · p. 29

8.1 Seven-Group Design

• Seven groups span the scheduler continuum, with adjacent comparisons isolating information, planning, scaffolding, graph scheduling, patch recovery, and replanning effects.The design includes an augmented Agent-Loop baseline and culminates in full three-level recovery; shared tasks, models, tools, timeouts, and budgets support attribution.Source: §8.1 · pp. 29–31

8.2 Gain Decomposition

• Gain decomposition expresses Graph Harness improvements through five attributable components and supports hypothesis tests about which design feature drives performance.The framework warns that additive gains can conflate structural effects with planning × structure interactions, which can be tested across planning-quality levels.Source: §8.2 · p. 31, §8.4 · p. 32

8.3 Task Set Design

• Tasks are stratified by dependency complexity, with simple tasks testing whether Graph Harness’s fixed structural overhead outweighs its benefits.This directly evaluates the fixed-overhead hypothesis and whether the design trade-off requires reevaluation on simple tasks.Source: §8.3 · p. 32

8.4 Evaluation Metrics

• Evaluation covers effectiveness, efficiency, stability, observability, and attribution, including success, runtime, variance, failure localization, and the five gain components.The metrics also include contract satisfaction, redundant steps, failure-loop rate, trace completeness, and repeated-trial behavior.Source: §8.4 · p. 32

9.1 The Scheduler Continuum as a Design Lens

• The scheduler continuum serves as a design lens: |U| and policy explicitness constrain an agent system’s expressiveness, controllability, and implementability.Recent systems converge toward graph execution but generally prioritize expressiveness, whereas SGH adds stable execution commitment and bounded recovery.Source: §9.1 · p. 33

9.2 Relationship to Existing Work

• SGH favors static DAGs, immutable plan versions, and bounded escalation over dynamic adaptability, improving auditability and predictable failure semantics for verifiable engineering tasks.Dynamic graphs are more expressive for emergent structures, but static DAGs integrate more naturally with engineering tooling and expose stable execution records.Source: §9.2 · pp. 33–34

9.3 When Is Static Structure Sufficient?

• Static DAGs are preferable when dependencies and success criteria are articulable before execution, while dynamic graphs or Agent Loops suit exploratory, evolving, and creative tasks.This boundary is a deliberate trade-off: SGH targets verifiable engineering tasks rather than open-ended exploration.Source: §9.3 · p. 34, §9.5 · p. 35, §9.7 · p. 38

9.3.1 The Role of the Planner in Identifying Parallelism

• SGH’s parallelism requires the planner to identify independent sub-tasks; otherwise it degenerates to a single-ready-unit scheduler and retains only recovery, auditability, and context-isolation benefits.Parallelism may come from domain knowledge, LLM inference, or explicit user-provided structure, but these guarantees are not the full structural benefit of parallel execution.Source: §9.3.1 · p. 34, §9.8 · p. 38

9.3.2 Estimating the Prevalence of Parallelism

• Approximately 30–40% of surveyed agent tasks showed natural parallelism, so SGH’s strongest benefits apply to a subset; this estimate is manual and remains unvalidated.The proposed G3-versus-G4 comparison is intended to isolate structural parallelism gains from planning and recovery effects.Source: §9.3.2 · pp. 34–35

9.4 The Recovery Layer as a First-Class Abstraction

• The three-level recovery protocol turns failure handling into a bounded, auditable escalation process and is presented as a portable abstraction for systems vulnerable to failure loops.Its invariant prevents recovery actions from skipping levels, while bounded budgets replace ad-hoc LLM decisions.Source: §9.4 · p. 35

9.5 Limitations and Future Directions

• SGH lacks experimental validation, risks LLM error propagation, has a non-trivial cold-start problem, provides no complexity-theoretic guarantees, and requires approximately 3,300–6,500 lines versus 300–500 for a simple Agent Loop.The implementation estimate excludes tests, documentation, and LLM integration layers, and requires validation through a prototype and curated task benchmark.Source: §9.5 · pp. 35–36

9.6 When the Planner Fails: Incorrect DAGs

• Planner defenses catch structural and contract violations but not strategically poor decompositions; SGH makes planner quality observable and isolated without guaranteeing correctness.Future validation should implement SGH, benchmark at least 50 stratified tasks, and run the seven-group protocol with at least 10 trials per task and group.Source: §9.6 · pp. 37–38, §9.5 · p. 37

10.1 Expressiveness Boundary

• Graph Harness applies to tasks whose dependency structure is articulable before execution, excluding open-ended exploration, evolving goals, and competitive trial-and-error.This boundary defines the class of verifiable engineering tasks supported by the system.Source: §10.1 · p. 40
• It excludes first-of semantics because cancellation requires complex compensation protocols and creates ambiguity about executing slower but potentially higher-quality alternatives.Users can approximate try-all-take-first behavior with all-of parallel execution followed by conditional selection; only 8% of surveyed tasks reportedly require true first-of semantics.Source: §10.1 · p. 40

10.2 Fixed-Overhead Hypothesis

• DAG validation, per-node tracking, and the three-layer protocol may impose unamortized overhead on simple one-to-three-step tasks.H4 predicts higher LLM-call and latency costs than an Agent Loop baseline without proportional success-rate improvement, motivating a possible dual-path design if confirmed.Source: §10.2 · pp. 40–41

10.3 LLM Dependence in Diagnosis and Planning

• Although scheduling policy is removed from the LLM, plan generation and failure diagnosis remain quality bottlenecks that Graph Harness makes observable but does not eliminate.Failures become attributable to incorrect plan versions or diagnoses rather than silently corrupted context.Source: §10.3 · p. 41

10.4 Relationship to Evolutionary Graph Architecture

• An evolutionary graph architecture could add compensated first-of execution, bounded recursive sub-graph expansion, and parent-chain rollback with plan-version inheritance.These relaxations extend competitive parallelism, dynamic decomposition, and hierarchical recovery, respectively, while trading controllability for expressiveness.Source: §10.4 · p. 41

• Graph Harness prioritizes controllability over maximal expressiveness, while keeping its explicit capability boundary relaxable through principled changes to individual design commitments.The paper’s scheduler framework and design principles are theoretical contributions; companion work is planned for prototype validation and evolutionary extensions adding dynamic topology, recursive expansion, and hierarchical recovery.Source: §11 · pp. 41–42
• Graph Harness unifies Agent Loops and graph executors as schedulers distinguished by ready-set cardinality, with Agent Loops satisfying |U| ≤1 and graph executors |U| ≥1.This formalization makes their structural differences precise and supports systematic trade-off analysis.Source: §11 · p. 41
• Its four principles trade competitive parallelism, dynamic plan modification, ad-hoc recovery, and unrestricted dispatch for predictability, auditability, failure-loop prevention, and safety.These trade-offs derive from systematic analysis of 70 existing agent systems.Source: §11 · p. 41
• The seven-group experimental framework decomposes performance gains into planning, scaffold, graph, patch, and replan gains, making the hypothesis “graph structure helps” testable as Ggraph > 0 independently of Gplan.The protocol requires a prototype SGH implementation, which is beyond this position paper’s scope.Source: §11 · pp. 41–42

A.1 Complete State Transition Table

• The complete state transition table enumerates all valid transitions for each node v ∈ V.Source: §A.1 · p. 44, Table 15 · p. 44

A.2 DAG Validation Algorithm

• Plans are rejected unless they pass acyclicity, reachability, join consistency, contract well-formedness, and side-effect consistency checks before execution.Acyclicity is verified with Kahn’s algorithm, and rejected plans require correction before execution begins.Source: §A.2 · pp. 44–45

A.3 Join Semantics: Formal Properties

• Under all-of joins, the ready set is monotonic: executed predecessors can make additional nodes ready but cannot make ready nodes un-ready.Source: §A.3 · p. 45
• Under any-of joins, selecting one candidate removes its siblings from the ready set, producing deliberate non-monotonicity for one-suffices execution.Source: §A.3 · p. 45

A.5 Survey Methodology

• The survey identified 340 unique repositories, removed forks and mirrors, applied relevance and quality filters, yielded 70 open-source LLM agent projects, and classified them across scheduler, planning, recovery, context, and complexity axes.Source: §A.5 · p. 46

A.6 Representative Projects

• Nine representative projects span all five execution categories, multiple programming languages and application domains, while the remaining 61 projects are documented in supplementary material.Source: §A.6 · p. 47, Table 16 · p. 47

A.7 Complete Project List

• The complete 70-project list is organized by category and records each project’s name, GitHub URL, classification, and key characteristics.Source: §A.7 · p. 47

• The survey is not peer-reviewed and should be interpreted as qualitative evidence rather than quantitative proof.Source: §A.4 · p. 45
• Project selection was subjective and not systematically sampled, limiting the survey’s representativeness.Source: §A.4 · p. 45
• Manual inspection of GitHub issues and code means reviewers might disagree on failure-loop behavior, debugging success rates, and other qualitative metrics.Source: §A.4 · p. 45
• Because the survey reflects the field as of April 2026, its findings may not generalize to newer systems.Source: §A.4 · p. 45
• The authors regard patterns such as prevalent Agent Loops and mutable-plan debugging difficulty as meaningful, while proposing more rigorous future survey methodology.Source: §A.4 · p. 45