Decomposition as an Engineering Artifact, Not a Prompt

Decomposition as an Engineering Artifact is the difference between an agent that can be recovered and one that can only be restarted. The plan has to exist somewhere outside the model's context, in a form the runtime can read, or none of the mechanisms in the next four chapters have anywhere to attach.

Key takeaways

• A plan inside a prompt is invisible to everything except the model. The runtime cannot check a step against it, resume from it, or roll one back, because as far as the process is concerned the plan is prose.
• The artifact needs more than steps. Each step carries a precondition, an acceptance check, an effect class, a compensation reference and a budget, and those five fields are what Chapters 4 to 9 operate on.
• Effect class is the most consequential field: read, internal write, or external effect. It decides recovery cost, and it is the boundary between a mistake you can undo and one you can only apologise for.
• Decompose along recovery boundaries rather than along verbs. A step should end where you can cheaply say whether it worked and cheaply undo it if it did not.
• Plan revision is an event to record, not a state to overwrite. When an agent changes its plan mid-run, the old plan and the reason are the evidence you will want during the incident review.

Read this beside Chapter 2, whose three kinds of wrong state this artifact makes explicit, and Chapter 7, which is where the structure gets executed durably. Chapter 5 attaches the checks and Chapter 6 the compensations.

Ask most agent implementations where the plan is and the honest answer is that it is in the assistant's last message. It was generated, it was read by the next inference call, and it exists nowhere a process can consult.

Then the process restarts. The plan is gone. The only recovery available is to begin again from a prompt and hope for a similar decomposition.

A plan the runtime cannot read is not a plan

There is a useful test. If the orchestrating code cannot answer, in ordinary programming terms, which step is currently executing and what has to be true for it to be finished, then there is no plan in the system.

That is not a criticism of models producing plans. Models are good at producing them. The failure is architectural: the output was consumed as text and never turned into state. Everything the rest of this book asks for depends on that conversion. Verification needs a stated acceptance condition. Checkpointing needs a step boundary to attach to. Compensation needs to know what effects a step emitted. Budgets need to know how many steps remain.

Temporal's framing is worth borrowing even if you never adopt the product, because it names the split precisely: workflows are business logic defined in code, and activities are the individual units of work that interact with the outside world. Translated into agent terms, the plan is code-shaped and the steps are the things that touch reality. When both live in a prompt, the system has neither.

What the artifact contains besides steps

The minimum structure is small enough to write in an afternoon and specific enough to carry the rest of the book.

Two fields carry more weight than the others. Acceptance is what turns a claim into a check, and writing it forces a question that a prose plan lets you skip: how would I know. If a step has no cheap observable, that is a finding about the design of the step rather than a gap in the template.

Compensation is where honesty enters. Most steps that send something to a third party have no true inverse, and the field should say so rather than holding a hopeful placeholder. Garcia-Molina and Salem's 1987 saga formulation is the ancestor here: a long-lived transaction is a sequence whose partial execution is amended by compensating transactions. Their model assumes the compensation exists. Yours has to record where it does not.

Decompose along recovery boundaries

The instinct is to split work by verb: fetch, analyse, decide, write, notify. That produces a readable list and arbitrary boundaries.

Split by recoverability instead. A step should end at a point where two things are cheap: saying whether it worked, and undoing it if it did not. That rule tends to push external effects into their own steps, which is exactly what you want, because it isolates the irreversible parts of the run into places where a gate and an approval can be attached.

It also produces steps of uneven size, and that is correct rather than untidy. Reading six files to build a picture is one step, because it is one thing to verify and nothing to undo. Writing one row to a partner's system is one step, because verifying it is a separate call and undoing it may be impossible.

The diagnostic work published in April 2026 by Wang and colleagues, across four domains and more than 3,100 trajectories, supports treating failure as attributable to specific steps. Attribution is only possible when steps are defined somewhere the analysis can see them, which is the second reason for the artifact: it is what makes your own failures diagnosable later.

Who writes the plan, and how much freedom it gets

Anthropic's December 2024 guidance draws the distinction the industry has settled on: workflows orchestrate models through predefined code paths, and agents direct their own processes and tool use. Their advice is to start simple and add complexity only when needed.

For long-horizon work the useful answer is usually neither pure form. The shape that holds is a fixed skeleton with model-generated interior: the phases and their effect classes are written by engineers, and the steps inside each phase are proposed by the model, validated against a schema, and only then admitted to the plan.

