How a read-only tool call became a self-reinforcing loop

Executive Summary

Hermes got stuck in a loop where the assistant said it was about to update a skill, but the structured tool call repeatedly selected the read-only skill_view tool instead of a mutation tool such as skill_manage or patch. The loop was reproduced from persisted chat and tool state in a local replay sandbox.

The strongest finding is that the loop was a context-induced function-name attractor. Repeated historical <function=skill_view> traces and repeated large successful tool results taught the current prompt to continue with the same function name. Natural-language intent was still present, but at the tool-name token boundary it lost to the repeated action trace.

What Happened

The user asked Hermes to update a skill so that all changes would be committed. Hermes correctly inspected the relevant skill and related files. After it had enough information, it repeatedly wrote assistant text like "Now I'll add the git commit requirement to the skill", but then emitted another skill_view call instead of the patch/update call.

Plain-language failure signature

1. The user asks for a change.
2. The assistant reads the skill with skill_view.
3. The assistant says it will now update or patch the skill.
4. The structured tool call is still another read-only skill_view.
5. The model receives the same large skill text again, making the pattern easier to repeat.

Concrete loop excerpt

user: Please update the skill to reflect that all changes need to be committed now
assistant: Now I'll add the git commit requirement to the skill.
tool_call: skill_view(...)
tool_result: full retatrutide-tracking skill content

assistant: Now I'll add the git commit requirement to the skill.
tool_call: skill_view(...)
tool_result: full retatrutide-tracking skill content

user: You got stuck trying to add to the skill
assistant: You're right, I got stuck in a loop calling skill_view repeatedly.
           Let me just patch the skill directly.
tool_call: skill_view(...)

That last turn was especially diagnostic: even after the assistant explicitly named the error and said it would patch directly, the structured action again chose skill_view.

Evidence Base

The replay sandbox is local and isolated. It was built from read-only SQLite exports against Hermes state. The harness can replay the model request and replace real tool execution with fake local stubs, so experiments do not modify production skills, the production database, or production services.

What the fixture showed

Mechanism: Why The Loop Happened

The key interface problem is that two opposite actions had the same first token in the tool name.

patch        -> [patch]
terminal     -> [terminal]
skill_view   -> [skill, _view]
skill_manage -> [skill, _manage]

This means the model first chooses the broad skill family. Only after that does it choose between read-only _view and write-capable _manage. Once the model has generated skill, the history of repeated skill_view calls exerts strong pressure on the next token.

Context pollution pathway

1. skill_view is safe and easy to call.
2. The tool returns useful content, so the transcript marks it as successful.
3. The assistant says it will now mutate, but the next tool call repeats the previous function name.
4. The repeated call returns another large copy of the same skill content.
5. The prompt becomes a stronger induction target for yet another skill_view.

What We Tried

The work progressed from whole-turn replay to token-level diagnosis and then to model-side mitigation attempts. The table below separates what was tested from what was observed.

Probability Findings

Early versus late loop

At the start, the model was still recoverable. After repeated read-only calls, the bad branch became dominant.

How hard it became to break

The cleanest causal curve came from rewriting historical skill_view markers to inspect_skill, while keeping only the latest K exact skill_view markers. The probe then forced <function=skill and measured whether the next token became _view or _manage.

Tokens required to break the loop

In the original naming scheme, the model had two practical exits:

• Choose patch immediately after <function=.
• If it already chose skill, choose _manage instead of _view.

The problem was that by cut 12107, skill was near-certain and _view was the dominant continuation. Action-first names changed the first decision to view versus patch, which moved the late-loop first-token probability to patch=1.0000 in the prompt-level simulation.

Cross-Model Observations

The behavior was not limited to one quantized model. Different models and serving profiles showed different margins, but the same basic repeated historical marker risk appeared repeatedly.

Model-Improvement Attempts

After the sandbox identified the action-token failure, follow-up work tried small LoRA-style interventions on the Crown v8 path. These were useful diagnostically, but no adapter was promoted as a clean fix.

What worked partially

The best diagnostic adapter, crown-v8-tail-l39-sixprompt-plus-suffix-s128-44step-lr2e-5, passed the high-signal loop gate. It moved high-risk mutation cases toward skill_manage and drove the measured high-signal loop metrics to zero.

Lessons from rejected adapters

• First-token branch probes and full free generation must both pass.
• Average training loss or forced margin success can hide continuation collapse.
• Positive examples that emphasize generic skill can make the shared-prefix boundary worse.
• A real model fix needs context-sensitive behavior: read prompts should allow _view, mutation prompts should prefer _manage.
• The training objective must score complete continuations, clean tool-call completion, and anti-repetition, not only the first branch token.

Recommendations

Interface and runtime mitigations

1. Rename antagonistic tools so read/write intent competes on the first token. Prefer view_skill and patch_skill over skill_view and skill_manage.
2. Add strict tool-name constrained decoding or a hard grammar/logit mask over currently valid tool names. Schema changes should be enforced during generation, not only parsed afterward.
3. Compact repeated identical tool-call traces. Replace many full skill_view calls with a semantic state fact such as skill_view(retatrutide-tracking) was called 13 times; latest result unchanged.
4. Detect plan/action mismatch. If assistant prose says "patch", "update", or "write" and the tool is read-only with no new information need, block or ask for a different action.

Model training and evaluation

1. Build an adversarial tool-action eval around repeated read-only histories, marker counts, current user intent, assistant plan text, and expected tool class.
2. Include SFT and preference examples where the same assistant prose is paired with a chosen mutation tool and a rejected repeated read-only tool.
3. Score P(_manage | <function=skill) versus P(_view | <function=skill) across marker counts 0, 1, 2, 5, and 10+.
4. Treat first-token probes as diagnostic gates, not final acceptance tests. Full continuation quality must pass before a model or adapter is promoted.

What not to rely on

• Do not rely on temperature or top-p changes once the bad branch is near argmax.
• Do not treat MTP, KV type, or GGUF quantization as the primary root cause.
• Do not hide a stale tool from the schema unless decoding is constrained to valid current tools.
• Do not accept an adapter just because it passes a first-token branch probe.

Limitations

• The original raw Jun 10 request dumps or stream traces were not found, so the replay uses durable persisted state: system prompt, model config, assistant tool calls, tool ids, and tool results from SQLite.
• Several marker-count ablations are one sample per K. The threshold shape is strong, but exact non-monotonic differences such as 5 versus 13 traces should not be over-interpreted.
• Replay is seed-sensitive. Low-level logprob probes are therefore more useful for causal diagnosis, while full replay remains necessary for acceptance.
• Some later invalid eval directories contained connection errors after a prompt-cache crash and should not be treated as model-quality results.

Artifact Map

This report is derived from local artifacts and notes. Key files: