And Then There Were Graphs

On 18 July, Peter Steinberger posted twelve words on X:

Are we still talking loops or did we shift to graphs yet?

That was all of it, and it was enough. The field had already moved through prompt engineering and loop engineering, so the next noun was funny before anybody had agreed what it meant.

Prompt engineering was mostly about one model turn. Find the wording, add the examples, arrange the context. As models gained tools and longer-running jobs, attention moved outwards to the harness and the loop around the prompt. The model planned, acted, read the result and tried again. The wording still mattered, but it was no longer the whole machine.

We laughed at the tweet. Then we looked across at a coding session that had been alive for sixty hours.

The session was doing useful work, which was why we had allowed it to continue. Across eleven substantial sessions, nine had shipped work before ending and ten eventually shipped. Their review stages had caught defects the test suites missed and stopped real regressions before release.

This one had begun with a product change. It later found missing database merges, which made parity work necessary, and the parity work exposed a staging prerequisite. Each addition to scope had evidence behind it. By then the session had survived forty-five context compactions and dispatched more than two hundred child tasks.

Viewed from above, it looked like a small municipal government. The transcript held goals, dependencies, approvals, repairs, release state, and the reasons one job had paused while another became urgent. This had happened gradually. Nobody had chosen a conversation as the database for the work.

The timing of the tweet made it hard to ignore. We wanted to know whether an explicit graph of goals and dependencies would help, and whether we could keep the review stages that were finding real bugs.

We were not going to run a second sixty-hour session beside it, so we selected three closed engineering jobs with known outcomes and replayed each through three workflow shapes. Near the end of those replays, one candidate had passed twenty-nine focused tests, TypeScript, diff checks and several rounds of review. A fresh reviewer found this case:

{ code: "ECONNRESET" }

The retry logic recognised ordinary network errors and awkward error objects that carried a useful message. This object had no message, so the code normalised it into Error("[object Object]") before classification. The network code disappeared and the operation received one attempt instead of another.

We reproduced the finding with a focused test and ended that trial. Our protocol did not allow unlimited repairs. The reviewer had been given frozen candidate bytes and a precise question, and that discipline had found something the workflow around it had missed.

// what we actually tested

The prompt-to-loop-to-graph sequence mixes several levels of a system. A prompt shapes one model turn. A harness controls context and tools. A loop lets the model inspect an action and try again. A work graph keeps state between bounded jobs: what is ready, what is blocked, what evidence closes a job, and where its output goes.

The replay covered a cache path with tricky retry rules, a schema change with several related query surfaces, and a recurring-notification change with an edge case around newly created state. Each started from a clean historical base with the same reconstructed intake and acceptance checks.

We tried a reviewed single-node workflow, a bounded modular workflow with isolated workers where the job appeared separable, and the same modular workflow with two independent reviewers. The controller used GPT-5.6 Sol and attempted worker dispatches used GPT-5.6 Terra. Opus 5 supplied independent review, with GPT-5.6 Luna added in the dual-review arm.

There was one run for each job and workflow shape. The twenty-one mandatory behaviours were eight cache checks, five query-surface checks and eight notification checks. Exact prompts and work artifacts are not public because they contain application detail, so this is an internal decision exercise rather than a reproducible benchmark.

We wrote the adoption rule before running it. A replacement had to preserve every mandatory behaviour and known release-blocking finding, accept no refuted high-severity finding, and reduce median time or fresh-token use by at least twenty-five percent without asking more of the operator. Here, "fresh tokens" means uncached input plus output across the controlled routes. It is not invoice cost or a measure of unique context.

The reviewed single-node and dual-review workflows each met twenty of the twenty-one behaviours. The bounded modular workflow remained unscored on one job because its only successful worker crossed the repository-isolation boundary and the required independent review never ran.

Median critical-path time improved by roughly ten to twelve percent in the two valid workflows. Median fresh-token use rose to between 2.3 and 3 times the observed historical comparator. The controlled replay accounted for about 5.0 million fresh tokens and 4.8 hours when active author and reviewer time was added together. That is workload, not elapsed time.

Those figures are much less general than their precision makes them look. We deliberately selected three old jobs, ran each cell once, and gave the replays packets containing information the original sessions had discovered live. Models and infrastructure had changed. Some historical token routes were incomplete, and medians across three different jobs say nothing about run-to-run variance. The failed worker dispatch may tell us about our isolation implementation rather than the value of explicit work state.

The numbers were enough to keep the tested modular workflow shapes out of production. They do not isolate the effect of adding a graph, because each shape also changed decomposition, worker dispatch, isolation, handoffs and review. A causal comparison would need repeated trials that vary those elements separately.

// what the reviewers were doing

The final network-code case was not an isolated save. Earlier review rounds found a third affected query after the obvious two had been repaired. On the notification job, review found that records could commit while the notification disappeared because the code was consulting state from before the mutation. The cache job also produced genuine findings about mixed-failure masking and a coded provider error being retried incorrectly.

Every accepted finding was reproduced against the frozen candidate. Review also produced plausible claims that did not survive reproduction. This is why the approval belongs to an exact candidate rather than to a branch name or a general sense that the work has been looked at. Any repair changes the bytes and cancels the approval.

The replay made it difficult to justify reducing that review loop. It was expensive, but it was still finding defects with observable consequences. The large conversational session suggested a different target: the coordination state surrounding the implementation and review work.

Inside a long conversation, all of those facts are prose. After enough hours and context compactions, the transcript has to remember why the first goal stopped, which findings still apply, what changed underneath them, and where to return. Each worker adds another handoff to the same record.

Published evidence also treats decomposition as conditional. Anthropic reserves parallel agents for independent work or perspectives. Google Research found that coordination helped a parallelisable task while multi-agent designs degraded strict sequential work, and CAID reports positive coding results on long jobs with separable packages. The useful distinction is whether the work decomposes cleanly.

// seven columns, five jobs

For the next five real jobs, we will move only the coordination state into a small Markdown ledger. A cohesive coding job keeps its existing loop. Work fans out when packages are genuinely independent or when separate reviewers need independent contexts.

There is no runtime or automatic router in the pilot. Its nodes are goals and evidence checks. Its edges are limited to blocks, requires and verifies.

The staging detour from the long session would have been recorded as:

release [blocked] -> parity proof [blocked] -> staging prerequisite [done] -> parity proof [done] -> release [ready]

That short record preserves the return path without asking a compacted conversation to reconstruct it.

During the pilot we will measure ledger upkeep, stale state, restart effort, operator interventions, repair cycles, time and tokens. It stops early if upkeep exceeds ten percent of active work twice, if stale state causes a wrong action, or if a checkpoint loses a protected invariant. Requests for a service, daemon, additional node types or an expanding metadata schema count as evidence against the pilot.

Production routing, review authority and release authority stay unchanged. After five jobs, the ledger can earn a continuing role if it makes interruption and recovery easier without reducing correctness.

We went looking for a graph engine and found a Markdown table. For now, that is enough.