Loop cost guardrails pattern
The four-part cost guardrail every agent loop should ship with: a hard iteration cap, a stop-after-N-turns clause in the goal text, a budget limit on SDK loops, and a /cost check inside the loop body.
Implementation note
When to use: before running any loop unattended — this is the checklist pattern for the most common loop disaster, discovering the overnight run cost fifty times your estimate. How it works: four guardrails, applied together rather than as alternatives. A hard MAX_ITER=20 cap in the loop wrapper bounds iterations mechanically. An or-stop-after-N-turns clause written into the /goal text bounds the in-session layer. max_budget_usd on SDK-driven loops bounds dollar spend directly. And a /cost check inside the loop body gives running visibility, so drift is observable mid-run instead of at invoice time. Safety: the redundancy is the design — each rail catches what another misses: the iteration cap stops infinite loops, the budget cap stops expensive-per-iteration loops, and the in-prompt clause survives contexts where the wrapper does not apply. Adopt all four as the default template for every loop you ship, not just the risky ones.
More automation loops
Run workflows with dynamic sub-agents
Split a task into packets, run sub-agents in parallel, synthesize results, and verify completion.
Run agent turns until goal met
Agent executes repeated turns toward a condition, with a lightweight evaluator checking progress after each turn until the goal is reached.
Run agent until goal met
Queue agent turns with goal context until your objective is achieved, treating the goal as untrusted data.