feat(memory): introduce MemoryProvider protocol and registry for long-term memory integrations#3958
Closed
danhdoan wants to merge 1 commit into
Closed
Conversation
…term memory integrations Add agent/memory/ package defining a lifecycle contract for memory providers (Honcho, ByteRover, future integrations). The interface replaces the current pattern of hardwiring each integration directly into AIAgent with scattered if/else blocks. The package provides: - MemoryProvider Protocol (9 methods): is_available, initialize, shutdown, capabilities, enrich_turn, on_memory_write, on_turn_complete, on_compress, and name property - MemoryProviderRegistry: orchestrates multiple providers with parallel execution (ThreadPoolExecutor with deadlines), error isolation (_safe_call wrapper), and enforced deadlines for enrichment (5s), compression flush (120s), and shutdown (15s) - Context sanitization helpers: sanitize_context, build_memory_context_block, inject_memory_context — centralized prompt injection defense via <memory-context> fencing Design decisions: - Protocol over ABC (duck-typing, no forced inheritance) - One registry per AIAgent (not a singleton — gateway-safe) - Providers are smart, registry is thin (no assembly logic) - Non-daemon threads for on_compress (must complete before messages are permanently discarded) - Daemon threads for on_memory_write and on_turn_complete (fire-and-forget, acceptable to lose) No existing code modified. No behavioral changes. 58 tests.
a2f2b47 to
c64d716
Compare
Contributor
|
Thanks for the thorough analysis and well-structured PR, @danhdoan! This automated hermes-sweeper review found that the interface you proposed has since been implemented on What landed:
Merged: commit Your design analysis in the linked issue #3943 and the method-level mapping you did were genuinely valuable — they clearly informed the shape of the final interface. If you want to contribute further, the memory plugin ecosystem ( This is an automated review by hermes-sweeper. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does this PR do?
Introduces a
MemoryProviderprotocol andMemoryProviderRegistrythat define a standard lifecycle contract for long-term memory integrations in Hermes Agent.Currently, Honcho is wired directly into
AIAgentinrun_agent.pywith ~250 lines of inline code scattered across 20+ locations. There is no abstract interface — adding a second memory provider would require inserting new if/else blocks into every one of those locations, and a third provider would triple the wiring. This PR establishes the interface so that future memory integrations (and eventually Honcho itself) can plug in through a clean registry without modifying core agent code.The interface was designed by tracing every Honcho integration point in the current codebase to ensure full compatibility. See the linked issue for the detailed analysis, provider mapping table, and migration plan.
This PR adds the interface and tests only. No existing code is modified. No behavioral changes.
Related Issue
Implemented #3943
Type of Change
Changes Made
agent/memory/__init__.py— Package public API re-exportsagent/memory/protocol.py—MemoryProviderProtocol with 9 methods:name,is_available,initialize,shutdown,capabilities,enrich_turn,on_memory_write,on_turn_complete,on_compressagent/memory/registry.py—MemoryProviderRegistrywith parallel execution (ThreadPoolExecutor), error isolation, and enforced deadlines (5s enrichment, 120s compression, 15s shutdown)agent/memory/context.py— Context sanitization helpers (sanitize_context,build_memory_context_block,inject_memory_context) for centralized prompt injection defensetests/agent/test_memory.py— 58 tests covering protocol conformance, registry lifecycle, capabilities, parallel enrichment with deadlines, error isolation, threading contracts, shutdown idempotency, and context sanitizationHow to Test
python -m pytest tests/agent/test_memory.py -v— all 58 tests should passpython -m pytest tests/ -q— no existing tests should be affected (no existing code modified)agent.memoryexists anywhere in the codebase outside of the new files and testsChecklist
Code
fix(scope):,feat(scope):, etc.)pytest tests/ -qand all tests passDocumentation & Housekeeping
docs/, docstrings) — protocol.py contains full API documentation in docstringscli-config.yaml.exampleif I added/changed config keys — N/A (no config changes)CONTRIBUTING.mdorAGENTS.mdif I changed architecture or workflows — N/A (interface only, no architectural changes to existing code)