Agent Systems · advanced
Agent Run Lifecycle
Run initialization, leases and heartbeats, progress transitions, budgets, completion evidence, cancellation, escalation, and safe termination.
Mental model
An autonomous run is a finite-state machine with an owner and a budget. It starts only after prerequisites are ready, progresses through durable states, renews authority while healthy, and terminates as complete, failed, cancelled, or escalated. 'Keep trying' is not a lifecycle state.
How to study Agent Run Lifecycle
Begin by restating the mental model in your own words, then connect it to a concrete system you have built or operated. Name the mechanism, the constraint it addresses, and the trade-off it introduces. Use OpenAI — Unrolling the Codex agent loop, Effective Harnesses for Long-running Agents (Anthropic) to check details, but close the source before writing your explanation. Retrieval is the learning step; rereading is only preparation.
Next, compare Agent Run Lifecycle with Durable Agent Execution, Long-running & Scheduled Agents, Independent Agent Verification. Ask what changes in correctness, latency, resource use, operability, and failure recovery. Complete Implement a bounded agent run lifecycle and preserve the command, input, output, and one failed attempt as evidence. Finish by explaining the idea without jargon to someone who has not studied the track.
Proof of understanding
- Explain the mechanism from first principles and identify the state it reads or changes.
- Give one situation where the concept is the right choice and one where it is not.
- Predict a realistic failure mode before running the drill, then compare the prediction with evidence.
- Connect the result to a roadmap or build artifact instead of treating the concept as isolated trivia.
Where it matters
Background coding agents, durable workflows, scheduled maintenance, CI remediation loops, and multi-hour autonomous builds.
Common mistakes
- Using a timer as the only stop condition
- Marking complete when commands ran rather than when the objective is satisfied
- Retrying permanent or authorization failures as if they were transient
Learn from primary sources
Practice and explain it back
Implement a bounded agent run lifecycle
Implement transitionRun(state, event). Valid states are queued, running, checking, complete, blocked, cancelled. start moves queued to running only when event.ready is true; submit moves running to checking; accept moves checking to complete only when event.evidenceCount is positive; reject moves checking back to running when budget remains and to blocked otherwise; cancel moves any non-terminal state to cancelled. Invalid transitions must throw.
Expected evidence: A finite-state lifecycle whose completion and retry transitions require evidence and remaining authority.
Open the interactive drill →Review prompts
- Design the terminal states and gates for a long-running agent loop. Why is 'run until the timer ends' not a safe lifecycle?
Build evidence
Build a Complete Coding-Agent Harness
Build a repository-local harness that can take one bounded engineering task from initialization through implementation, verification, durable handoff, and explicit termination without relying on hidden machine state or chat memory.
- A fresh isolated workspace can bootstrap and prove readiness from repository-local commands
- Instruction scopes, allowed edit roots, capabilities, budgets, and escalation triggers are explicit and mechanically inspectable
- The run persists goal, progress, evidence, blockers, and the next safe action across a forced restart
- A checker gathers independent evidence and can reject an unsupported maker claim
- The lifecycle terminates only as complete, blocked, failed, cancelled, or escalated with durable evidence
Automate and Evaluate a Maker-Checker Loop
Automate a bounded loop in which a maker attempts one task, an independent checker evaluates explicit acceptance criteria, failures return actionable evidence, and the orchestrator stops on success, escalation, cancellation, or budget exhaustion. Compare it with a baseline harness on a frozen task suite.
- Maker and checker roles have separate inputs and the checker ignores unsupported self-reported success
- The loop has explicit goal, task and retry budgets, durable state, and semantic termination criteria
- A frozen evaluation suite measures success, unsafe actions, cost, latency, retries, and human interventions
- At least one component ablation isolates whether instructions, tools, verification, or retry policy caused the observed change
- Release or rejection follows a declared multi-objective gate rather than pass rate alone