Validation is not a formality. A proposed step is rejected and regenerated before anything executes if it fails schema validation, names a tool that does not exist, or omits an acceptance check. That gate removes a whole class of failures. They surface otherwise at step thirty, as an unhandled exception.

How much freedom the interior gets is a risk decision rather than a taste one. The more your steps carry external effects, the more of the plan should be fixed in code. A run that only reads and reasons can be almost entirely model-planned, because the worst case is wasted tokens.

Revision is an event, not an overwrite

Plans change mid-run, and they should. New information arrives, a precondition turns out to be false, a tool returns something the plan did not anticipate.

The mistake is to let the agent replace the plan silently. When the record of what was intended is overwritten by what is now intended, three capabilities disappear at once: you cannot tell whether the revision was reasonable, you cannot resume from the pre-revision state, and you cannot count revisions as a signal.

Treat each revision as an appended event with the reason, the trigger and the diff. That gives you a cheap and unusually informative metric. A run that revises its plan twice is adapting. A run that revises eleven times is thrashing, and the eleventh revision is a better predictor of a bad outcome than any individual step failure. The reliability-science framing from March 2026 gives the vocabulary for that pattern with its meltdown onset point, and revision count is the cheapest proxy for it available inside your own system.

Set a revision budget for the same reason you set a token budget. Chapter 9 makes it a ceiling with a defined behaviour when it is hit, which is usually escalation rather than termination.

Granularity, and the cost of too many steps

Fine decomposition looks safer and is not free.

Chapter 2's arithmetic applies to whatever unit you choose. Splitting one step into five does not change the total work, and it does change the number of places where a judgement can go wrong, and each additional boundary adds overhead: a check, a checkpoint write, and often an extra inference call.

Two rules keep it sane. A step should be large enough that its acceptance check is worth running. It should be small enough that redoing it is cheap. And two adjacent steps sharing an effect class and an acceptance check, with no possible failure between them, should be one step.

There is a subtler trap. Because the model chooses how finely to decompose within a phase, a system that rewards thoroughness will produce plans with more steps and a lower end-to-end success rate, while every individual step looks better. Watch step count per phase over time. If it drifts upward without a change in the work, the prompt is being rewarded for something you did not intend.

How the structure gets executed

The artifact is only worth writing if something walks it, and the walk is deliberately boring: read the next step, check its precondition, dispatch it, run its acceptance check, record the result and the effects, checkpoint, and continue.

Two properties matter in that loop. The walk must be resumable from the record alone, because Chapter 4 depends on it. And the walk must be deterministic given the same record, which is the constraint Temporal's replay model enforces by requiring that workflow code avoid clocks, randomness and network calls outside activities. Model calls are non-deterministic by nature, which is precisely why they belong on the activity side of that line, with their outputs recorded as results rather than recomputed.

That separation is the whole trick, and it is why Chapter 7 comes where it does. The plan is the deterministic part. The model calls and the tool calls are the non-deterministic parts, and the record of what they returned is what makes the run replayable.

Chapter summary

A plan that exists only in a prompt is invisible to the runtime, so nothing can verify, resume or undo anything, and the test for whether you have a plan at all is whether the orchestrating code can name the current step and its finishing condition. The artifact needs five fields per step: precondition, acceptance, effect class, compensation and budget, with acceptance forcing the question of how you would know and compensation forced to record honestly where no inverse exists, in the tradition of the 1987 saga formulation. Boundaries should follow recoverability rather than verbs, which naturally isolates external effects into their own steps where gates and approvals can attach, and it makes failures attributable in the way the 2026 diagnostic work assumes. The plan is best written as a fixed skeleton with model-generated interior validated against a schema before execution, with more of it fixed in code the more external effects it carries. Revisions are appended events with reasons rather than overwrites, which preserves resumability and turns revision count into an early warning that outperforms individual step failures. Granularity is a real trade-off, since every extra boundary adds a judgement and an overhead, so steps should be large enough to be worth checking and small enough to be worth redoing. And the executor that walks the plan must be resumable from its record and deterministic given that record, with model and tool calls on the activity side of the line.

The record that makes the walk resumable is the next problem. Chapter 4 is Checkpoints: What an Agent Must Be Able to Resume From, which is about choosing the state boundary that makes a restart cheap, what belongs in a checkpoint besides the step number, and why the most common checkpoint design saves everything except the one thing you need.