Feature request: discuss optional ClawMem-backed storage adapter

[EricZequan]

Summary

I'd like to discuss an optional integration path between ChatterBot and ClawMem as an external storage/memory backend.

This is not a request to add generic persistence from scratch. ChatterBot already has persistent storage adapters (SQL, MongoDB, Redis vector storage) and a clean storage_adapter extension point.

The request is specifically about whether ChatterBot should support or document a ClawMem-backed storage adapter for teams that want:

• durable conversation history across sessions
• auditable memory/workspace boundaries
• GitHub-compatible issue/comment-backed memory spaces
• optional shared memory across agents/users

Why this seems feasible

From the current codebase/docs:

• ChatBot(..., storage_adapter=...) already accepts a dot-notated import path for custom adapters.
• StorageAdapter defines a clear interface (count, filter, create, create_many, update, remove, get_random, drop).
• ChatterBot already supports multiple storage backends and recently expanded vector-based storage support.

So an initial integration path could likely be:

1. implement a ClawMem-backed adapter externally
2. optionally add docs/example usage in ChatterBot if maintainers think this is a good fit

Important caveat

ChatterBot stores conversational knowledge as a statement graph (text, in_response_to, conversation, tags, etc.), while ClawMem is oriented around durable memory artifacts and GitHub-compatible repository primitives.

Because of that, the likely MVP is not "replace ChatterBot's internal model with ClawMem semantics".
Instead, it would be something narrower such as:

• an optional storage adapter that maps ChatterBot statements into a ClawMem-backed store, or
• an adapter/example package maintained outside core, with ChatterBot docs showing how to wire it in

What I want to clarify

Would maintainers be open to one of these directions?

1. External adapter + docs example

   • adapter lives outside core
   • ChatterBot only documents the integration pattern

2. First-party optional adapter

   • adapter lives in ChatterBot core as another storage backend

3. Not a good fit for ChatterBot

   • if the statement-graph model and ClawMem memory model are too different, it would be useful to know that early

Minimum viable integration scope

If this is worth pursuing, the smallest useful scope seems to be:

• preserve conversation, text, and in_response_to
• support create_many, filter, and update well enough for training + response selection
• keep the adapter optional and avoid changing existing default storage behavior
• prefer docs/example-first unless maintainers want first-party support

If this direction sounds reasonable, I can turn this into a concrete implementation brief.

[gunthercox]

Hi @EricZequan, first off I really appreciate your clarity here and the quality of this feature request. Your framing of this as a question of if ChatterBot should support or document ClawMem integration along with your target outcomes is greatly appreciated.

My initial survey of ClawMem (https://github.com/yoloshii/ClawMem) leads me to agree in relation to the caveat you highlighted regarding the difference between ChatterBot's statement graph and ClawMem's memory artifacts. My initial suspition is that ClawMem might yield low quality responses when implemented as a ChatterBot StorageAdapter class due to its lack of statement-->response structuring which allows the selection of relevant replies. (Although I could very well be wrong here, I'm not yet fully familiar with ClawMem, and as an example, a Q/A data source would actually align very well with ChatterBot's response generation logic.

---

A possible alternative implementation

In addition to the Redis vector storage support being developed for ChatterBot, another recent (experimental) addition is the ability to support tool usage when using an LLM.

For example, the following snippet from https://docs.chatterbot.us/large-language-models/#llm-with-tool-support shows existing LogicAdapter subclasses being used as tools accessible to a ChatterBot instance:

bot = ChatBot(
    'My Bot',
    logic_adapters=[
        {
            'import_path': 'chatterbot.logic.OllamaLogicAdapter',
            'model': 'llama3.1',
            'logic_adapters_as_tools': [
                'chatterbot.logic.MathematicalEvaluation',
                'chatterbot.logic.TimeLogicAdapter',
                'chatterbot.logic.UnitConversion'
            ]
        }
    ]
)

My current thought is that a setup like this could include a ClawMem LogicAdapter which could be used as a tool for performing 'CRUD' operations on saved memory within ClawMem, providing additional context to the LLM. Implementing a feature like this might genuinely involve a bit more work than a StorgeAdapter implementation, especially considering the new and experimental status of the logic_adapters_as_tools parameter and LLMs in ChatterBot in general.

My recommendation would be to explore the possible fit of ClawMem as a logic adapter for LLM-backed instanced of ChatterBot. If this implementation works well, I will happily accept a contribution to the core ChatterBot library to support this functionality. I think there might be potential here to establish a pattern for memory-related tool usage that extends to data sources beyond just ClawMem.

---

Let me know if there is anything here that I can clarify or expand upon. If you're interested in moving forward with a pull request at any point I can also help make sure that any experimental features are properly labeled and documented as such.

[EricZequan]

@gunthercox Thanks for the thoughtful response. I think I was not specific enough about which ClawMem I meant, so that part is on me.

The ClawMem I was referring to is the project described at https://clawmem.ai/, not the yoloshii/ClawMem repository you linked.

The current ClawMem model is less “arbitrary memory artifacts” and more an inspectable memory layer for agents: it records conversations, extracts key facts/preferences/decisions into structured durable memories, retrieves relevant items semantically, and injects that context before later sessions. It also keeps provenance back to the originating session/turn, and those memories are inspectable/editable by the user.

So I agree that compatibility with ChatterBot’s statement graph is still the key question, but I think the fit may be somewhat different from the repository you reviewed. The “GitHub-compatible” part is more of an implementation/backend detail, not the primary memory abstraction.

Given your point about response quality and reply selection, I think your suggested LogicAdapter / LLM tool route may actually be the best first experiment.

If you’re open to it, I’d be happy to explore an external proof of concept that uses ClawMem for memory CRUD + semantic recall while keeping ChatterBot’s native response-selection behavior intact where appropriate. If that works well, we could then decide whether the right next step is docs-only guidance, an external integration package, or something closer to first-party support.

If useful, I can also write up a more concrete implementation brief based on the clawmem.ai model rather than the repository you referenced.

[gunthercox]

@EricZequan, I think an external proof of concept sounds like a great idea. Looking through the source and documentation for https://clawmem.ai/ it definitely seems like it might be a better fit. This ClawMem project appears to be predominantly a typescript package and collection of skills, and I wonder if something useful might be to also investigate setting it up outside of OpenClaw ecosystem (eg. seeing if it can be set up as a standalone service in a Docker container or something like that to avoid the overhead of unnecessary setup and boilerplate.

Depending on what you find, I would be happy to link to or add something to the ChatterBot documentation.