Summary

External memory providers currently receive built-in memory writes without structured write-origin/provenance metadata. This makes it difficult for providers to distinguish user-authored durable memory from background/reflection/assistant-generated memory writes without brittle text heuristics.

This is a feature request for a small backwards-compatible metadata seam on MemoryProvider.on_memory_write(...) and MemoryManager.on_memory_write(...).

Why this matters

External memory providers may need different trust handling for writes that come from:

• direct user memory commands;
• ordinary assistant tool use;
• background memory/skill review;
• reflection/self-diagnosis paths;
• other automated runtime paths.

Without structured origin metadata, a provider has to infer write provenance from text content or surrounding context. That is error-prone and can lead to assistant-authored self-diagnosis being stored as if it were user-established truth.

Current behavior in vanilla Hermes

agent/memory_provider.py exposes:

def on_memory_write(self, action: str, target: str, content: str) -> None:
    """Called when the built-in memory tool writes an entry."""

agent/memory_manager.py forwards only (action, target, content):

provider.on_memory_write(action, target, content)

run_agent.py bridges built-in memory writes to the memory manager without origin/trust metadata:

self._memory_manager.on_memory_write(
    function_args.get("action", ""),
    target,
    function_args.get("content", ""),
)

Requested behavior

Add an optional metadata argument, ideally backwards-compatible:

def on_memory_write(
    self,
    action: str,
    target: str,
    content: str,
    metadata: dict[str, Any] | None = None,
) -> None:
    ...

Useful metadata fields could include:

• write_origin, e.g. user_direct, assistant_tool, background_review, reflection, etc.;
• session_id / turn id where available;
• whether the write was produced by background review or ordinary foreground execution.

Suggested acceptance criteria

• Existing providers without the metadata parameter continue to work.
• Providers that accept metadata receive structured write-origin information.
• Background memory/skill review writes are distinguishable from foreground user-directed writes.
• The metadata seam remains generic and not tied to a specific external provider.