Stop Runaway AI Agents: Loop and Cost Control Patterns
Autonomous AI agents are powerful precisely because they decide their own next steps. That same autonomy is what lets an agent quietly rack up thousands of API calls, loop on a task it can never finish, or drain your monthly budget before lunch. If you are shipping agents to production in 2026, controlling loops and cost is not optional infrastructure — it is a core reliability feature.
This guide covers the concrete patterns that keep agents bounded: step limits, token and dollar budgets, stop conditions, and the guardrails that catch failures before they compound.
Why Agents Run Away in the First Place
An agent loop is deceptively simple: the model observes state, chooses a tool or action, executes it, and feeds the result back in. Repeat until the goal is met. The failure modes all live in that word until.
- No termination signal. The model never emits a "done" state because the task is ambiguous or impossible.
- Oscillation. The agent alternates between two actions — call an API, get an error, retry the same call, get the same error.
- Tool-call storms. A single reasoning step spawns dozens of parallel tool calls, each with its own token cost.
- Context bloat. Every iteration appends more history, so each step costs more tokens than the last, turning a linear task into quadratic spend.
None of these are exotic. They show up in ordinary retrieval, coding, and research agents. The fix is to assume the agent will misbehave and build hard limits around it.
Pattern 1: Hard Step Limits
The simplest and most important guardrail is a maximum iteration count. Wrap your agent loop in a counter and refuse to continue past a ceiling.
MAX_STEPS = 15
step = 0
while not done and step < MAX_STEPS:
action = agent.decide(state)
result = execute(action)
state = update(state, result)
step += 1
if step >= MAX_STEPS:
escalate("step limit reached", state)Pick the ceiling based on how many steps a successful run actually takes, then add headroom. If your typical research task finishes in five steps, a limit of fifteen catches runaways without cutting off legitimate work. Log every run that hits the limit — those logs are your best signal that a task class is under-specified.
Distinguish limits from failures
Hitting a step limit is not the same as failing gracefully. When you truncate a run, return a clear status the caller can act on (for example, incomplete_step_limit) rather than a partial answer that looks finished. Downstream code should never mistake a cut-off run for a real result.
Pattern 2: Token and Dollar Budgets
Step count alone does not bound cost, because one step can be far more expensive than another. Track cumulative token usage and translate it into a dollar figure using your provider's current per-token pricing.
budget_usd = 0.50
spent = 0.0
for step in range(MAX_STEPS):
resp = model.call(prompt)
spent += cost_of(resp.usage)
if spent > budget_usd:
halt("budget exceeded", spent)
breakSet budgets at multiple scopes so no single layer can blow up the whole system:
- Per-run budget — caps a single agent invocation.
- Per-user or per-tenant budget — protects you from a single customer's traffic, whether accidental or abusive.
- Global daily budget — a circuit breaker that pauses all agent activity if aggregate spend crosses a threshold.
Enforce these with a shared counter in a fast store like Redis so the limit holds across concurrent requests and multiple worker processes. A budget that only lives in one process memory is no budget at all.
Pattern 3: Explicit Stop Conditions
Step limits and budgets are safety nets. The primary way an agent should stop is by succeeding. Make that success condition explicit and machine-checkable rather than relying on the model to declare victory.
Verifiable completion
Wherever possible, define done as a testable state, not a model opinion. Examples:
- A coding agent is done when the target test suite passes.
- A data-extraction agent is done when the output validates against a schema.
- A retrieval agent is done when it has produced an answer with at least one supporting citation.
When completion is verifiable, you can let the loop run until the check passes or a limit trips — and you get a trustworthy signal instead of a hallucinated "task complete."
No-progress detection
Detect oscillation by hashing the agent's action plus its key arguments each step. If you see the same action-and-args repeat two or three times, break the loop — the agent is stuck. This one check eliminates a huge fraction of infinite loops in practice.
recent = []
signature = hash((action.name, action.args))
recent.append(signature)
if recent[-3:].count(signature) >= 3:
halt("no progress: repeated action")Pattern 4: Bound the Fan-Out
Agents that can call tools in parallel need a concurrency cap. Limit the number of tool calls per step and the total number of in-flight calls. Without this, one reasoning step that decides to "search everything" can trigger hundreds of simultaneous requests and their associated cost.
Also guard recursion depth for agents that spawn sub-agents. Each sub-agent should inherit a share of the parent's remaining budget, not a fresh full budget — otherwise a three-level tree multiplies your spend geometrically.
Pattern 5: Control Context Growth
Because token cost scales with context length, an agent that naively appends every observation gets more expensive each step. Keep context bounded by summarizing older turns, dropping raw tool output once it has been used, and storing large artifacts externally with only references in the prompt. A predictable per-step token cost makes your budget math reliable.
Observability: You Cannot Control What You Cannot See
Every guardrail above depends on measurement. Instrument each run with:
- Step count, tokens in and out, and dollar cost per run.
- Which stop condition ended the run — success, step limit, budget, or no-progress.
- The full action trace so you can replay stuck runs.
Emit these as structured events and set alerts on the ones that matter: a spike in budget-halted runs, a rising share of step-limit truncations, or a single tenant consuming a disproportionate slice of spend. Modern tracing tools for LLM applications make per-run cost attribution straightforward — use them from day one rather than bolting them on after your first surprise invoice.
A Practical Default Configuration
If you are starting fresh, these defaults are a reasonable, conservative baseline to tune from:
- Max steps: 10–15 per run.
- Per-run budget: a fixed dollar cap sized at roughly 3x the cost of a typical successful run.
- No-progress break after 2–3 repeated actions.
- Max 5 parallel tool calls per step; sub-agent depth capped at 2.
- A global daily circuit breaker that pauses agents and pages a human.
Start strict. It is far easier to loosen a limit after watching real traffic than to explain a runaway bill. Treat every truncated run as feedback: if legitimate tasks keep hitting your ceilings, the fix is usually a clearer goal or a better tool, not simply a higher limit.
Ready to build real AI skills? Join the September 2026 cohort at Class For Jobs. Explore Advanced AI — a hands-on, live program to build and ship production AI applications, live and instructor-led with career support, resume help, and job-placement assistance.
Related reading
