1.4 KiB
1.4 KiB
title, type, status, created, updated, verified_on, confidence, tags, sources
| title | type | status | created | updated | verified_on | confidence | tags | sources | |||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Tool Calling | concept | active | 2026-07-22 | 2026-07-22 | 2026-07-22 | high |
|
|
Tool Calling
Idea
How Hermes decides to invoke a tool, and — more specifically for this page — how it detects and stops itself when tool use goes wrong (loops, repeated failures).
How this install implements guardrails
Verified (~/.hermes/config.yaml, tool_loop_guardrails:):
warnings_enabled: true
hard_stop_enabled: false
warn_after:
exact_failure: 2
same_tool_failure: 3
idempotent_no_progress: 2
hard_stop_after:
exact_failure: 5
same_tool_failure: 8
idempotent_no_progress: 5
- Warnings trigger well before any hard stop (2–3 repeats vs 5–8).
hard_stop_enabled: false— Hermes will warn about a stuck tool loop but will not currently force-stop itself. That's a deliberate-looking but consequential setting: a genuinely stuck loop only gets a warning, not an automatic halt.
Why it matters here
This is the mechanism behind runbooks/troubleshoot-tool-loop — that runbook's "agent loops on one tool" symptom is exactly what warn_after/hard_stop_after are meant to catch. With hard-stop disabled, a human (or the messaging integrations) is the actual backstop today.