The Graph Follows Execution

Ask of any part of a system's graph: could this have been reconstructed from a record of a run that already happened? A process tree, a flame graph and a call graph answer yes, which is why each is a program you run afterwards rather than a file you edit first. A durable execution journal answers partly — the history is generated by running, but a journal can only record boundaries somebody declared. An approval gate answers no, and not merely because it must precede what it gates: what a gate encodes is what it would do on inputs that did not arrive, and an execution takes one path.

Recoverability is a property of the information, not a choice available to a designer. The move this paper makes follows from taking that seriously: existing frameworks classify nodes by function — router, judge, retry, checkpointer — and we classify the information those nodes carry by whether running the system can generate it. The familiar distinction between graphs that are written and graphs that are read is one consequence. We call these the prescriptive and descriptive uses, and argue that agent orchestration frameworks are caught between them. The claim is not that graphs cannot execute — Petri nets, statecharts, BPMN and every dataflow language execute, and the workflow systems in data engineering are right to be written in advance. It is narrower: a graph that records discovered structure should not have to exist before the discovery. Where a task's decomposition is itself the work, requiring the graph up front asks the developer to finish a search before the computation that would perform it has started.

Sorting a framework's own primitives supplies the evidence, and the three classes it yields are the three answers to the recoverability question. Some are operating system concerns with an owner since the 1970s — processes, message passing, lifetime, reaching a host. Some are gaps the kernel really does not fill, chiefly durability across process death, and durable execution engines are building the substrate for them. The rest — router, retry, judge, validator, approval gate — are not infrastructure. Each records a place where a model could not be trusted with something. We argue this last class is not disappearing but churning: individual nodes are indexed to a capability level and expire, while the class persists because rising capability is spent on wider scope. That makes it the fastest-moving part of the system, and Hydra's 1975 argument is precisely that the fastest-moving part is what must not be frozen into the same file as the slowest.

The design conclusion is not that agent systems should have no written graph but that they should have two, split where recoverability splits them: write the counterfactual part, recover the rest. A case study of toast shows the recovered half is constructible — the graph is a process tree and a message log rather than a file. We state what it does not get — no durable execution, no proof of behaviour before running, a shell as a prerequisite — and give predictions checkable against framework release histories.