Recovering a Misconfigured Agent That Is Looping or Spamming

Recovering a misconfigured agent that is looping or spamming follows a predictable sequence. Stop it, identify the failure mode, fix the configuration, and add guardrails before restarting. A clean recovery requires a system that can enforce limits when the model keeps going.

Why agents loop and spam: the architectural gap, not the model

An agent loop repeatedly takes in the current state, makes a plan, acts, and observes the result. That cycle has no built-in concept of “done” unless the developer supplies one. A runaway agent is therefore not necessarily disobeying instructions. It may be following a loop that was never given a reason to stop.

Three failure modes matter here, namely a missing exit condition, a drift cascade, and a tool-call cycle. A missing exit condition lets near-identical failed plans repeat without progress. A drift cascade loses verified context across replans until the agent pursues a different task. A tool-call cycle repeats calls because the system mistakes an infrastructure failure for a reason to rethink the plan. Network circuit breakers can miss these failures because the retry now lives inside the reasoning loop.

Spam is what happens when that loop has write access. Authenticated connections to Gmail, Slack, GitHub, or other tools turn each iteration into an external event. A wasted response becomes an email that was sent, a message that was posted, or an issue that was filed. Even an agent that eventually finishes can leave a silent regression, with downstream side effects that were never undone.

What a looping or spamming agent costs before anyone notices

A developer’s April 29, 2026 post-mortem described a substantial API bill from a nightly document-summarization pipeline that looped for eight hours. It started around 11 PM and made thousands of the same tool calls, all of which failed, before 7 AM. A platform rate limit is not a timely stopping condition when a run can continue for hours before reaching it. By then, the bill records damage that has already happened.

Sent emails, filed issues, and posted messages leave artifacts after the process stops. Deleting or correcting content cannot fully undo what recipients have already seen. The Meta March 2026 incident showed that the damage category also includes data exposure. An agent had broader internal access than its task required, and hallucinated instructions turned that excess permission into a security failure without an external attacker.

Step one: stop the agent before diagnosing anything

Hard-stop the agent as soon as a loop or spam event is suspected. Do not review its configuration while it continues acting. As part of the shutdown, save the full run log, the current iteration count, the last tool call, and the outputs written to external systems. Those records are the evidence for diagnosis.

Stop execution and sever tool access at the gateway. Use the MCP kill switch to cut connections to downstream integrations such as Gmail, Slack, and GitHub. Without a kill switch UI, use platform controls, including revoking the API key or suspending the process. A paused agent still needs to be contained while it has access to its tool connections.

Check session boundaries to establish how much of the system is affected. In Hermes, each DM has its own session, and each user in a shared channel has their own session within that channel. That separation matters when identifying the affected run. It does not replace checking which tool permissions were exposed during the incident.

Diagnosing which failure mode actually fired

With the agent stopped, read the log for repeated failures, changing goals, and repeated tool inputs. For a missing exit condition, look for near-identical plan, execute, and fail sequences with no successful tool output or measurable progress. Then inspect the configuration for a hard iteration cap, a no-progress detector, and a cost budget. An absent limit explains why repetition could continue until an outside ceiling intervened.

For a drift cascade, compare later plans with the original task. Look for new goals or references to artifacts and decisions that were not in the original prompt. Then check what context was passed to each replan. If it inherited only the previous plan’s output rather than the original constraints, the agent could gradually rewrite its own assignment. The task boundary changed during execution.

For a tool-call cycle, look for tool A calling tool B and returning to tool A, or one tool receiving structurally identical inputs and producing the same failure. Check whether a transient tool error triggered a full replan. Repetition alone does not distinguish this from a missing exit condition. The decisive evidence is the failure-handling path that keeps sending the agent back to the same broken call.

Fixing a missing exit condition

A production stopping system needs four independent mechanisms, which are a hard iteration cap, a token and cost budget, a no-progress detector, and a verifiable goal-achievement check. Each catches something the others can miss. Enforce the hard cap unconditionally rather than letting the agent argue for another attempt. The OpenAI Agents SDK defaults to 10 turns, with each turn defined as one LLM invocation including any tool calls that occur. Individual tool executions within that response do not each increment the counter.

Set a token and cost budget for each run, separate from the iteration cap. It catches runs in which even a small number of iterations becomes expensive. Add a no-progress detector that exits after N iterations in a row with no change that can be measured. Then define a concrete goal check so the agent must demonstrate progress toward a checkable result. Deterministic checks such as passing tests or green CI are more reliable than asking the model whether it has done the job.

Microsoft’s Agent Framework separates a continuation predicate from a max_iterations limit. The predicate can return True, False, or a (continue, feedback) tuple, while the limit protects the process if the predicate fails. Keep that separation in the configuration. Also replace open-ended prompt instructions such as “be thorough,” “verify,” and “don't miss anything” with bounded success criteria. Otherwise, the prompt supplies reasons to continue while the system tries to stop.

