Hermes starts putting hard limits around runaway subagents
Hermes PR #22820 turns a familiar multi-agent failure into explicit controls. The report describes a delegated subagent that drifted beyond scope, ran for 175 seconds, expanded context from about 33K to 72K+ tokens, made 10+ API calls, and had to be interrupted. The proposed fix adds configurable caps for maximum child context, output/input growth ratio, and wall-clock timeout, then marks the child failed with `resource_limit_exceeded` when it crosses the boundary. PR #22944 tackles a related reliability issue in context re-compression: the agent’s `## Active Task` field could be overwritten with `[N/A]`, stale, or hallucinated content after repeated compaction cycles.
Multi-agent systems fail less dramatically when they can stop children that loop, bloat context, or forget the task. These changes matter because they move Hermes from “delegate and hope” toward bounded delegation with auditable failure reasons.
- PR #22820 lists a concrete runaway case: 175 seconds, 72K+ tokens from 33K initial context, 10+ API calls, and manual interruption
- The PR adds `delegation.max_context_tokens`, `delegation.context_growth_ratio`, and `delegation.timeout_seconds`, with child results marked `resource_limit_exceeded` when caps are exceeded
- PR #22944 identifies two active-task corruption causes in iterative re-compression and changes the prompt/template flow so the field is preserved by code rather than rewritten by the summarizer
- PR #12436 adds a DAG TaskGraph, delegate bridge, in-process agent-to-agent bus, and reflex hints, showing Hermes is still expanding orchestration while resource controls are being added
- The core changes are open PRs, so operators should not assume released behavior yet
- Hard limits can prevent runaway cost but can also fail legitimate long work if defaults are too tight
- The DAG orchestration direction increases the need for per-child permission, budget, and observability controls