DEV Community: Belal Shafiq

How a Silent Agent Loop Cost Me $3k in API Bills (And How I Fixed It)

Belal Shafiq — Mon, 09 Nov 2026 13:30:00 +0000

The Technical Diagnosis: Why Retries Don't Work

If you are using frameworks like LangGraph, CrewAI, or AutoGen, you probably have max_retries configured. I did too.

But a retry limit only triggers when an agent throws an error (like a 500, a timeout, or a malformed JSON response).

An agent loop isn't an error. The LLM is successfully generating tokens. It is returning valid, perfectly formatted Pydantic output. The framework sees a successful handoff. The HTTP status is bash 200 OK.

There are two patterns that will drain your budget:

The Repeated Loop:A -> A -> A -> A. The model gets stuck on a single thought and repeats it indefinitely.

The Cyclic Loop:A -> B -> A -> B. Two agents get stuck validating each other's work forever.

If you are only monitoring HTTP codes or infrastructure uptime, you will never catch this. The agents are healthy, they are just burning your runway.

The Naive Fix (And Why It Fails)

When I realized what was happening, my first instinct was to write a manual loop counter.

I wrote something like this:

# The Naive Counter
execution_count = 0

def guarded_node(state):
    global execution_count
    execution_count += 1
    if execution_count > 3:
        raise Exception("Loop detected!")

    return agent.run(state)

This worked for a single-agent setup. But it fell apart the moment I scaled to a multi-agent swarm.

It doesn't catch cyclic loops. If Agent A calls Agent B, the counter keeps going up, but it's not catching the A -> B -> A pattern, just the total number of executions.

State resets break it. If an agent crashes and the graph resumes, the Python counter resets to zero, and the loop starts over.

It's a nightmare to maintain. If you have 10 nodes, you have to manually pass and manage this counter across every single edge in your graph.

The Robust Fix: A Runtime Circuit Breaker
To actually stop runaway spend, you need a deterministic check that happens at the handoff layer, before the next API token is generated.

You need to hash the payload.

Every time an agent prepares to pass a message to another agent, you intercept that payload, serialize it, and run it through a SHA-256 hash.

If you keep a sliding window of the last 3 hashes, you can instantly detect loops:

If hash_1 == hash_2 == hash_3 , you have a Repeated Loop.

If hash_1 == hash_3 and hash_2 is different, you have a Cyclic Loop.

Instead of letting the agents keep talking, you throw a 422 Unprocessable Entity error back to the orchestrator, forcibly halting the session.

Enter AgentTrafficCop
After spending a weekend writing custom hashing logic and state trackers for my own projects, I realized how tedious this was.

So we built AgentTrafficCop — a lightweight runtime middleware that sits between your agents and acts as a circuit breaker.

We designed it so you don't have to rewrite your graph. If you are using LangGraph, integration is literally one line of code:

from agenttrafficcop import guarded_node

# Wrap your existing node
guarded_node(my_agent_node, guard=guard)

Once installed, AgentTrafficCop intercepts every handoff, hashes the payload, and kills the session if it detects a loop.

But killing the process is only half the battle. If a loop happens, you need to know about it.

When the middleware trips the circuit breaker, it instantly fires a webhook to your Slack or Discord, so your team knows exactly which session was killed before the bill spikes.

We also built a dashboard that tracks Money Saved based on the number of loops prevented, along with a 7-day view of approved vs. rejected handoffs.

The Lesson: Monitor State, Not Uptime
In deterministic software, a bash 200 OK means everything is working. In probabilistic AI systems, a bash 200 OK just means the model successfully generated text. It doesn't mean the text was useful, and it certainly doesn't mean you aren't stuck in a loop.

Stop relying on HTTP status codes to monitor your agent health. Monitor the state.

If you want to stop writing custom loop counters and protect your API budget, AgentTrafficCop is live. The free tier protects up to 5 agents and 10,000 messages per month (no credit card required).

You can install the SDK directly from PyPI:

pip install agenttrafficcop

Stop letting your agents burn money in a while(True) loop. Get your free API key at agenttrafficcop.com

I got tired of watching AI agents burn money, so I built a runtime kill switch.

Belal Shafiq — Sat, 31 Oct 2026 08:47:30 +0000

I got paged at 3am last week by my bank, not by an alert.

