Runaway Agent Loop Detection and Cost Circuit Breakers

A runaway agent loop is an infrastructure failure, not a bug in application logic. The only reliable place to stop one is in the execution path itself, at the gateway layer, where a spending policy can be enforced before a request ever reaches a model provider. For enterprise teams comparing options, the shortlist comes down to a few patterns: self-hosted open-source gateways for teams that want full control over the enforcement code, and managed gateways like Concentrate for teams that want per-key spend limits, audit logs, zero data retention, and provider failover running on day one without building any of it. The rest of this piece explains why that split exists and what each layer of control actually has to do.

Why LLM Agents Fail Differently from Other Software

A person using a chatbot sets the pace. Agents remove that person from the loop by design. An agent calls the model, reads the response, takes an action, and calls the model again, often hundreds of times in a single run, with no person checking in between to decide whether the next call is worth making.

That loop gets more expensive as it runs, not less. Some frameworks even let agents escalate to heavier, more expensive models mid-run when a lighter model isn't working, and if no human is watching, nothing stops that escalation from happening over and over.

Those are the mechanical reasons agent costs climb. A separate body of research shows the loop itself can be a target. Research on termination poisoning (arXiv:2605.05846, May 2026) looks at attacks where someone injects malicious content into an agent's context so it corrupts the agent's judgment about whether a task is finished. The agent keeps believing the work isn't done when it actually is, so it keeps looping. The vulnerability sits in the agent's self-evaluation step: agents judge their own progress using signals pulled from web pages, documents, and API responses, and every one of those inputs can carry a hidden prompt injection. Across 8 mainstream agents, this technique produced a substantial increase in step count over normal execution length, with the worst case reaching roughly 25 times. A runaway loop, in other words, isn't always a coding mistake. It can be something done to the agent on purpose, and the agent's own code cannot tell a bug from an attack.

Why in-agent controls cannot reliably stop a runaway loop

The obvious fix is to have the agent track its own spending and stop itself once it hits a limit. That fix doesn't hold up, because any check written into the agent's own code is a check the agent can fail to run.

A budget check inside the agent is just more code executing inside the same process that might be stuck, buggy, or actively manipulated. A gateway that enforces the budget before forwarding the request removes that possibility, because the agent cannot make an LLM call that violates the policy. That's the structural difference between a suggestion and a rule. Telling an agent, through its system prompt, to stop after spending a certain amount is a request written in prose, and an agent convinced it's one step from finishing a task will often push past that kind of instruction. Real enforcement has to be code sitting outside the agent's reach, not language inside its context.

Termination poisoning makes the self-check approach even weaker. An agent whose judgment has been corrupted by a malicious injection won't honor a ceiling it set for itself, because it has already rationalized its way past the belief that the task is complete. Asking a compromised agent to police its own spending is asking the compromised component to also be the safeguard.

Dashboards don't close this gap either. A dashboard records what already happened. It's useful for understanding a loop after the fact, but it can't stop one in progress, and a spend graph checked the next morning offers no protection against a loop that already burned through a budget overnight. The same problem applies to webhook-based alerts: they fire once a spending threshold is crossed, notify someone, and just hope the agent pauses on its own. A notification isn't an enforcement gate. An enforcement gate has to run synchronously, before the next API call goes out, not after the fact.

This is the same logic behind a Unix process limit like ulimit. Nobody waits for a process to consume all available memory and then kills it afterward. The ceiling gets set at the operating system level before the process can exceed it. Loop control for agents needs the same placement: before the call, not after the damage.

The five enforcement mechanisms that belong in the execution path

Containing a runaway loop reliably takes five layered controls, not one. Each layer catches a different failure mode that the others miss, and all five have to run before the API call goes out, not after it returns.

The five layers are per-request ceilings, per-session rolling budgets, per-key monthly caps, model-tier routing, and circuit breakers.

A per-request ceiling limits how much a single response can cost. Paired with an input ceiling, it bounds the maximum possible cost of any one step in the loop, so a single call can't blow past expectations even if everything else fails.

A per-session rolling budget is the most effective single control against a runaway loop. It caps total spend across an entire agent run, so a stuck agent cannot burn past that ceiling no matter how many iterations it attempts. It doesn't matter if the loop runs ten times or ten thousand times: the session ceiling holds.

A per-key monthly cap adds attribution on top of enforcement. An org-wide spending cap can tell you that something went wrong, but it can't tell you which project, team, or agent caused it. Capping spend per key means every dollar spent is traceable to the key that spent it.

Model-tier routing stops an agent from escalating, on its own, to a more expensive model mid-run without permission to do so. Without this control, a cost-conscious deployment can still see its bill spike because an agent decided, on its own, that a heavier model might solve a problem a lighter one couldn't.

The circuit breaker catches what a budget ceiling misses: speed. A budget ceiling tracks the total amount spent. When spending accelerates past that rate, the breaker trips, and that stops an infinite retry loop from producing a catastrophic bill before the total budget ceiling would even have caught it. Applied to token spending, the same idea prevents a runaway process from spending its way through a budget faster than any human could notice.

