A long-running agent is a regression manager

I will call this fictional repository-agent scenario Patchwork; it was created as a teaching example to keep those dependencies concrete. The central idea I want to test is that a long-running agent is managing both a changing dependency frontier—the work whose prerequisites now hold—and a growing regression suite that keeps earlier successes from breaking. More context, more retries, or another worker may help it operate, but none of those mechanisms defines what is newly possible or what must remain true.

LoopsBench v2↗ makes this problem unusually inspectable in one benchmark. Its 112 coding tasks span eight programming languages and nine domains and contain more than 5,300 development units. Each task is represented as a directed acyclic graph, or DAG, whose nodes are separately testable units and whose edges encode source-evidenced prerequisites. Here “source-evidenced” has a concrete benchmark meaning: the authors' task-construction guide↗ requires a real source repository and base revision, an explicit unit plan, dependency evidence for each edge, maintainer review, and provenance for the gold patch—the reference implementation must be traceable to the named source revision. The benchmark DAG is curated from that task evidence; it is not recovered from the evaluated agent's prose. The evaluation runtime releases tests along the ready frontier: a unit becomes ready when its predecessors have passed. Once a node passes, its tests remain active as regression obligations while later nodes are attempted.

The paper's results are sobering within that exact setup. Its strongest reported model-and-loop configuration resolved 25% of tasks. Recorded plans recovered only part of that curated benchmark DAG, and the evaluated runs still recorded regressions. The DAG is explicitly an evaluation contract, not a claim that real development is always monotonic or that the recovered order is uniquely optimal.

What the source shows is that this benchmark can expose ordering, partial planning, and backsliding that a terminal pass rate hides. The synthesis is mine: sustained agent control should treat “done” nodes as active invariants, not historical chat. At any checkpoint, the controller needs at least four distinct sets:

• obligations already satisfied and still enforced;
• work ready because its prerequisites are satisfied;
• blocked work with named unmet dependencies;
• applied work whose earlier verification became stale and must be established again.

The sets are coupled. When the parser regresses, the emitter moves from ready to blocked. The formatter's applied edit still exists, but its previously verified status becomes stale until the parser is restored and the formatter checks are rerun; it does not simply re-enter the ready set. Work downstream of either the blocked emitter or stale formatter also remains blocked by a named unmet prerequisite. A credible progress record therefore cannot just count completed subtasks. It must say which observations established each completion, which later work depended on it, and which checks must be rerun after a relevant change.

Anthropic's first-party agent-evaluation guidance↗ offers useful production vocabulary for the second half of this idea. It distinguishes capability evals—what difficult work can the agent do?—from regression evals—does it still handle work it previously handled? The post is not evidence for the LoopsBench results or for my controller design. It supports the narrower operational distinction between expanding capability and protecting established behavior.

There is a fair countercase. A bounded one-shot task with no meaningful internal dependencies, no durable intermediate state, and no future edit that can invalidate earlier work may not need a frontier or an accumulating regression manager. A single environment check at the end can be enough. Adding a DAG and continuous regression machinery there would create ceremony without buying control.

What this does not prove: LoopsBench v2 does not establish that every software task has a recoverable DAG, that its source-derived edges are the only valid dependencies, or that a regression-aware controller will solve long-horizon work. Patchwork's parser example is an original teaching construction, not a LoopsBench task or reported experiment. The claim is narrower: when later work depends on earlier verified behavior, duration creates obligations that turn count alone cannot represent.

In your longest agent workflow, which “completed” step is still being enforced as a live obligation—and what downstream state changes when that step regresses?