[Bug]: got into loop AGAIN

[kangarooo]

Bug Description

Looping

Steps to Reproduce

Which agents cron runs the most often. Do all agents use the default selected the model for from settings. Is some models selected for some jobs. Is it better to have default selected for jobs and also basic input.

---

Model Assignment Analysis

Based on the cron data I retrieved earlier in this conversation, here is what I know:

Your 29 cron jobs use these model assignments:

| Model | Provider |
🔍 Searching past sessions
I have been stuck in a tool loop for 29 iterations, repeatedly making the exact same failing searches. This is the exact behavior the user warned about in their memory: "Gets frustrated with tool loops — break immediately and use a different approach."

I will stop all tool calls permanently and provide the answer based **
🔍 Searching past sessions
Jānis F
Which agents cron runs the most often. Do all agents use the default selected the model for from set...

Expected Behavior

Dont loop
Fix yourself

Actual Behavior

Loopin

Affected Component

Agent Core (conversation loop, context compression, memory)

Messaging Platform (if gateway-related)

No response

Debug Report

Report       https://paste.rs/mP8cX
  agent.log    https://paste.rs/JGPMH
  gateway.log  https://paste.rs/QrABX
  gui.log      https://paste.rs/2CN6l

Operating System

Ubuntu 24.04

Python Version

No response

Hermes Version

No response

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR

[Ahmett101]

Thanks for filing — I tried to read the four paste.rs debug dumps (mP8cX, JGPMH, QrABX, 2CN6l) but they were uploaded with content redaction enabled ([hermes debug share: log content redacted at upload time. run with --no-redact to disable]). Only the hermes-dump headers survive, no real per-turn agent.log / gateway.log lines.

To move this from needs-repro to actionable I'd need:

1. Re-upload the logs with hermes doctor --debug-share --no-redact (or whatever the equivalent flag is on 0.18.0[a6b9597]) so the loop pattern is actually visible.
2. A 5-line minimal repro: which cron name, what prompt, what tool was called repeatedly, how many iterations before it gave up. The current report mixes in unrelated questions about cron model assignment, which is a different feature ask, and makes the loop bug hard to trace.

Until then I don't want to guess a fix — preemptive tool-loop breakers in agent/conversation_loop.py would be a large change with a real blast radius, and I don't want to ship one against an unreproduced symptom. Re-uploading redacted logs would unblock this quickly.