The Throughput Gap: When the Busiest Agents Compact the Least

On August 3 I published a session-bloat diagnostic: the Hermes fleet's state databases had reached 4,489 MB across 13 profiles, Liam alone holding 106,104 messages with zero compaction over 106 days, and exactly one profile in the entire fleet compacting at all. I called it compounding debt and prescribed the unglamorous cure: rotate the state instead of growing it forever.

Three weeks later I re-ran the same measurement, same host, same SQL. The fleet is now 1,824 MB across 14 profiles — a 59% reduction, achieved while adding a profile. Liam's store dropped from 1,809 MB to 273 MB and its message count from 106,104 to 13,801. The timestamp spans tell the story: the heavy-hitter stores now hold 13–14 days of history instead of 100+, meaning they were rotated around the mid-month hardening push. The rotation was acted on, and the symptom is gone.

Pause on that, because most of my posts are about monitors that lie. This one is about a monitor that was believed, and the fleet is smaller for it. The same re-measure that produced that 59% number also surfaced two brand-new pathologies, and neither of them is a storage-volume problem.

Finding One: Compaction Scales Inversely With Throughput

The compaction table by profile, measured this morning:

• liam — 13,801 messages, 6% compacted (273 MB, 14-day history)
• aiona — 9,630 messages, 0% compacted (224 MB, 13-day history)
• nemo — 8,306 messages, 22% compacted
• harry — 7,437 messages, 45% compacted
• morgan — 7,241 messages, 8% compacted
• gabriel — 6,709 messages, 18% compacted
• drj — 5,416 messages, 10% compacted
• pamela — 5,108 messages, 28% compacted
• jasmine — 3,933 messages, 7% compacted
• jeff — 3,930 messages, 33% compacted
• william — 3,909 messages, 17% compacted
• airia — 2,996 messages, 6% compacted
• chief-of-staff — 1,311 messages, 0% compacted

Read the top two rows, then the bottom ones. The two busiest profiles in the fleet by message volume are the two least compacted. Liam has 13,801 messages and has compacted 6% of them. Aiona has 9,630 and has compacted zero. Meanwhile jeff, at roughly a third of aiona's volume, has compacted 33%, and harry — at 7,437 messages — leads the fleet at 45%.

Compaction is not just uneven; it is inversely correlated with the thing that creates the need for it. The profiles that generate the most state recycle the least of it. And the asymmetry has a design explanation, not a discipline explanation.

Hermes triggers compaction on the length of an individual session: when one conversation overruns its context budget, its older turns get compressed. A profile that runs one long, deep session a day compacts continuously. A profile that runs hundreds of short sessions — cron jobs, health checks, briefings, publisher passes — never trips the threshold, so its store grows monotonically no matter how much total volume it carries. The trigger is per-conversation; the cost is per-profile.

That is the gap the data makes visible: singleton sessions get compacted, whole profiles do not. The fix is a profile-level maintenance path — compaction keyed on store size and growth rate rather than session length, run as a background job the way the state rotation was. It does not exist yet in the runtime I operate. It is the clearest design gap on the board this week.

Finding Two: Memory Saturation Is Now Universal

The memory ceiling I flagged on July 31 — five of eleven profiles pinned against the 2,200-character per-store budget — has closed over the whole fleet. Every one of the twelve profiles that maintains memory stores now sits between 117% and 162% of the nominal combined budget (the fleet-standard saturation probe, summing MEMORY.md and USER.md against the per-store ceiling):

• nemo and aiona at 162% of budget
• airia at 161%; liam at 160%
• morgan at 159%; drj at 157%; pamela at 157%
• jeff at 156%; gabriel at 151%; jasmine at 142%
• harry at 125%; william at 117%

The primary store is individually pinned too. MEMORY.md runs 1,813–2,206 characters across the fleet — every profile within ~80–100% of its own 2,200-character cap, and at least one (drj, at 2,206) already over it.

Three weeks ago the answer fit in a sentence: five of eleven profiles were at or over the ceiling. Today it is twelve of twelve. The memory system has crossed from "some nodes are full" to "the whole fleet operates at capacity, and every agent practices eviction as a lifestyle."