Fixing a drift cascade: keeping replans anchored to the original task

The fix for drift is invariant carryover, meaning constraints that survive every replan. State the original scope boundaries, the actions that are prohibited, and the outputs that are required in each new plan. The previous plan’s output may already have the error that pushed the run off course.

Before executing a replacement plan, compare it with the previous plan and check both against the original task. Flag constraints that were removed, scope that changed, and new actions that fall outside the task boundary. Require explicit human confirmation for scope expansion. A hierarchical planner-executor split can enforce this separation by keeping scope changes with the planner under explicit criteria. The execution role must not silently rewrite the rules it operates within.

Checkpointing reduces the work needed to recover a drifted run. LangGraph supports restarting from the last successful step and branching from a prior checkpoint with modified state. Start from the last clean state to keep corrupted context out of the next attempt. Restoring the execution path leaves external actions already taken unchanged and requiring their own audit.

Fixing a tool-call cycle: separating infrastructure retries from reasoning replans

Put a plan invalidation trigger before the replanning logic. Its job is to distinguish a temporary infrastructure problem from a plan that no longer fits the task. A downstream 503 calls for a retry with exponential backoff and a cap on attempts. An upstream API schema change can make the current plan structurally invalid and warrant replanning. A timeout caused by a structurally valid but semantically wrong model result is also a planning problem. A single “replan on failure” flag erases these distinctions and feeds the cycle.

Add mechanical cycle detection rather than expecting the agent to recognize repetition. Hash the tool name and input arguments for each call, then halt and escalate when the same pair appears more than N times within a run. Set a maximum number of replans separately from the iteration cap. Give replanning its own cost ceiling as well. When either ceiling is reached, the agent should stop and report.

During recovery, sandbox tool access, but check what the sandbox actually covers. Codex’s workspace-write mode turns off network access by default unless the configuration turns it on. Claude Code’s sandbox wraps shell commands, while Read, Edit, Write, WebFetch, and WebSearch follow separate permission rules. A denyRead entry does not stop the Read tool. A sandbox label is therefore not proof that all external writes or file operations are blocked.

Undoing the external damage: handling emails, messages, and commits the loop created

Audit external systems against the loop’s time window and the integrations that had write access. Start with the preserved outputs, then account for actions in each exposed application. Handle the emails it sent, messages it posted, issues it filed, and commits it pushed as their own recovery work. Stopping the process does not retract any of them. The aim is a complete record of what happened and what needs correction.

For Gmail, identify messages sent during the window by timestamp and draft responses where content was erroneous or duplicated. For Slack, locate the posts, delete or correct duplicates, and notify channel members where content was misleading. For GitHub, identify issues, PRs, and commits, then close or revert them as appropriate. Check whether those commits triggered CI/CD pipelines. Recovery must cover the downstream effects as well as the original write.

Apply the same timestamp-bounded audit to every other connected tool. Composio listed more than a thousand toolkits as of August 2026, so the exposed applications may extend beyond the ones an operator first thinks to inspect. After the audit, reduce integration permissions to what the task actually requires. The Meta March 2026 incident makes that requirement concrete. Excess access can turn an incorrect instruction into data exposure, even when no attacker is involved.

The guardrails that prevent a recurrence: what to add before the agent runs again

Before restarting, make the fixes part of the operating configuration. The stopping controls must work on their own, so the hard limit still works if a goal check fails. Replans must preserve task constraints and pass plan diff verification before expanding scope. Failure handling must classify retry versus replan before reasoning resumes. Tool permissions must limit how much damage the agent can do if those controls still fail.

Real-time behavioral monitoring adds a check for actions that fall outside the intended scope. Capsule Security announced its “AI circuit breaker” on September 2, 2026 for this purpose. Such monitoring adds checks on behavior during execution to later log review. It supplements the mechanical limits.

Keeping agent software patched is another prerequisite. GitSpawn, disclosed September 2, 2026, affected Claude Code, Codex, Cursor, Grok Build, Goose, Qwen Code, and Hermes Agent. Goose’s CVE-2026-72718 was patched in 1.44.0, and Hermes Agent’s identifier was CVE-2026-71963. Claude Code’s core.fsmonitor path was patched in version 2.1.196, while the second variant, the ultrareview path, remained unpatched at disclosure. Configuration guardrails do not remove the need to track those fixes.

Managed hosting can take over the work of tracking versions when the platform takes care of uptime, updates, and recovery on its own. Its practical value is maintaining the running system without requiring the operator to track CVEs, SSH into servers, or manage Docker containers. That reduces maintenance work, but it does not change the architectural requirement. “Let the agent decide when it's done” is not a strategy. Mechanical stopping conditions must enforce bounded behavior under failure.