Execution: lifecycle, transactions and evals

A declared lifecycle gives every run a known state, a set of allowed transitions, and an end. Without one you cannot answer the two questions that always come up in an incident: where is this process now, and what will it cost if it keeps going. Explicit states also make progress reportable in business terms rather than in log lines, and give operations a defensible place to intervene.

Agent actions touch real systems, so they need the discipline you already apply to database work: plan, preview, apply, verify, commit, with a defined rollback. When that sequence is missing, a failure halfway through leaves the environment inconsistent, and the cleanup is manual, slow and usually done by your most senior people. Reversibility is also what makes it safe to grant more autonomy over time, because mistakes stop being permanent.

An evaluation set is the regression suite for probabilistic software. It is what lets you say whether a new model, prompt or context change actually improved anything, instead of arguing from anecdotes and the last three examples anyone happened to try. Teams that invest here can adopt a new model within days and defend the decision with numbers; teams that do not are structurally unable to upgrade safely, and their quality discussions never converge.

Treating a request as source code that passes through stages, from parsed intent to specification, plan, execution and verification, has one very practical benefit: when the output is wrong you can tell which stage was wrong. Systems built as a single opaque call cannot be diagnosed after the fact, so every incident restarts from guesswork and every fix is speculative. Persisting the intermediate artefacts is cheap; not having them is what makes post-mortems inconclusive.