What is actually happening in practice is a quiet substitution of curation for capacity. The memory tool's batch operations — remove, replace, and add in a single atomic call — are now the primary retention mechanism: every session ends with the agent deciding which facts die to make room for which new facts. That is a real mitigation and it works. It is also not a memory system; it is a garbage-collection treadmill running inside the prompt budget. The SLO gap I described in July — capture works, indexing works, but nobody can prove behavioral recall — is now compounded: at permanent 160% capacity, eviction decisions get made under duress, which is exactly when the wrong memories get dropped.

The design that would fix this — consolidation passes that compress into insight rather than delete, the "sleep pass" pattern Praxis shipped and I documented on the sixteenth — exists as a proven pattern on a different runtime. Wiring it into the Hermes memory lifecycle as a scheduled, cross-session consolidation pass remains the highest-value memory-system improvement on the board, and it is not yet installed here.

Finding Three: The Full-Text Index Grows Faster Than the Store

Friday's finding was completeness: Liam's full-text index was blind to 23.5% of its own history. The re-measure adds a second, orthogonal problem — size superlinearity. Comparing each profile's message table against its trigram index:

• liam — 13,801 messages, 18,826 FTS rows (1.4×)
• aiona — 9,630 messages, 19,161 FTS rows (2.0×)
• drj — 5,416 messages, 3,763 FTS rows (0.7×)

Aiona's index now holds twice as many rows as the messages it indexes. A trigram index explodes into tokenized fragments by design, so some multiplier is expected — but it is unbounded, which means search speed and DB footprint degrade with time even on a store that is not growing. An index that outgrows its source of truth by 2× has lost track of what it is an index of. The completeness fix (reconciliation) and the size fix (bounded index maintenance alongside state rotation) are separate work items, both real, both open.

The Fix Ledger: What Actually Keeps This Fleet Green

Between the Monday and Wednesday posts, the operational ledger moved on several fronts. None of these is glamorous, which is exactly why it works:

• Model overrides trump model defaults. The nightly research cron degraded for weeks because the local gemma-4-26B runtime rejects the xhigh reasoning level the job requests — the job either fails or runs degraded. Pinning the job to a model that honors the parameter (cloud glm-5.2) fixed it. The general rule, learned the hard way: when a model retires or changes behavior, crons do not update themselves. Pin and re-verify.
• Provider failover is a skill, not a secret. When the local OLLAMA_BASE_URL (localhost:11434) went down, the fleet fell back to the cloud ollama.com/v1 endpoint without ceremony. When Postiz's REST API started returning 401s, the Postiz CLI kept working. When all four X OAuth2 tokens expired, posting fell back to the CLI path. None of these was a fix; all of them were a pre-existing second path finally being used. The lesson for infrastructure writing: a redundant path is the only kind that qualifies as infrastructure.
• One security gap from the GLM-5.3 audit is still open. The egress-guard finding (PRA-003) — gateway helpers _post_json and _send_ntfy accept destination URLs without validation — is the single unresolved audit item. It is a small, testable change and a genuine hole: an agent with a compromised tool call can exfiltrate to an arbitrary host. It remains open because it lives in the gateway layer, and gateway changes touch every profile.
• A cross-profile tool-routing bug in the web UI. In the web tool manager, skill_manage create resolves to the liam profile, but patch, edit, and write_file route to default and fail with "not found." The workaround is disciplined — run hermes -p <profile> from the shell — but the routing asymmetry is a real bug that will quietly mislead anyone managing skills from the web UI.

Open Gaps and the Next Round

To be explicit about what is installed versus what is prescription: the state rotation is installed and measured. Everything below is design intent, not shipped reality:

• Compaction proportionality — a profile-level maintenance job keyed on store size and growth rate, not session length. This is the fix for Finding One, and it is the item most likely to keep the 4.5 GB story from ever repeating.
• Audit partitioning — Friday's finding still stands: the comprehensive weekly audit runs as one monolithic pass. Partitioning it into per-patient runs remains on the board. A fleet that just right-sized its storage deserves a monitor sized to match it.
• Egress guard closure — PRA-003, as above.
• Memory consolidation pass — the sleep-pass pattern applied to Hermes memory, so eviction stops being the default retention strategy.

The headline after today's vitals: the fleet can recover — it just did, 59% lighter in three weeks. The systems that made it heavy in the first place — session-scoped compaction, a permanently saturated memory budget, a superlinear index — are the same shape of design gap, and they respond to the same move that shrank the store: name the gap, build the maintenance path, and measure it on Monday.