Long-Running Verification: Convergence Mechanisms for Long-Running AI Agent Tasks
on , tagged translations, ai-agents, ai, processes (share this post, e.g., on Mastodon or on Bluesky)
Over the weekend, I ran two experiments using Claude Code’s /workflows, combined with a series of experiments I’d done using Codex /goal. Looking at both capabilities together feels clearer than looking at either tool in isolation.
With /goal, I ran a nearly 30-hour timetravel-agent in one go: a JavaScript time-travel debugger prototype inspired by Wallaby.js. It already has instrumentation, runtime recording, trace querying, replay, an HTTP service, and a React/Next demo. The other was Claude Code’s dynamic workflows: writing the orchestration logic for parallel subagents into a JavaScript script, then having a local runtime schedule and execute it.
They look like two different kinds of problems. timetravel-agent is a long-running objective; Claude Code workflows are a multi-agent parallel mechanism. But viewed together, they point to the same engineering headache:
Agents can work for a long time, and many can work together—but an engineering system needs to know when it can actually stop.
Bun’s Zig-to-Rust migration has already shown us that agents can participate in system-level, large-scale rewrites; Claude Code’s dynamic workflows put orchestration logic into a JavaScript script, letting multiple subagents work in parallel; /goal lets a task keep pushing forward around completion conditions, crossing the boundary of a single conversation turn.
AI coding is entering the long-task phase. The new question is not whether an agent can keep going, but whether the system can converge after it keeps going.
/goal: Long Tasks Can’t Rely on Continuous Handoffs Alone
I previously ran an experiment with /goal: Have an agent imitate Wallaby.js and implement a JavaScript time-travel debugger. This task is naturally suited to long-running execution—it needs instrumentation, trace recording, state replay, a debugging UI, and test verification.
But the result failed to converge.
The problem is not /goal itself. /goal’s value is letting an agent push forward around an objective and judge whether completion conditions are met after each round. But it is more like a handoff mechanism, not a verification system. It can hand the task off to the next round, yet it cannot prove to the engineering system whether the execution trace is complete, variable states are replayable, branches and exceptions are covered, or whether step forward/backward actually changes snapshots.
So when the goal is simply “implement a time-travel debugger,” the agent easily generates a project that looks finished: structure, UI, README, shallow tests. The problem is that a time-travel debugger’s completion conditions are not in these surface appearances, but in trace, replay, state recovery, and semantic consistency.
When I later reopened the timetravel-agent demo, the problem became even clearer. The UI can already display the compiled artifact, the mapping from source to instrumented output, probe counts, source maps, and integrity status. These are all good entry points for evidence, but they are not yet a complete proof of completion.
This is also why we previously discussed gates in Routa Kanban. A long task cannot have only a linear path from start to finish; it needs gates between key states:
Goal → Plan → Build → Verify → Review → DoneFor timetravel-agent, gates can be broken down more concretely: a Trace Gate checks whether events are complete, a Replay Gate checks whether states can be recovered, a UI Gate checks whether the debugging panel can actually drive problem localization, a Mismatch Gate checks semantic differences between generated code and source code, and an Evidence Gate requires leaving behind reviewable commands, reports, and screenshots.
This way, /goal does not just let the agent keep running; it lets the task flow continuously between gates. /goal solves the handoff problem; the gate solves the convergence problem.
/workflows: After Multi-Agent Parallelism, the Key Is Result Reduction
If /goal exposes the vertical convergence problem of long tasks, then dynamic workflows expose the horizontal reduction problem of parallel tasks.
Claude Code’s dynamic workflows are interesting. They turn the problem of stuffing a long context into a JavaScript orchestration script executed by a runtime in the background, scheduling multiple subagents. The workflow puts the plan into code; the script saves loops, branches, and intermediate results; Claude’s context only receives the final result. It can be used for codebase-wide bug sweeps, 500-file migrations, cross-checked research, and similar tasks.
This change is important.
Task state moves out of the chat window and into script variables, stage outputs, and agent results. Multiple subagents can search, audit, migrate, and verify in parallel, and the workflow synthesizes the results afterward. This is very much like MapReduce in the agent era: First slice the task space, then fan out to workers, then collect findings, then cross-check, and finally reduce into patches, reports, or conclusions.
The most expensive part falls on the reduce.
I previously looked at runtime data from a /deep-research workflow. Taking the Node.js Permission Model research as an example, total tokens were about 3.31M, of which the Verify stage was about 1.76M—more than half. That ratio is interesting. The most expensive part is not Search and Synthesize, but Verify.
A workflow that merely searches and summarizes in parallel does not produce sufficiently trustworthy results. Dozens of subagents running together only expand coverage; without cross-checking, they may simply expand the surface area of error. Only when claims are extracted, evidence is traced, conflicts are merged, and failures are marked does a workflow begin to have engineering value.
The future competition among coding agents will come down to a more concrete question: can worker results be reduced into trustworthy evidence?
Parallelism only expands coverage. Trustworthiness comes from verification relationships.
Long-Running Verification: Turning “Keep Going” into “Continuously Prove”
Put timetravel-agent and Claude Code workflows side by side, and the failure modes of long tasks become very clear.
Vertically, tasks drift. At first we say “implement a time-travel debugger.” As it runs, the goal may become “build a UI”; a while later, it becomes “make the demo page open”; finally the README is written, screenshots are taken, and the project looks like a product—but execution traces, state replay, and semantic consistency have not been proven.
Horizontally, errors spread. Workflows let dozens of subagents work simultaneously, coverage expands rapidly, but without claim extraction, evidence voting, conflict handling, and final reduction, parallelism simply magnifies uncertainty. It looks busy, yet the result is not necessarily more reliable.
The most dangerous place in a long task is here: The agent has not failed—it has swapped the original goal for the easiest current goal; the workflow has not failed either—it has synthesized many local results into an answer that looks complete.
So the engineering focus of a long-running task is not about making the agent work harder or running more sessions. Every segment the task advances must be verifiable. Execution is only the process; convergence is the result. Without verification points, a long task easily becomes long-duration generation; with verification points, it begins to look like an engineering system.
I later called this problem “long-running verification.”
Long-running verification should not be tacked on at the end of a task as a test report. It should appear before the task starts, during execution, and before entering Done. It includes at least four things:
- Before a task starts, there must be a checkable done-condition, not a wishful goal statement.
- During execution, there must be checkpoints that can explain why the current state is allowed to enter the next stage.
- After multi-agent parallelism, there must be a reduce mechanism that reduces results into evidence, not directly into a summary.
- Before entering Done, an evidence bundle must be left behind: commands, reports, screenshots, failure records, and unresolved risks.
These things sound clumsy, and not as glamorous as “let the agent explore on its own.” But engineering systems mostly stand on these clumsy things.
Closing: Let “Done” Leave Evidence
What long tasks need next is a more stable verification structure. As run times keep growing, this gap will only widen.
/goal lets an agent avoid finishing in one shot; dynamic workflows let an agent avoid working alone. Whether they can enter engineering delivery depends on another set of questions: whether the objective has a done-condition, whether the process has checkpoints, whether there are gates between stages, whether artifacts have proof, whether failures can be carried over into the next evaluation.
What AI coding may compete on next is another kind of capability: turning “it’s done” into a set of provable engineering facts.
The gate is small, but it may be the most critical unit in an agent runtime.
(This post is a machine-made, human-reviewed, and authorized translation of phodal.com/blog/long-running-agent-verification/.)