---
title: "Decomposition delivers what checkpointers simulate"
url: https://recursiveai.org/research/decomposition-vs-checkpointing/
description: "When every step is an independently addressable endpoint, replaying step 30 means calling step 30. And when a multi-agent build needs resuming, the resumer should be an agent, not a replay engine."
date: 2026-08-27
author: Kurtis Welch
---

# Decomposition delivers what checkpointers simulate

August 27, 2026 · Kurtis Welch

Graph runtimes for agent workflows ship elaborate checkpoint-and-replay machinery, and it’s worth asking why they need it. The answer is structural: in a graph runtime, a node has no independent existence. Replaying step 30 requires the runtime to have recorded steps 1–29, because step 30 is only defined relative to the run that contains it.

Decompose differently and the machinery evaporates. **When every step is an independently addressable endpoint, replaying step 30 means calling step 30.** Its inputs are explicit, its address is stable, and any client — a human with curl, an orchestrator, a test — can invoke it in isolation. Durability stops being a runtime feature and becomes a property of the decomposition. Structure, not machinery.

That covers the mechanical half. The more interesting half is what happens when a long-running multi-agent build actually fails, because there the checkpoint model isn’t just unnecessary — it’s wrong.

A checkpointer re-runs a failed step with identical inputs and hopes. But a step that failed in a multi-agent build usually failed *for a reason*: the spec was ambiguous, a dependency delivered something different than expected, an approach hit a wall. Identical replay reproduces the conditions that produced the failure.

**Our resumer is an agent, not a replay engine.** Plan orchestrators write a first-class execution ledger as they go — per-artifact entries, timestamps, builder instance IDs. When a build needs resuming, an orchestrator reads that ledger: completed specs are skipped, failures are revisited. Before re-dispatching, it reviews each builder’s plan, consolidates open questions across parallel builders, diagnoses *why* the failed step failed, and changes the approach — a different spec, a different decomposition, sometimes a different specialist. Recovery is judgment, not retry.

The receipt we point to: a 37-artifact platform subsystem built by creator agents in dependency waves in about an hour, ledgered per-artifact — and resumed across failures without ever replaying a completed step. The pattern needs no exotic runtime, just two commitments: address every step, and let something with judgment read the ledger.