When a circuit breaker trips, the agent's current task state should be written to persistent storage before anything gets blocked, so the run can be reviewed and resumed by a person rather than simply erased. Without that record, the only sign that anything went wrong is the number on the invoice.

What ties all five layers together is the enforcement gate itself, which sits between the orchestrator and the model API client. The budget check runs first, then the rate check, then execution. If a check fails, it blocks the step and logs an event before a single token gets consumed. That gate has to be synchronous. A check that fires a webhook after the fact is a notification, not enforcement, and the distinction matters because policy defined centrally, enforced by the gate, can be adjusted without ever touching the agent's code.

Why the gateway is the correct layer for these controls

The gateway is the only point in an agent's execution path that sits outside the agent's own code, shows up on every single request no matter what framework built the agent, and can't be skipped by the agent itself. That combination is what makes it the right place for these five controls to live.

An agent can skip a check written into its own logic. It cannot skip a check enforced by the network layer it has to pass through to reach the model provider. That's the core structural reason the gateway wins the argument: the gateway sits in the path, not inside the agent's own reasoning process, so there's no way for a stuck, buggy, or compromised agent to route around it.

The same layer that enforces spending limits is also the natural place to handle provider fallbacks, PII redaction, audit logging, and role-based access control. None of that needs to be built as a separate system. If you put a unified API gateway between your application and its model providers, it can enforce per-request, per-session, and per-key spend limits before any call reaches the model, so even a compromised agent has no path around the ceiling. Governance is the same gateway layer doing more of what it already does.

Routing decisions and resilience decisions turn out to be the same decision made at the same layer. The same piece of infrastructure enforcing a loop budget is also the piece keeping the agent online during an outage. Neither function requires its own separate system.

Observability at the gateway matters for a different reason than people sometimes assume. It doesn't replace pre-execution enforcement, but it is what makes a real post-incident review possible. Structured inference logging at the gateway turns raw request traces into data that can actually be queried: a cost team can pull token consumption broken down by project, a security team can audit every prompt and response that passed through, and a compliance team can confirm that PII masking fired on every external call. None of that visibility exists when each application manages its own connection to a model provider directly, because the relevant data ends up scattered across separate provider dashboards and has to be pieced back together from invoices at the end of the month. Concentrate exposes spend in real time broken down by organization, team, key, model, and provider, alongside usage by project and user, with request logs that can be filtered by status, latency, tokens, cost, model, and provider.

Gateway-enforced controls in an agentic deployment

Moving these five controls to the gateway collapses what would otherwise be separate implementation work for every agent and every framework into one configuration surface that the agent code never has to know exists.

You can set per-key spend limits and per-session token ceilings directly in the gateway. The agent's code simply points at the gateway's base URL and sends requests the way it always would. No budget-tracking logic needs to be written inside the application. Concentrate's approach to this is to issue a Universal API key, attach a spend limit and an access policy to that key, and apply those controls to every request made through it, regardless of which agent framework generated the request. The policy lives one layer below the framework, enforcing spending limits regardless of which framework generated the request.

Team workspaces extend this by mapping individual keys to individual owners. If a different agent, team, or project gets its own key with its own ceiling, that solves enforcement and attribution in the same step, so you don't need two separate systems tracking spending and ownership apart. Alerts monitoring balances, key limits, error spikes, and unusual spend patterns run in real time, rather than getting reconstructed from a report pulled together after the fact.

PII redaction and zero data retention work the same way: as features of the routing layer, present for every request from the start, rather than something bolted on after an agent has already sent sensitive information somewhere it shouldn't have gone. Retrofitting this kind of control after a system is already in production is expensive and slow, because every existing integration has to be revisited. If you build it into the gateway from day one, it's already there, covering agent traffic along with everything else running through the same key.

This matters because the failure mode isn't abstract. Writing plain-text prompts containing PII or PHI into an unencrypted log store creates a fresh regulatory violation on top of whatever cost problem triggered the logging. The same gateway stopping a runaway loop from draining a budget prevents that separate class of compliance failure.

Configure fallback chains once at the gateway, and they apply automatically to every agent request that passes through it. For a long-running agentic task, a mid-run provider outage without that kind of fallback can corrupt the entire run's state, which turns an infrastructure hiccup into a wasted execution.

The build-vs-buy decision for gateway-layer loop controls

Teams weighing these controls eventually ask whether to self-host a gateway or use a managed one, and the honest answer depends on what the engineering team actually wants to own.

If a team self-hosts gateway software, it gets full control over the enforcement code, the deployment, and the infrastructure it runs on. None of that work is optional once a self-hosted gateway becomes the single point every request has to pass through. If it goes down, every agent behind it goes down too.

A managed gateway shifts that operational burden off the engineering team. Concentrate's model gives a team per-key spend limits, per-session ceilings, PII and PHI redaction, zero data retention, audit logs, and provider fallback chains without requiring anyone to patch, scale, or maintain the gateway software itself. For a team whose core product has nothing to do with running gateway infrastructure, that distinction tends to decide the question on its own: the five enforcement layers described earlier still need to exist somewhere, and the question isn't whether to build them, but whether to build and maintain them in-house or point agent traffic at a system that already runs them.