The agent ran. It kept running. Nothing came back.
No error. No output. Just a spinning process and a rising API bill.
The first assumption was the prompt. Too complex, too ambiguous, not enough context. So the prompt got rewritten. The agent ran again. Same result. Four minutes of silent execution, zero useful output, and a validation node that had no idea it was supposed to stop.
That is the loop nobody talks about when they demo LangGraph. Not the clean orchestration. The silent one that costs you money while you wait for something that will never arrive.
Decision Snapshot
The Wrong Diagnosis
When an agent loops without producing output, the natural instinct is to blame the model. The prompt is vague, the instructions conflict, the context window is overwhelmed. That is the visible surface. It feels correct because the agent is clearly confused.
It was the wrong diagnosis.
The prompt was not the problem. The validation node had no exit condition. It was checking output quality, finding it insufficient, and routing back to the generation node — every single time, indefinitely. The graph had a loop. The loop had no floor.
This is a structural problem, not a prompt problem. And it is more common than most LangGraph tutorials acknowledge. A bug documented across community threads describes exactly this: an agent repeatedly calling the same node or tool without processing the output or routing to a terminal state. The loop looks intentional from the outside. It is not. It just never had a reason to stop.
What the Graph Looked Like Before
The broken version was logically reasonable. A generation node produced output. A validation node assessed it. If the output passed, it routed to END. If it failed, it routed back to the generation node to try again.
Nothing in that structure is wrong on paper. The problem was what happened when the validation node kept returning “fail.” There was no counter. No cap. No fallback. The graph just kept cycling.
Before — broken flow pattern:
validate_node → [PASS] → END
validate_node → [FAIL] → generate_node
# No retry counter. No max attempts. No exit on repeated failure.
The graph was technically valid. It ran without throwing an exception. It just never terminated on failure paths. And the API was billing for every token generated in every loop iteration.
The 30-Second Loop Liability Audit
- The Spinning Meter: An infinite validation loop isn’t just a slow agent—it’s an open credit line for your API provider. If your agent runs for 4+ minutes without output, you’re losing money on silence.
- Semantic Deadlock: Why a model can satisfy the prompt but fail the validation logic indefinitely, and why “prompt-only” fixes never stop the loop.
- The Manual Kill Habit: Calculate the labor cost of team members manually restarting or killing stuck processes. That invisible labor is a direct hit to your automation ROI.
- Deterministic Safety: Moving from “hoping the model stops” to a hard, state-based retry counter that terminates on your terms, not the model’s.
The Fix: State-Based Retry Counter
The correction is not complicated. It feels obvious in retrospect, which is how all structural bugs feel after you find them.
Add retry_count and max_retries to the graph state. Increment the counter inside the validation node each time it routes back. Check the counter before routing. When it hits the cap, exit to a fallback state instead of looping again.
After — corrected flow pattern:
state = {
“output”: None,
“retry_count”: 0,
“max_retries”: 3
}
# Inside validate_node
if validation_passes(output):
return {“next”: “END”}
elif state[“retry_count”] >= state[“max_retries”]:
return {“next”: “fallback_node”}
else:
return {
“retry_count”: state[“retry_count”] + 1,
“next”: “generate_node”
}
Three retries capped. Fallback node handles graceful degradation — log the failure, return a partial result, flag for human review. The graph now has a physical kill-switch baked into state. It cannot loop past the cap regardless of what the model produces.
The key word is physical. This is not a prompt instruction telling the model to stop. It is a hard structural condition in the graph logic itself. The model does not get a vote on whether to keep trying.
The Scenario That Makes This Real
Consider a content validation agent. Input is a draft. The validation node checks for tone, length, and keyword presence. If any check fails, it routes back to the generation node with feedback.
The assumption was that the model would self-correct within two or three passes. That assumption held in simple tests. It broke on edge cases where the generation node kept producing output that technically satisfied the prompt but failed the validation heuristic — a mismatch between what the model understood as “correct” and what the validation logic expected.
Without a retry cap: the graph ran indefinitely. API usage climbed. No output returned to the caller.
With the retry counter capped at 3: on the fourth failed validation, the graph routes to a fallback node that returns the best available draft with a flag. The caller gets something. The API call terminates. The bill stops.
Without cap: Loops indefinitely, API runs until timeout or manual kill
With retry cap (3): Exits to fallback after third failure, returns partial result
Business effect: Bounded API cost per invocation, predictable behavior at scale
Without cap: Timeout or hanging request, no output
With retry cap: Flagged draft returned, reviewable by human
Business effect: Human review replaces silent failure, no invisible data loss
Without cap: Difficult to trace — no exception thrown, no state record
With retry cap: retry_count in state gives exact loop depth at failure point
Business effect: Faster root cause identification, less guesswork
The Profit Angle
An infinite validation loop does not look like a bug. It looks like a slow agent. Someone on your team is probably waiting it out, restarting it manually, and not telling anyone — because it feels like their problem to manage.
That invisible restart habit is your real automation cost. It compounds every time the agent runs without a kill-switch.
Where the Retry Counter Actually Breaks
This fix has a specific failure mode that is worth naming before you ship it.
A retry counter stops the loop. It does not fix what caused the loop. If the generation node is structurally incapable of producing output that satisfies the validation logic — because the validation criteria are miscalibrated, or the model is consistently misreading the instructions — the counter will hit its cap on every single invocation.
At that point, the fallback node is not a safety net. It is the permanent exit path. The agent is effectively broken, but it is broken quietly, returning flagged drafts instead of looping. That is better than an infinite loop. It is not a solved problem.
The retry counter is a physical safety break, not a quality fix. It protects the API bill and gives you observable failure data. It does not repair the mismatch between generation and validation logic. That requires a separate diagnostic pass on the validation heuristic itself.
If your fallback node is firing on most runs, the retry counter did its job. The problem is upstream.
What This Does Not Solve
- Prompt-level misalignment. If the generation prompt and the validation criteria are fundamentally mismatched, capping retries surfaces the failure faster but does not resolve it.
- Tool call loops. If your agent is looping on tool calls rather than validation routing, the fix requires conditional edge logic around tool output processing, not just a state counter. The counter still helps, but the root cause is different.
- LangGraph’s native RetryPolicy. The built-in
RetryPolicyin LangGraph handles node-level transient errors like network failures. It is not designed for semantic validation loops. Do not confuse the two. A state-based counter handles semantic failure. RetryPolicy handles infrastructure failure. - Multi-agent loops. If the looping behavior spans multiple agents passing state between graphs, a single counter in one graph’s state will not capture the full cycle. Each agent boundary needs its own stop condition.
The Minimal Graph Fix, Assembled
For readers who want the corrected structure in one place without the narrative, here it is stripped down:
“retry_count”: int = 0
“max_retries”: int = 3
# 2. Validation node logic
def validate_node(state):
if passes_validation(state[“output”]):
return {“next”: “END”}
if state[“retry_count”] >= state[“max_retries”]:
return {“next”: “fallback_node”}
return {
“retry_count”: state[“retry_count”] + 1,
“next”: “generate_node”
}
# 3. Fallback node
def fallback_node(state):
return {
“output”: state.get(“output”),
“status”: “max_retries_exceeded”,
“next”: “END”
}
The status field matters. When max_retries_exceeded appears in the output state, downstream systems can route it to a human review queue instead of treating it as a clean result. The loop is stopped. The failure is visible. The bill is bounded.
Every autonomous loop needs a physical kill-switch. Not because the model will always fail — but because when it does, you need the graph to stop on your terms, not the API’s.
If you want the full workflow breakdown — including fallback node patterns, state schema templates, and how to route flagged outputs to review queues — join the list. The setup notes go out to subscribers.
Get the LangGraph retry pattern notes.
Subscribers get the state schema template, the fallback routing pattern, and the next workflow breakdown — before it publishes. No pitch, no filler.
Before You Go
An agent that loops without stopping is not a smart agent. It is an open meter. The retry counter does not make the agent smarter — it makes the bill predictable, which is the part that actually matters in production.