ai agent email loop detection: how to stop your agent from emailing itself forever
AI agent email loops burn tokens and tank reputation. Here's how loop detection works, four loop types to watch for, and how to stop them before they start.
Last Tuesday, someone in the OpenClaw Discord shared a screenshot of their token dashboard. Their orchestrator agent had burned through $140 in API calls overnight. The cause: two sub-agents replying to each other in a loop, each one interpreting the other's response as a new task. By the time anyone noticed, they'd exchanged 2,300 emails and accomplished nothing.
AI agent email loops are the runaway process of the agent era. They're silent, expensive, and surprisingly easy to trigger. If your agents communicate through email (and in multi-agent systems, they should), loop detection isn't optional. It's the difference between a working system and a billing emergency.
What is an AI agent email loop?#
An agent loop happens when an AI agent receives input, takes action, and produces output that triggers the same (or a reciprocal) action again. In email-based systems, this usually means an agent sends a message that causes another agent, or itself, to send a reply that restarts the cycle.
The classic version: Agent A emails Agent B with a task. Agent B processes it and replies with results. Agent A interprets that reply as a new task and emails Agent B again. Neither agent recognizes the repetition. Both are doing exactly what they were told.
What makes email loops particularly nasty is the async nature of email. Unlike function call loops that spike CPU immediately, email loops can run for hours at a low, steady pace. Each message looks legitimate in isolation. The loop only becomes visible when you zoom out and see the pattern.
How AI agent email loop detection works#
- Hash each iteration. Every time an agent processes an email and produces a response, generate a fingerprint of the (action, result) tuple. This can be as simple as hashing the tool name, recipient, and a normalized version of the content.
- Compare against a sliding window. Store the last N fingerprints (typically 5-10) and check each new one against the window.
- Classify the pattern. Flag exact repeats, ping-pong alternations, semantic near-duplicates, and polling loops where the same query fires on a timer.
- Trigger a halt after N consecutive matches. Three identical fingerprints in a row is a reasonable default. Two is too aggressive (legitimate retries exist). Five is too generous for production.
- Log the halted state. Write the full chain to an audit log so you can reconstruct what happened during post-mortem analysis.
- Escalate or degrade gracefully. Notify a human, fall back to a safe default, or mark the thread as stale so no agent picks it up again.
That's the general model. The specifics depend on which type of loop you're dealing with.
Four types of email loops in agent systems#
Not all loops look the same. Each type needs a slightly different detection strategy.
Exact repeat loops#
The agent sends the same email, with the same content, to the same recipient, over and over. This is the easiest to catch. A simple content hash will flag it within two or three iterations.
Cause: usually a missing state update. The agent checks its inbox, finds the same unread message (because it failed to mark it as read), and processes it again.
Ping-pong loops#
Agent A emails Agent B. Agent B replies. Agent A treats the reply as a new request and emails Agent B again. The content differs slightly each time, so a naive hash won't catch it. You need to track the (sender, recipient) pair and count round-trips within a thread.
Email headers are your friend here. The Message-ID and In-Reply-To headers form a natural chain. If your infrastructure preserves threading (LobsterMail does), you can count the depth of a thread without any agent-side logic. A thread that exceeds 8-10 round-trips between the same two addresses in under an hour is almost certainly a loop.
Semantic repeat loops#
The agent rephrases the same request each time. The content looks different on the surface, but the meaning is identical. "Please summarize the Q3 report" becomes "Can you provide a summary of the third quarter report?" becomes "I need a recap of Q3 results."
Hash-based detection misses these entirely. You need either embedding similarity (compute a vector for each message and flag when cosine similarity exceeds 0.92) or a cheaper heuristic: extract the core action verb and object, then compare those normalized tuples. The second approach is less accurate but costs almost nothing in compute.
Polling loops#
The agent sends a "checking in" email on a schedule, but the schedule fires faster than the recipient can respond. This isn't a logic error per se. It's a timing mismatch that produces loop-like behavior: dozens of "Any update?" messages piling up in an inbox.
Detection: track the ratio of sent messages to received responses per thread. If an agent has sent more than 3 unanswered follow-ups in a single thread, pause the thread and wait for a reply before sending another.
Where should loop detection live?#
There's a real architectural question here: should loop detection run inside each agent, in the orchestrator, or in the email infrastructure itself?
Agent-side detection is the most common approach. Each agent maintains its own sliding window of fingerprints and halts itself when it detects repetition. The downside: every agent needs the same logic, and a buggy agent can disable its own detection.
Orchestrator-level detection works well for hub-and-spoke architectures where one central agent dispatches tasks. The orchestrator can monitor all threads and kill any that exceed depth or frequency thresholds. The downside: it doesn't help with peer-to-peer agent communication.
Infrastructure-level detection is the most interesting option and the least explored. If your email layer tracks thread depth, message frequency per sender-recipient pair, and content similarity across a thread, it can flag or block loops before agents even see the messages. This moves loop detection out of application code entirely.
LobsterMail's audit logs capture every message with full threading metadata, which makes post-mortem loop analysis straightforward. You can trace exactly which message triggered which reply, see the full chain, and identify where detection should have kicked in. For teams building multi-agent email workflows, this is the kind of observability that turns a 3-hour debugging session into a 10-minute one. If you're building agents that coordinate through email, .
The cost problem nobody talks about#
A single email loop doesn't just waste email sends. Each iteration burns LLM tokens (the agent has to read and compose each message), API calls, and potentially tool-use credits. That $140 overnight bill from the Discord story? Most of it wasn't email costs. It was GPT-4 inference charges from 2,300 unnecessary completions.
At roughly $0.06 per completion (input + output for a typical agent turn), 2,300 loops cost $138 in inference alone. The email sends were nearly free by comparison.
This is why loop detection needs to be fast and local. Sending a message to an external service to check "is this a loop?" adds latency and its own costs. A local sliding window with hash comparison adds microseconds.
Practical defaults for production#
If you're setting up loop detection today and want sensible starting points:
- Window size: 5 previous fingerprints
- Halt threshold: 3 consecutive matches for exact repeats, 5 for semantic similarity
- Thread depth limit: 10 round-trips between any two addresses
- Unanswered follow-up limit: 3 per thread before auto-pause
- Timeout: if an agent task hasn't completed in 30 minutes, force-halt and escalate
- Fingerprint method: SHA-256 of (normalized_action + recipient + first_100_chars_of_body)
These aren't perfect. They're starting points you should tune based on your actual traffic. The important thing is having any detection at all, because most agent systems ship with none.
What to do when a loop is detected#
Three options, in order of preference:
Halt and escalate. Stop the loop, log the full thread, notify a human. This is the safest default. The human reviews, fixes the root cause, and restarts manually.
Halt and degrade. Stop the loop, send a final "I've detected a repeated pattern and am stopping this thread" message to the other agent(s), and mark the thread as closed. No human needed, but the task doesn't complete.
Retry with modification. Risky but sometimes appropriate. The agent recognizes the loop, modifies its approach (different prompt, different tool), and tries once more. If the retry also matches the loop pattern, halt immediately. Never allow more than one retry.
The worst option is to do nothing. An undetected loop will run until it hits a rate limit, an account balance, or a very confused human checking their inbox on Monday morning.
Frequently asked questions
What is an AI agent email loop and why is it dangerous in production?
An AI agent email loop occurs when agents exchange messages in a repeating cycle, with each reply triggering another unnecessary response. In production, this burns LLM tokens, wastes email sends, and can cost hundreds of dollars overnight without producing any useful output.
What are the four main types of email loops an AI agent can fall into?
Exact repeat (same message sent repeatedly), ping-pong (two agents replying back and forth), semantic repeat (same meaning rephrased each time), and polling (follow-ups sent faster than responses arrive). Each requires a different detection strategy.
How does hash-based fingerprinting detect agent email loops?
Each agent action is hashed into a fingerprint (typically the tool name, recipient, and normalized content). New fingerprints are compared against a sliding window of recent ones. Three consecutive matches usually indicates a loop.
What is a semantic repeat loop and how does it differ from an exact repeat?
A semantic repeat loop sends the same request with different wording each time. Unlike exact repeats, content hashes won't catch it. Detection requires either embedding similarity comparison or normalized action-object tuple matching.
How many identical fingerprints should trigger a loop halt?
Three consecutive identical fingerprints is a reasonable production default. Two is too aggressive since legitimate retries happen. Five is too generous and allows unnecessary cost accumulation before stopping.
Can loop detection be handled at the email infrastructure layer instead of in agent code?
Yes. Email infrastructure that tracks thread depth, message frequency per sender-recipient pair, and content similarity can detect loops before agents process the messages. This removes the burden from application code and catches loops that individual agents miss.
How do Message-ID and In-Reply-To headers help detect email loops?
These headers form a natural thread chain. By counting the depth of In-Reply-To references between the same two addresses, infrastructure can flag threads that exceed a reasonable round-trip limit (typically 8-10) without needing any agent-side logic.
What happens to cost and token usage when an AI agent enters an email loop?
Each loop iteration burns LLM inference tokens (reading and composing the message), API call credits, and email sends. A 2,300-iteration loop can cost over $130 in inference charges alone, since each agent turn requires input and output token processing.
In a multi-agent system, should the orchestrator or sub-agent handle loop detection?
Both, ideally. The orchestrator should monitor thread depth and frequency across all dispatched tasks. Individual agents should maintain their own fingerprint windows as a second line of defense. Relying on only one layer leaves gaps.
What should an AI agent do when a loop is detected?
The safest default is halt and escalate to a human. A middle option is halting and sending a closure message to the other agent. Retrying with a modified approach is risky and should be limited to one attempt before a hard stop.
How does async email delivery change the loop detection model?
Async delivery means loop iterations are spaced out over minutes or hours instead of milliseconds. This makes loops harder to detect through timing alone. Detection shifts to inbox-level deduplication, thread depth tracking, and idempotency keys rather than real-time execution monitoring.
Can loop detection rules accidentally block legitimate automated email workflows?
Yes. Overly aggressive thresholds (halting after 2 matches) can interrupt valid retries and scheduled follow-ups. Tune thresholds based on actual traffic patterns, and use thread-scoped detection rather than global counters to reduce false positives.
What is a ping-pong loop in an AI agent system?
A ping-pong loop happens when Agent A emails Agent B, Agent B replies, and Agent A misinterprets the reply as a new task. The two agents alternate messages indefinitely. Detection requires tracking sender-recipient pairs and round-trip counts within a thread.
How do audit logs help with post-mortem analysis of agent email loops?
Audit logs that capture full message threading metadata let you trace which message triggered which reply, identify the exact iteration where the loop began, and determine whether detection should have fired earlier. This turns multi-hour debugging into a quick review of the message chain.
What observability tools help trace agent email loops in real time?
Thread depth counters, per-address send rate dashboards, fingerprint match rate monitors, and cost-per-thread tracking all help. The key metric is round-trips per thread per hour. Any thread exceeding your baseline by 3x or more deserves investigation.
