Free tools Windows power users keep installed
One-click scans. No signup required.
To stop a runaway agent, first cancel the active run through your application’s own stop mechanism. Then put a finite bound on every run, find the transition that repeats, and add checks wherever a tool changes external state. A higher limit is not a fix. It only lets a cycle that is still running consume more turns, steps, or money before it stops.
Stop the run that is executing now
Do this before anything else. The steps depend on how your agent is hosted, so start from the stop path your application already owns.
As an Amazon Associate I earn from qualifying purchases.
- Locate the run handle in your service. Every framework needs a reference to the active run, whether that is a task object, a worker, a graph invocation, or a request.
- Use the framework’s external stop control where one exists. In AutoGen AgentChat,
ExternalTerminationlets code outside the run end it programmatically. Trigger itsset()method from your control path. The Microsoft termination tutorial documents this as a programmatic stop from outside a run. - For OpenAI Agents SDK runs, stop according to your application’s lifecycle. The SDK documentation describes resumable run-state flows. If you need to keep the run’s state for later inspection, save it before you discard the process. Do not assume a restart will resume safely without checking that state.
- For LangGraph, stop the worker or request that invokes the graph. The graph’s recursion limit is a step cap, not a kill switch you can trigger from outside. Until the invoking process stops, the graph keeps stepping toward that cap.
- Quarantine the side effects. List which tools ran and what they changed. Temporarily revoke the credentials or disable the tool path that is still writing to external systems so the cycle cannot keep acting while you investigate.
Set a finite budget before the next run
Each framework counts something different and fails differently at its limit. Use the table as a map, then confirm the exact names in the version you have installed.
| Framework | What is counted | Finite setting | What happens at the limit | Unbounded option |
|---|---|---|---|---|
| OpenAI Agents SDK | Model turns | max_turns passed to the runner |
Raises MaxTurnsExceeded. The SDK guide shows an error handler that returns a controlled fallback. |
max_turns=None disables the limit. |
| LangGraph | Graph steps | recursion_limit in the run configuration |
The graph stops with the GRAPH_RECURSION_LIMIT error, which means it reached its maximum steps before a stop condition. |
Not stated on the cited error page. |
| AutoGen AgentChat | Messages, token usage, elapsed time, or an external signal | Termination conditions on the team, such as message count, token usage, or timeout | The run ends when the condition is met. | Not applicable as a setting. The termination tutorial notes that a run can go on forever without a termination condition. |
OpenAI Agents SDK
The SDK describes the runner loop as a model call followed by one of three outcomes: final output, a handoff, or tool execution followed by another model call. A cycle therefore appears as repeated model calls that never reach final output. Pass a finite max_turns to every run that needs a hard bound. Then handle MaxTurnsExceeded deliberately, because the failure is a controlled stop you designed for, not a crash to hide. Setting max_turns=None is appropriate only when you have an equivalent bound elsewhere.
#1 Best Overall
LangGraph
A GRAPH_RECURSION_LIMIT error means the StateGraph reached its maximum number of steps before it reached a stop condition. The official error page says this often results from an infinite loop, though complex graphs can legitimately need more steps than the default. Treat the error as a question first: check the edges and the stop logic for a cycle. Raise recursion_limit only when you have confirmed the graph needs more iterations. The page includes an example that raises the limit to 1000, but it presents that as an example, not as a recommended setting.
AutoGen AgentChat
Termination conditions are the stop logic for a team. The built-in options include message count, token usage, timeout, text mention, handoff, source match, external control, and function-call termination, and you can write custom conditions. Conditions combine with & (all must hold) and | (any may hold). A useful default pairs a message cap with a timeout, so one condition is a backstop if the other never fires. Token-usage termination only works when the agents report token usage, so verify that reporting is enabled before you rely on it.
Find the transition that repeats
A limit tells you that a run was too long. It does not tell you what repeated. Pull the run history, the tool inputs and outputs, the handoffs, the graph state, and the stop condition for the run, then check which of these patterns you see:
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
- The same operation with the same arguments. The agent calls one tool repeatedly and gets the same result each time.
- A ping-pong between agents or nodes. Two agents hand work back and forth, or a graph edge returns to an earlier node with no state change.
- Retries on a failing tool. A tool errors, the agent retries, and nothing in the retry path changes the input.
- An unreachable completion test. The stop condition depends on something the agent cannot produce, so the run never satisfies it.
Trace fields differ across frameworks, so these checks are diagnostic guidance based on how the loops are documented to work, not a promise that every framework exposes identical trace data.
Research on this failure mode gives a concrete reason to bound the feedback path, not just the whole run. Hou, Wang, Zhao, and Wang (2026) describe infinite agentic loops in a preprint, arXiv:2607.01641, submitted July 2, 2026. Their static-analysis evaluation covered 6,549 LLM-agent repositories and reported 74 potential findings. Manual review confirmed 68 infinite-loop failures across 47 projects, for a reported precision of 91.9%. These are the authors’ results for their own tool and sample. They do not measure how often loops occur in deployed systems. The authors also warn that a limit placed near a loop does not necessarily stop it if the limit does not govern the transitions that feed the loop.
Make the exit condition reachable
A limit is a backstop. The stop condition should be the normal way a run ends, and it has to be something the agent can actually satisfy. Check these points when you revise a workflow:
Rank #3
- Tie completion to state the agent can change. A completion flag that only a human sets, or a result the tool never returns, guarantees a cycle.
- Bound the loop, not only the run. If a retry path or a handoff pair can repeat, give that path its own counter or cap so it stops even when the global budget is still available.
- Define a failure outcome. Decide in advance what a stopped run returns to the user or the caller, such as a partial result, an error message, or a request for review.
- Keep the limit and the condition consistent. If the stop condition needs ten turns and the cap is three, the cap will always fire first and hide the design flaw.
Guard the tools that change state
Stopping a loop matters most when a repeated call writes to a database, sends a message, or moves money. Place checks where that action happens, not only at the start or end of the conversation.
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Tool-level checks
OpenAI’s SDK guardrails are scoped. Agent-level input guardrails run only for the first agent in a chain, and output guardrails run only for the final agent. Handoffs do not pass through the function-tool guardrail pipeline. If every custom tool call needs a check, put that check at the tool boundary. OpenAI’s practical guide describes this layering with the sentence Think of guardrails as a layered defense mechanism.
Human approval
Approval solves a different part of the problem. A guardrail validates an input, an output, or a tool call automatically. An approval pauses a sensitive action for review. In the OpenAI Agents SDK, an approval request pauses the run and returns resumable state. After a decision, resume that state. Do not treat the approval as a new run, or the cycle context and the pending action can be lost.
Idempotency and bounded retries
For tools that mutate external systems, make repeated calls safe where you can. Use an idempotency key so the same logical action is applied once, and cap retries per action. This is an engineering recommendation for your application. The cited framework documentation does not describe a universal idempotency feature that applies to all tools.
Verify the fix on your framework version
Framework APIs and defaults change between releases, and the behavior described here reflects the cited official documentation as of October 2026. Before you rely on a fix in production, confirm three things in your installed version:
- The exact name and default of the limit setting, and what the error or stop result looks like.
- That your stop path cancels or ends the run and does not just log it.
- That a deliberately cyclic test agent in a staging environment halts at the expected point, and that its tool calls stop with it.
Primary sources for the behavior above are the OpenAI running-agents guide, the OpenAI Agents SDK running-agents page, the LangGraph GRAPH_RECURSION_LIMIT page, the AutoGen AgentChat termination tutorial, the OpenAI Agents SDK guardrails page, the OpenAI guardrails and human review guide, and the OpenAI practical guide to building agents.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