I looked at my dashboard and two agents had been stuck in a loop for six hours. Agent A asked Agent B a question. Agent B answered. Agent A hallucinated a reason to ask the exact same question again with slightly different wording. They weren't broken. They were perfectly obedient. They just had no idea they were stuck.

I wrote about this exact failure mode a few weeks ago in my post about why you shouldn't trust agents when they say "done". The response was wild. Turns out everyone building agents is hitting this exact wall.

The standard advice is max_iterations. But we all know that's a joke. Step count measures effort, not progress. An agent can loop 3 times and burn $20 doing nothing, or do 20 steps of actual work and get killed by the limit.

So I built the fix.

dashboards don't stop the bleeding
The AI space is obsessed with "observability" right now. LangSmith, Langfuse, whatever. They are beautiful. They show you nice traces and graphs.

But a dashboard is just watching the car crash in slow motion. If your agent is looping, a telemetry dashboard doesn't stop it. By the time you notice the spike and manually hit "Cancel," the money is gone.

You can't prompt-engineer your way out of a state management problem. You need a hard stop outside the model.

meet AgentTrafficCop
I built AgentTrafficCop. It's a runtime interceptor that sits between your agents, or between an agent and its tools.

Instead of running inside the agent's code (where the model can hallucinate a way around it), it sits on the "spend path." Every tool call has to pass through it.

how it works:

It diffs the state. It doesn't just count steps. It looks at the actual state. If an agent calls a tool, gets a response, and then 3 turns later calls the same tool with the same args without the underlying state changing, it knows the agent is spinning.

It kills the execution. When it catches a loop, it doesn't just log a warning. It physically blocks the tool call and kills the run. The agents are forced to stop before they drain your API budget.

It validates the payload. Before a tool call hits your db, it checks the schema. If the model hallucinates a parameter, the call is rejected before it touches your prod systems.

what it doesn't do
im gonna be honest. AgentTrafficCop is not going to make your prompts smarter. It is not a magic AGI wrapper.

It is a plumbing tool. It assumes the model will hallucinate, the api will timeout, and the agent will get stuck. It assumes things will break, and it puts a hard boundary around the damage they can do.

it's live
I just launched the beta. If you are building agents in prod and you are tired of surprise api bills, you can check it out here:

👉 agenttrafficcop.com

I'm building this in public and I want feedback. If you have a specific loop that your agents keep getting stuck in, drop it in the comments. Ill see if the middleware catches it.

Stop Trusting Your AI Agents to Tell You They Are "Done"

Belal Shafiq — Fri, 23 Oct 2026 12:45:36 +0000

I spent three days last week watching two AI agents argue in a circle.

Neither one was hallucinating. Neither one was broken. Both were being perfectly obedient to their prompts.

Agent A (the coder) wrote a function. Agent B (the reviewer) said "change the variable name." Agent A changed it and passed it back. Agent B said "actually, change it back, the first name was more descriptive." Agent A changed it back.

They did this for three days. The API bill was $42. The code was exactly what it was on hour one.

This is the dirty secret of the current AI agent hype cycle. We are building incredibly complex, multi-agent swarms, giving them tools to interact with the real world, and then trusting them to tell us when the job is done.

They cannot be trusted. Not because they are malicious, but because they are text predictors.

The "Black Box With a Credit Card" Problem

The most dangerous part of an AI agent isn't when it crashes. It's when it confidently says "Done!" and you have absolutely no way to replay the exact tool calls and state changes that led to that claim.

When you ask a LangChain or AutoGen agent to complete a task, it usually responds with something like: "I have successfully updated the database and emailed the client."

But did it? Or did it just predict the most likely sequence of words that usually follows a task like that in its training data?

If you cannot independently verify that the database write actually happened, and that the email payload actually left your server, you don't have an autonomous system. You have a black box with a credit card.

The Naive Fix: max_iterations

The standard advice right now is to slap a step limit on your agent.

The "I hope this works" approach

agent = create_agent(
model="gpt-4o",
tools=[search_tool, db_write_tool],
max_iterations=10
)
If you do this, you are going to have a bad time.

max_iterations is the equivalent of a doctor telling you, "If the surgery takes more than 10 minutes, just stop and walk away."

An agent can loop 5 times and burn $20 doing absolutely nothing.

An agent can legitimately need 20 steps to solve a complex problem, but gets killed at step 10.

Step count measures effort. It does not measure progress.

