[Feature] Wire on_pre_compress into the context compression pipeline for MCP servers

[linyueweia]

Problem

When Hermes Agent's context compression fires (triggered when prompt_tokens >= threshold), it destroys conversation history without any pre-hook to preserve state. This causes catastrophic data loss: the agent loses access to everything that was in context before compression.

What already exists

agent/memory_manager.py defines on_pre_compress() (line 438) which calls provider.on_pre_compress(messages) on all memory providers. run_agent.py already calls this hook at line 9696, before calling context_compressor.compress() at line 9701.

However, hermes-knowledge-base runs as an MCP server, not as a MemoryProvider plugin. The MCP server is completely separate from the MemoryProvider lifecycle, so it never receives the on_pre_compress call.

Proposed Solution

Expose a pre-compression hook accessible to MCP servers. Two options:

Option A — MCP server pre-compression hook (recommended)

Before compressing, Hermes makes a blocking call to each MCP server's pre-compression hook:

# In run_agent.py, just before context_compressor.compress() at line 9701:
for server_name, server in self._mcp_servers.items():
    if hasattr(server, 'on_pre_compress'):
        try:
            server.on_pre_compress(messages)
        except Exception as e:
            logger.warning(f"MCP server {server_name} on_pre_compress failed: {e}")

This mirrors how MemoryProvider.on_pre_compress() already works for native plugins.

Option B — context_engine.pre_compress_hook config

Allow users to configure an external script that Hermes calls before compression:

context_engine:
  compressor:
    pre_compress_hook: "python3 /path/to/backup_script.py"

The configured script receives the full message list as stdin JSON and can run hk_retain or any other backup logic.

Current workaround

Users currently work around this with aggressive cron-based polling (*/10 * * * *) that checks sessions.json and backs up when last_prompt_tokens >= 59%. This is unreliable — compression can fire between checks, causing data loss.

Impact

Without a pre-compression hook, any memory system running as MCP (including hermes-knowledge-base) has a race condition: compression fires → context is compacted → the next tool call (e.g. hk_retain) receives the already-compacted context and backs up incomplete data.

[akimuz]

Since MCP servers run as independent processes, directly mirroring the on_pre_compress logic on the Python side would introduce unnecessary IPC overhead and compromise protocol purity. and external scripts might not be user-friendly for everyone.
I propose a more decoupled approach: Lifecycle Hooks via Tool Convention. If an MCP server exposes a specifically named tool (e.g., hermes_lifecycle_pre_compress), Hermes can proactively invoke it before compression.
This approach shifts the backup responsibility to the MCP server itself—which has the best context of its internal state—while Hermes only needs to send a lightweight 'nudge' with the session ID.
I’ve submitted a Pull Request to demonstrate this, happy to iterate on the implementation based on your feedback.