Subtasks and checkpoints
Subtasks and checkpoints are a workflow pattern for agent systems where a long goal is split into recoverable units, and useful state is saved between them. Each subtask produces an inspectable result; each checkpoint lets the run resume, retry, branch, or stop without losing all prior progress.
Long agent runs fail for the same unglamorous reasons as other distributed software: malformed inputs, unreliable APIs, rate limits, ambiguous intermediate results, stale context, and bad local decisions. If the whole job is one opaque prompt, any of those faults can poison the remainder of the run. Decomposition limits the blast radius by making progress visible and replaceable at step boundaries.
In practice, the agent behaves less like a monologue and more like a workflow. It chooses or receives a subtask, executes it, records the prompt, tool calls, outputs, errors, and decision state, then uses that recorded state to choose the next action. A checkpoint is the persisted handoff: enough information to resume from a known-good point rather than reconstructing the entire conversation.
The trade-off is extra engineering. You must decide what counts as a stable output, define schemas, persist state, handle idempotency, and avoid splitting work so finely that orchestration dominates the task. Checkpoints can also preserve bad assumptions if validation is weak. The honest answer to checkpoint frequency is: it depends on failure cost, tool reliability, review needs, and how expensive recomputation is.
Engineers meet this pattern in planning agents, LangGraph-style state machines, background job systems, CI pipelines, map-reduce workflows, and human-in-the-loop review flows. Natural boundaries are places where a result can be validated: after retrieval, extraction, code generation, test execution, summarisation, or an external tool call. A vague chain of prompts becomes a resumable system when those boundaries have explicit inputs, outputs, and recovery rules.
Common questions
- Are checkpoints just saved copies of the conversation?
- No. A conversation transcript may be part of a checkpoint, but a useful checkpoint saves the operational state needed to continue safely: the plan, current subtask, tool outputs, structured results, validation status, errors, and decisions already made. It should support resuming or retrying without depending on hidden context.
- Do better prompts remove the need for subtasks and checkpoints?
- No. Better prompts reduce some errors, but they do not make tools reliable, APIs available, inputs clean, or model outputs deterministic. Checkpoints are a control mechanism, not a prompt-quality substitute. They let software validate, retry, branch, request review, or abandon a step before the failure contaminates later work.
- How do I choose where to put subtask boundaries?
- Put boundaries where there is a meaningful intermediate result that can be checked independently. Good candidates include fetched data, extracted facts, generated files, test results, approvals, and external side effects. Avoid boundaries that save vague reasoning only; prefer points where the next step can consume a clear, typed, or otherwise verifiable artefact.