Memori memory provider

[devwdave]

What does this PR do?

Adds Memori as a bundled external memory provider for Hermes.

This gives Hermes a structured long-term memory backend with explicit recall, summary, quota, signup, and feedback tools. Completed turns are captured in the background, including the user request, final assistant response, and Hermes-processed tool trace so Memori can preserve what the agent did, not just what it said.

The core memory sync path now accepts optional trace metadata while preserving compatibility with existing memory providers. Memori only reports available when both config and the SDK are present, and the docs now call out the required entity ID plus the full raw after-Hermes-processing trace policy.

Related Issue

No linked issue.

Type of Change

• 🐛 Bug fix (non-breaking change that fixes an issue)
• ✨ New feature (non-breaking change that adds functionality)
• 🔒 Security fix
• 📝 Documentation update
• ✅ Tests (adding or improving test coverage)
• ♻️ Refactor (no behavior change)
• 🎯 New skill (plugin-provided Memori skill)

Changes Made

• Added bundled Memori provider under plugins/memory/memori/.
• Added Memori tools: memori_recall, memori_recall_summary, memori_quota, memori_signup, and memori_feedback.
• Added a plugin-provided Memori skill with guidance for recall, summaries, quota checks, signup, feedback, pitfalls, and verification.
• Extended agent/memory_manager.py and agent/memory_provider.py so completed-turn sync can optionally include trace metadata without breaking legacy providers.
• Updated run_agent.py to record tool trace for sequential, concurrent, blocked, and cancelled tool calls, then sync final Hermes-processed tool result content.
• Added tests for provider behavior, trace compatibility, Memori trace forwarding, and trace assembly.
• Updated memory provider docs, integration docs, CLI provider listings, and the Memori plugin README.

How to Test

1. Run the focused Python compile check:

   python3 -m py_compile agent/memory_manager.py agent/memory_provider.py plugins/memory/memori/__init__.py plugins/memory/memori/client.py run_agent.py tests/agent/test_memory_provider.py tests/plugins/memory/test_memori_provider.py tests/run_agent/test_memory_sync_interrupted.py

2. Run diff hygiene:

   git diff --check

3. With Memori credentials configured, run a smoke test that initializes the provider, captures a completed turn with trace, recalls it, and checks quota.

Validation performed locally:

• Changed Python files compile.
• Staged diff check passed.
• Provider compatibility smoke passed.
• Real Memori Cloud smoke passed: capture + recall returned memories, and quota returned the expected account shape.

Note: full pytest/ruff could not be run in this checkout because the local uv run path is currently blocked by a pyproject.toml exclude-newer = "7 days" parse issue and missing spawned pytest/ruff executables.

Checklist

Code

• I've read the Contributing Guide
• My commit messages follow Conventional Commits (fix(scope):, feat(scope):, etc.)
• I searched for existing PRs to make sure this isn't a duplicate
• My PR contains only changes related to this fix/feature (no unrelated commits)
• I've run pytest tests/ -q and all tests pass
• I've added tests for my changes (required for bug fixes, strongly encouraged for features)
• I've tested on my platform: macOS

Documentation & Housekeeping

• I've updated relevant documentation (README, docs/, docstrings) — or N/A
• I've updated cli-config.yaml.example if I added/changed config keys — or N/A
• I've updated CONTRIBUTING.md or AGENTS.md if I changed architecture or workflows — or N/A
• I've considered cross-platform impact (Windows, macOS) per the compatibility guide — or N/A
• I've updated tool descriptions/schemas if I changed tool behavior — or N/A

For New Skills

• This skill is broadly useful to most users (if bundled) — N/A: this is a Memori-provider plugin skill, not a generic bundled skill under skills/
• SKILL.md follows the standard format (frontmatter, trigger conditions, steps, pitfalls)
• No external dependencies that aren't already available (prefer stdlib, curl, existing Hermes tools) — N/A: the Memori provider intentionally depends on the memori SDK
• I've tested the skill end-to-end: hermes --toolsets skills -q "Use the memori-memory skill to explain when to use Memori recall versus Memori summaries."

Screenshots / Logs

End-to-end Memori Cloud smoke:

E2E_CAPTURE_OK=true
E2E_RECALL_OK=True
E2E_LAST_RECALL_SHAPE={"keys": ["memories"], "type": "dict"}
E2E_QUOTA_SHAPE={"keys": ["exceeded", "memories", "message"], "type": "dict"}

[kshitijk4poor]

Thanks for the contribution!

Per the updated CONTRIBUTING.md, new memory providers are no longer accepted as in-tree additions to plugins/memory/:

Memory Providers: CLOSED to new in-tree additions
PRs adding to plugins/memory/ will be closed. Publish as standalone plugin into ~/.hermes/plugins/ or via pip entry point. Must implement MemoryProvider ABC (sync_turn, prefetch, shutdown, optional post_setup).

Closing this in line with that policy. The path forward is to publish it as a standalone plugin so users can install it directly without touching the Hermes source tree. Once it's published, a small docs PR adding it to the Community plugins section of the README is welcome.

Sorry for the bump — appreciate the time you put into this.

[devwdave]

@kshitijk4poor Per your comment, I've created a new PR here Please let me know if any changes are required.