An AI agent should not be allowed to keep trying forever.
That sounds obvious until you look at how most agent workflows are designed. The happy path gets the attention. The retry path is treated like plumbing.
But retries are where autonomy quietly expands.
An agent fails to write a file, so it tries again. A tool returns an ambiguous error, so it changes arguments. A browser action does not land, so it clicks somewhere else. A multi-agent loop gets another critique, another revision, another handoff.
Sometimes that is useful. Sometimes it is how one bad observation becomes three bad actions.
The control is a retry budget.
What a retry budget actually controls
A retry budget is not just "try twice."
It defines what the agent can do after failure:
- How many times it can repeat the same action.
- How many times it can replan.
- Whether it can call a new tool.
- Whether it can touch a new data class.
- Whether it can make an externally visible change.
- When it must stop and ask for review.
- What evidence the reviewer gets.
This matters because agent loops are built around repeated action. Anthropic describes computer use as a loop where the model requests a tool action, the application executes it, returns the result, and the model decides whether more tool use is needed. OpenAI's Agents docs describe the same runtime pattern: the runner inspects output, executes tool calls, handles handoffs, and continues until a stopping point.
That loop needs a boundary.
The security problem is excessive agency
OWASP's Excessive Agency guidance is the cleanest security framing here. LLM systems often get tools, skills, plugins, or extensions. Agent systems may make repeated model calls where earlier outputs steer later calls.
OWASP names three root causes:
- Excessive functionality.
- Excessive permissions.
- Excessive autonomy.
Retries sit inside the third one.
A tool call that looks low risk once can become high risk when it repeats, changes arguments, or runs after the agent misunderstood a failure. A failed writeback is not just a failed writeback. It is a decision point.
Should the agent try again?
Should it change the target?
Should it escalate?
Should it stop?
If the workflow does not answer those questions up front, the model answers them at runtime.
Frameworks already expose the stop line
This is not theoretical.
OpenAI's Agents SDK exposes max_turns, which limits how many agent turns can run before stopping. The docs define a turn as one AI invocation, including tool calls. Passing None disables the limit.
LangGraph has a recursion limit error for graphs that hit the maximum number of steps before reaching a stop condition. The docs call out the obvious failure mode: an unexpected cycle.
AutoGen treats termination as a first-class design surface. It supports max-message termination, token usage termination, timeout termination, handoff termination, external termination, and custom functional termination.
Keep reading with free field-guide resources.
VibeSec Advisory publishes practical research, Skills, workflow examples, MCP notes, prompt injection tests, and AI red-team lessons for builders working with agentic AI.
LangChain's human-in-the-loop middleware can pause before sensitive tool calls such as file writes or SQL execution. The reviewer can approve, edit, reject, or respond. Its docs also warn that significant edits can cause the model to re-evaluate and potentially execute tools multiple times or take unexpected actions.
That warning is the point.
Human review is not only about approving a single action. It is about controlling what the agent does next.
Use five budgets
For a real workflow, define five budgets before launch.
Retry budget
How many times can the agent repeat the same failed action?
For each attempt, log the tool, arguments, output, error, and what changed before the next attempt.
Replanning budget
How many times can the agent change strategy before review?
Replanning can be more dangerous than retrying. It may introduce new tools, new data, new destinations, or new assumptions.
Side-effect budget
Which actions are read-only, reversible, reversible with effort, or irreversible?
Read-only actions can usually tolerate more retry room. Irreversible or externally visible actions should not retry autonomously after failure.
That includes financial transactions, legal commitments, customer-facing sends, credential changes, deletions, production modifications, publishing, and consent actions.
Escalation budget
When does the workflow stop?
Useful triggers:
- Same failure twice.
- New source type appears.
- Agent asks for a more privileged tool.
- Output conflicts with an approved source.
- Tool result is ambiguous.
- Human approval is missing.
- A retry would send, delete, spend, publish, modify production, expose sensitive data, or accept terms.
Evidence budget
What does the reviewer see?
Minimum packet:
- Goal.
- Current step.
- Attempt count.
- Tool trace.
- Source labels.
- Proposed next action.
- Data touched.
- Known failure mode.
- Reversibility.
- Recommended decision.
The decision should be continue, edit, reject, or escalate.
Recommended default
Start conservative.
One autonomous retry for read-only failures.
Zero autonomous retries for irreversible actions.
Human review after the same failure repeats.
Human review before any new tool, new data class, new destination, or externally visible action.
Durable trace logging for every tool call and guardrail decision.
Manual fallback when the retry budget is exhausted.
These are recommendations, not universal numbers. The budget depends on reversibility, data sensitivity, blast radius, and cost of delay.
But the workflow needs a number.
It also needs a stop line.
The field-guide test
Before an agent gets more autonomy, ask six questions:
- What can this agent touch?
- What happens if the same action runs twice?
- What happens if the second attempt is based on a bad observation?
- Who can stop it?
- What evidence will they see?
- What is the manual fallback?
If those answers are missing, the retry loop is not a reliability feature.
It is hidden autonomy.
Sources
- NIST, Artificial Intelligence Risk Management Framework
- NIST, Generative Artificial Intelligence Profile
- OWASP, Top 10 for Large Language Model Applications
- OpenAI, Guardrails and human review
- OpenAI Agents SDK, Tracing
- Anthropic, Building effective agents
- Anthropic, Measuring AI agent autonomy in practice
- LangGraph, Interrupts