Hermes portable-memory tool: ~2,200-char MEMORY.md cap is too tight and has no auto-eviction — active agents' memory silently freezes

[mostlydev]

Summary

The Hermes runner's memory tool enforces a ~2,200-character cap on the consolidated MEMORY.md index and rejects any write that would exceed it, with no automatic eviction of old entries. On a busy pod this silently freezes an agent's persistent memory: once it reaches the cap it can never record anything new, and the agent loses awareness of its own recent actions across turns.

The rejection looks like:

Tool memory returned error: {"success": false, "error":
"Memory at 1,952/2,200 chars. Adding this entry (781 chars) would exceed the
limit. Replace or remove existing entries first."}

Observed on a live pod (8 OpenClaw/Hermes agents)

6 of 8 agents at/near the cap, several frozen for weeks:

agent	MEMORY.md size	frozen since
boulton	2179	~33d
logan	3130 (over)	~33d
tiverton	2177	~11d
dundas	2161	same-day
weston	2085	~4d
gerrard	2082	~2d

Concrete impact: an agent re-litigated whether its own action earlier the same day had happened, because its MEMORY.md index had frozen and captured nothing since. Per-day notes/*.md writes still succeed (separate path); only the consolidated index is stuck.

Why it matters at the runtime layer

The cap is a Hermes runtime default, not exposed in the pod config (claw-pod.yml / agent files) — so operators can't raise it, and agents don't reliably self-prune. A purely operator-side workaround (manual trimming) doesn't scale across a roster.

Suggested directions

• Make the cap configurable (per-agent or via CONFIGURE/env), and/or
• Auto-evict oldest entries (or summarize) on write instead of hard-rejecting, and/or
• Raise the default — 2,200 chars is very tight for an agent that journals every turn.

Surface the current usage to the agent so it can self-manage if a cap remains.

Downstream reference

Tracked desk-side at mostlydev/tiverton-house#47 (with the full per-agent evidence).