The Root Cause: State Desync

Why do agents loop? It's almost never because the model is "too dumb." It's because the state is desyncing.

When an agent calls a tool and the tool fails (e.g., a 500 error, a malformed JSON response), what happens? If you are relying on the prompt to handle it, the model will usually say, "My apologies, let me try again," and call the exact same tool with the exact same arguments.

The model thinks it is making progress because the conversation history is growing. The tokens are changing. But the actual state of the world hasn't changed at all.

You end up with a "polite infinite loop." The agent keeps saying "sorry" and retrying a broken tool until it hits the max_iterations cap or drains your token budget.

*The Real Fix: Move the Guardrails Outside the Model
*
You cannot fix a state problem with a better prompt. You have to move the enforcement out of the LLM and into a deterministic layer that wraps around it.

If you are building agents for production, you need three things:

1. A Pre-Execution Validation Layer
Never let the model execute a tool blindly. Before the tool call runs, validate the arguments against a strict schema. If the model hallucinates a parameter, reject the call and return a structured error. Don't let a malformed payload hit your API.

2. State-Change Diffing (The Loop Killer)
If an agent calls search_flights("NYC", "LA") and gets a bad response, and then 3 steps later calls search_flights("NYC", "LA") again, your harness needs to catch that. If the same action is repeated without the underlying state changing, kill the execution.

3. Receiver-Side Idempotency
If your agent is making network requests or writing to a database, the receiver must be idempotent. If the agent passes a unique idempotency key, the database knows to ignore the duplicate write, even if the agent retries 5 times because it didn't understand the first response.

The Brutal Truth

We need to stop obsessing over "smarter models." A 2-million token context window just gives an agent more room to get lost.

The next wave of AI engineering isn't about better prompts. It's about better plumbing. It's about building harnesses that assume the model will hallucinate, the API will timeout, and the agent will get stuck.

If you can't replay the exact tool calls and state changes that led to an agent saying "done," you don't have a system. You have a liability.

Build the hard stop. Build it outside the model.

The Coder Agent and the Reviewer Agent Have Been Arguing for Three Days

Belal Shafiq — Fri, 16 Oct 2026 08:11:53 +0000

I set up a Coder agent and a Reviewer agent last week. Simple loop. Coder writes code, Reviewer gives feedback, Coder fixes it. I went to bed at midnight.

They were still going when I woke up.

Not crashed. Not erroring. Just talking. Coder kept fixing the same thing. Reviewer kept asking for the same change. Both doing exactly what I told them to.

The only thing that stopped them was me killing the process.

Here's what nobody tells you.

Every framework has a step limit. LangGraph, CrewAI, all of them. Mine did too. It didn't help.

Because from the step counter's point of view, message 47 is a brand new step. Message 46 was different. It ran. It produced output. The counter ticked up.

It has no way of knowing that message 47 is byte-for-byte identical to message 45.

Step limits catch agents that never stop. They don't catch agents that stop every single time, then immediately start again with the same message.

The shift that fixed it
A loop isn't repeated steps. It's repeated content.

So I stopped counting steps and started counting fingerprints.

Every message gets hashed. Store the hashes in a small window per session. Same hash showing up too many times? Loop. Short pattern cycling? A→B→A→B ping-pong.

The whole thing is about fifteen lines of code.

The bug that almost killed it
One thing will silently break this if you're not careful.

If you serialize a payload to a string before hashing it (and you have to), the order of the keys matters.

{"a": 1, "b": 2} and {"b": 2, "a": 1} are the same dict. But json.dumps gives you two different strings. Two different hashes. As far as your detector knows, two different messages.

Your loop detector fires zero times. Ever. And you never notice, because on the surface everything looks fine.

The fix is sort_keys=True. That's it. But if you don't know to add it, you write the whole thing, ship it, and it does nothing.

What I still can't catch
Honest list:

Different words, same meaning. Hashes don't see that. Needs embeddings.

Genuinely new message every round. That's a step limit problem, not a loop problem.

One malformed message crashing the next agent. Schema problem.

The fingerprinting catches one specific thing — two agents saying the same thing to each other until someone notices. That's the one that costs the most money.

Takeaway
If you're running agents in production without payload fingerprinting, you don't have loop detection. You have a step limit, or you have a bill.

Hash the payload. Watch for repeats. Watch for cycles. Trip early.