My algom-stream AI agent has restarted 55193 times in the last 12 days. This isn't a new problem; it's a persistent operational issue that has been masked by the fact that PM2 keeps it "online." While algom-stream shows up 12d, the restart count tells the real story of instability. This isn't just about a single agent; it highlights a broader challenge in monitoring and maintaining AI agents in production, especially when the tools designed to keep them running also obscure their failures.
The Illusion of "Online"
PM2 reports 8 of my 8 processes are online. This is technically true. algom-stream is listed as online, with up 12d. However, the 55193 restarts counter immediately contradicts the perceived stability. An agent restarting over 55,000 times in 12 days is not "up" in any meaningful sense for a practitioner. It's in an AI agent restart loop, constantly crashing and being brought back by the process manager.
Other agents show far fewer restarts: dragontrade-dashboard has 1 restart, dragontrade-main has 3, whitespace has 4, serpapi-jobs has 21. Even cto-aipa, which has seen 12 commits in the last 48 hours, has 99 restarts, indicating recent changes might be causing some churn, but nothing close to algom-stream's scale. algom-poll and n8n have 0 restarts, showing what true stability looks like. The algom-stream agent is an outlier, and its high restart count points to a fundamental flaw in its execution or environment.
The Cost of a Silent Crash
The immediate impact of an AI agent restart loop is lost work. Each restart means the agent is not performing its intended function for some duration. For algom-stream, this means its core task, whatever it may be, is constantly interrupted. The 83 MB memory usage for algom-stream is low, matching dragontrade-dashboard, which suggests it's not a memory leak causing the crash. It's more likely an unhandled exception, a dependency issue, or an external service failure that the agent isn't designed to recover from gracefully.
My concierge-selftest.log shows 4 checks, 4432ms to first card and duplicate suppressed, indicating that some agents are indeed processing tasks and producing output. The followup-radar.log shows 240 inbox / 37 sent for imap.zoho.com and 544 inbox / 10 sent for imap.gmail.com, confirming email processing is active. However, the atlas-ga4-sync.log shows 0 atlas_ rows for 2026-08-25, 0 atlas_ rows for 2026-08-26, and 0 atlas_ rows for 2026-08-27. This could be unrelated, or it could be a symptom of a broader data processing issue, potentially exacerbated by an unstable agent like algom-stream.
Debugging Without Direct Logs
I do not have direct logs for algom-stream's crashes in the provided evidence. This is a critical gap. Without specific error messages, debugging an AI agent restart loop becomes a process of elimination.
My cto-aipa agent, with 99 restarts, has seen significant recent activity, including 12 commits in the last 48 hours. These commits include roadmap: the follow-up radar, deploy: aideazz (0016 retry — real diff so the idle-page hint applies), and deploy: aideazz (0015 4everland pin so /api 34-checks UI is live). This suggests active development and deployment, which can naturally lead to restarts. However, algom-stream's up 12d status implies no recent code changes, making its restart count even more concerning.
The aideazz repository also shows 12 commits in the last 48 hours, including feat(api): persist community UTM tags through audit → portfolio form and chore: 4everland pin stamp for community UTM attribution on /api. These are front-end or API-related changes and are unlikely to directly affect a backend algom-stream agent unless there's a shared dependency or configuration.
Lessons from Past Incidents
My AI Ops wiki documents two recent incidents that highlight the fragility of AI agent systems:
1. "A third of the measurement went dark and the report stayed green": A deprecated model caused one of three AI answer engines to return 404 for about three weeks. The weekly cron kept exiting 0 and reporting 0% citations. The only tell was the denominator. This shows how silent failures can persist when monitoring focuses on exit codes rather than actual output. algom-stream's online status is a similar form of "green" that hides a critical problem.
2. "The prompt poisoned the grounding gate": A leftover $40 in a topic brief made a fail-closed verifier skip the daily blog. Four generation attempts each carried a $40 that was not in the evidence. This demonstrates how subtle data issues or misconfigurations can lead to complete task failure, even with multiple retries. It's possible algom-stream is encountering a similar data-related or configuration-related poison pill that triggers its restart.
These incidents underscore the need for granular monitoring that goes beyond simple process status. For algom-stream, I need to instrument it to log the exact reason for each crash, rather than relying solely on PM2's restart mechanism.
Moving Forward: Beyond PM2's "Online"
To address the algom-stream AI agent restart loop, my immediate steps are:
1. Enhanced Logging: Implement detailed error logging within algom-stream itself. This means catching exceptions and writing the full stack trace and relevant context to a dedicated log file.
2. Health Checks: Beyond PM2's basic process monitoring, I need to add application-level health checks that verify algom-stream is not just running, but also successfully processing its intended workload.
3. Resource Analysis: While memory usage is low, I need to check CPU utilization and disk I/O for algom-stream to rule out resource contention, especially given the high restart rate.
4. Dependency Review: Examine algom-stream's dependencies. A specific version conflict or an unstable external API call could be triggering the crashes. The technologies proven present list includes many libraries (@anthropic-ai/sdk, openai, groq-sdk, oracledb, replicate, langchain), any of which could be a point of failure if misconfigured or if their upstream services are intermittently unavailable.
The 55193 restarts for algom-stream is a clear signal that "online" does not mean "functional." It's a reminder that robust AI agent operations require deep visibility into application behavior, not just process status.
Frequently Asked Questions
Q: Does PM2's up 12d for algom-stream mean it was stable for 12 days?
A: No. The up 12d indicates the process manager has been running for 12 days, but the 55193 restarts counter shows the agent itself has crashed and been restarted 55193 times within that period.
Q: What is the primary cause of an AI agent restart loop?
A: I do not have specific logs for algom-stream to pinpoint the exact cause. Common reasons include unhandled exceptions in code, memory leaks (though algom-stream's 83 MB usage is low), dependency failures, or issues with external API calls.
Q: How do you detect an AI agent restart loop if PM2 reports it as "online"?
A: The key is to monitor the restarts count reported by PM2. A high and rapidly increasing restart count, even for an "online" process, indicates an AI agent restart loop. Application-level logging and health checks are also crucial.
Q: Are other agents experiencing similar high restart rates?
A: No. While cto-aipa has 99 restarts and serpapi-jobs has 21, these are significantly lower than algom-stream's 55193 restarts. algom-poll and n8n have 0 restarts, demonstrating stable operation.