I got tired of watching AI agents burn money, so I built a runtime kill switch.
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 were

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.
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.
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:
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.