Memory Provider Plugins
Memory مزوّدو النماذج Plugins
Start with meaning, then move to detail.
This lesson explains Memory Provider Plugins as part of Hermes internals and extension points. You will learn what it does, when it matters, and the smallest safe test that proves it works.
If you are new, do not memorize names. Focus on three questions: what problem does this solve, what access does it need, and how can you verify the result?
For practice, inspect the first example, identify its effects, run it on test data, and compare the result with the source claim.
For advanced readers, inspect Directory Structure, The MemoryProvider ABC, Required Methods, then verify failure modes and version compatibility.
Know Python, Git, and basic project structure before changing code.
A clear outcome before you read.
- Understand Memory Provider Plugins without assumed prior knowledge.
- Separate the source description from what still needs testing in your environment.
- Read the first command and identify its inputs and outputs before copying it.
Short definitions before the details.
- Provider
- The service that runs or provides access and authentication to a model.
- Session & memory
- A session holds conversation context, while memory keeps selected facts that should persist.
How to build a memory provider plugin for Hermes Agent
What does the source say, and in what order?
- 01Directory Structure
Start here to understand the core idea or structure.
- 02The MemoryProvider ABC
Read this after the foundation, then connect it to the previous step.
- 03Required Methods
Read this after the foundation, then connect it to the previous step.
- 04Core Lifecycle
Read this after the foundation, then connect it to the previous step.
- 05Config
Read this after the foundation, then connect it to the previous step.
- 06Optional Hooks
Read this after the foundation, then connect it to the previous step.
- 07Config Schema
Read this after the foundation, then connect it to the previous step.
- 08Save Config
Read this after the foundation, then connect it to the previous step.
- 09Plugin Entry Point
Read this after the foundation, then connect it to the previous step.
- 10plugin.yaml
Finish here to verify the result and special cases.
Copy only after you understand the effect.
plugins/memory/my-provider/
├── __init__.py # MemoryProvider implementation + register() entry point
├── plugin.yaml # Metadata (name, description, hooks)
└── README.md # Setup instructions, config reference, tools## Required Methods
### Core Lifecycle
| Method | When Called | Must Implement? |
|--------|-----------|-----------------|
| `name` (property) | Always | **Yes** |
| `is_available()` | Agent init, before activation | **Yes** — no network calls |
| `initialize(session_id, **kwargs)` | Agent startup | **Yes** |
| `get_tool_schemas()` | After init, for tool injection | **Yes** |
| `handle_tool_call(tool_name, args, **kwargs)` | When agent uses your tools | **Yes** (if you have tools) |
### Config
| Method | Purpose | Must Implement? |
|--------|---------|-----------------|
| `get_config_schemFields with `secret: True` and `env_var` go to `.env`. Non-secret fields are passed to `save_config()`.
:::tip Minimal vs Full Schema
Every field in `get_config_schema()` is prompted during `hermes memory setup`. Providers with many options should keep the schema minimal — only include fields the user **must** configure (API key, required credentials). Document optional settings in a config file reference (e.g. `$HERMES_HOME/myprovider.json`) rather than prompting for them all during setup. This keeps the setup wizard fast while still supporting advanced configuration. See the Supermemory proRead the first command and identify its inputs and outputs before copying it.
Match every command to your installed Hermes version, review the files and accounts it can reach, and use non-sensitive data for the first test. If this explanation differs from the source, the official source wins.