Please Add Native Hermes Agent MemoryProvider Support for Cortex

[Yat-mo]

Add Native Hermes Agent MemoryProvider Support for Cortex

Summary

Cortex currently works with Hermes Agent through the generic MCP path, but it does not appear to have a Hermes-specific native integration.

Please consider adding native Hermes Agent MemoryProvider support so Cortex can be selected as a first-class memory.provider, similar to mem0, and eventually replace Mem0 for Hermes users who want a self-hosted external memory backend.

Background

I have checked the current state:

• The Cortex README does not mention Hermes Agent integration.
• I could not find existing GitHub issues related to Hermes, memory.provider, or MemoryProvider.
• My local environment does not have the GitHub CLI installed.
• My ~/.hermes/.env does not contain a GitHub token, only a Telegram token, so I cannot directly create the issue from my Hermes environment.

Current State

Cortex already works with Hermes Agent through MCP:

Hermes Agent native MCP client
  -> npx @cortexmem/mcp --server-url http://127.0.0.1:21100
  -> Cortex server

This exposes tools such as:

cortex_recall
cortex_remember
cortex_forget
cortex_search_debug
cortex_stats
cortex_relations

This is useful, but it is not equivalent to native Hermes memory provider support.

Why MCP Alone Is Not Enough

MCP makes Cortex callable as a tool provider, but it does not make Cortex participate automatically in Hermes Agent's memory lifecycle.

A native memory provider would allow Cortex to:

• prefetch relevant memories before each turn;
• inject relevant recall context automatically;
• sync completed turns after each response;
• appear in hermes memory setup and hermes memory status;
• be configured through Hermes' standard memory.provider flow;
• replace Mem0 without changing how Hermes memory works.

With MCP alone, the model must decide when to call cortex_recall manually. That is not the same as automatic memory lifecycle integration.

Requested Feature

Please add a native Hermes Agent MemoryProvider integration for Cortex.

Ideally, users should be able to configure Cortex like this:

memory:
  provider: cortex

Then Hermes should treat Cortex as the external memory backend.

Expected Behavior

A native Cortex provider should support the following behavior:

1. Cortex appears in hermes memory setup as a real provider.
2. Cortex appears in hermes memory status as active and available.
3. Hermes automatically prefetches relevant Cortex memory before each turn.
4. Hermes automatically syncs completed turns to Cortex after each turn.
5. Explicit remember/search/forget tools are exposed natively.
6. Built-in Hermes memory remains active.
7. Cortex replaces the external provider slot currently often occupied by Mem0.
8. Hermes profile, user, agent, and session scoping are handled safely.

Relevant Hermes Provider Interface

A native provider would likely implement Hermes' MemoryProvider lifecycle roughly like this:

class CortexMemoryProvider(MemoryProvider):
    @property
    def name(self) -> str:
        return "cortex"

    def is_available(self) -> bool:
        ...

    def initialize(self, session_id: str, **kwargs) -> None:
        # kwargs may include:
        # hermes_home, platform, agent_context,
        # agent_identity, agent_workspace,
        # parent_session_id, user_id
        ...

    def system_prompt_block(self) -> str:
        ...

    def prefetch(self, query: str, *, session_id: str = "") -> str:
        ...

    def queue_prefetch(self, query: str, *, session_id: str = "") -> None:
        ...

    def sync_turn(
        self,
        user_content: str,
        assistant_content: str,
        *,
        session_id: str = ""
    ) -> None:
        ...

    def get_tool_schemas(self) -> list[dict]:
        ...

    def handle_tool_call(
        self,
        tool_name: str,
        args: dict,
        **kwargs
    ) -> str:
        ...

    def shutdown(self) -> None:
        ...

The existing Mem0 provider in Hermes is a useful comparison point. It appears to implement:

• system_prompt_block() to advertise active memory tools;
• queue_prefetch() / prefetch() for recall injection;
• sync_turn() for post-turn ingestion;
• tool schemas such as mem0_profile, mem0_search, and mem0_conclude.

Possible Cortex Mapping

A Cortex provider could map Hermes memory behavior to Cortex APIs or MCP tools:

Hermes provider behavior	Cortex equivalent
Pre-turn recall	POST /api/v1/recall or cortex_recall
Post-turn ingestion	POST /api/v1/ingest
Explicit store	POST /api/v1/memories or cortex_remember
Forget / correct	DELETE /api/v1/memories/:id or cortex_forget
Profile / status	GET /api/v1/stats, GET /api/v1/memories, GET /api/v1/agents

Proposed Configuration

Environment variables could support:

CORTEX_URL=http://127.0.0.1:21100
CORTEX_AUTH_TOKEN=...
CORTEX_AGENT_ID=hermes
CORTEX_PAIRING_CODE=optional-instance-scope

Alternatively, Hermes could support a provider config like:

{
  "url": "http://127.0.0.1:21100",
  "agent_id": "hermes",
  "pairing_code": "optional"
}

Secrets such as auth tokens should remain in environment variables rather than plain config files where possible.

Compatibility Request

It would be especially helpful if Cortex could provide one of the following paths:

1. A bundled or documented Hermes plugin under something like plugins/memory/cortex;
2. A small Python package or install script that drops a Cortex provider into Hermes' memory plugin directory;
3. Documentation with a reference implementation for Hermes maintainers to upstream.

Acceptance Criteria

• hermes memory setup can configure Cortex.
• hermes memory status shows Cortex as active and available.
• memory.provider: cortex activates Cortex without requiring MCP tools as the primary memory path.
• A test turn is automatically ingested into Cortex.
• A later turn automatically receives relevant Cortex recall context.
• Explicit remember/search/forget tools work.
• Agent, user, profile, and session scoping are documented.
• Existing MCP integration remains supported.

Notes

I already have Cortex running locally with Hermes Agent through MCP, so the Cortex server side is usable today.

The missing part is first-class Hermes MemoryProvider integration, so Cortex can truly replace Mem0 as the external memory backend for Hermes Agent instead of only being callable through MCP tools.

Finally Request

Please add a native Hermes Agent MemoryProvider integration for Cortex, so Cortex can be selected via memory.provider: cortex and replace Mem0 as Hermes' external memory backend, instead of only being callable through MCP tools.