Protocol
Bound every autonomous agent loop before it starts
A loop without a hard edge is an outage waiting for a goal condition to fail.
When it fits
- An agent can iterate until it believes the task is complete.
When to avoid it
- Bounds can stop useful work early; choose them from task stakes and expected horizon, then tune with observed trajectories.
Why it matters
Set explicit bounds before execution: maximum invocations or steps, elapsed time, tool-call count and/or cost. The loop can stop earlier on success, but it must have a deterministic ceiling if the completion condition fails, the model stalls or the evaluator becomes inconsistent.
Steps
- A broken completion condition cannot create an unbounded run.
An example
A research agent can run until the coverage rubric passes, but never beyond 20 search/analysis iterations or the defined cost budget.
Check your result
A broken completion condition cannot create an unbounded run.
Keep this limit in mind
- Bounds can stop useful work early; choose them from task stakes and expected horizon, then tune with observed trajectories.
Connected ideas
Useful withBound how much damage one agent run can do
Evidence and sources
Supports
Microsoft's agent-loop documentation explicitly recommends always bounding autonomous loops because completion conditions can fail and agents can stall.
Bounds can stop useful work early; choose them from task stakes and expected horizon, then tune with observed trajectories.
Agent Looping · See source record