Summary
I'd like to discuss whether CrewAI would be open to an optional ClawMem-backed memory integration.
This is not a request to replace CrewAI's architecture. The narrower question is whether ClawMem could fit as an optional memory/knowledge backend for long-running multi-agent workflows.
Why this seems worth discussing
CrewAI's README frames the project as a fast and flexible multi-agent automation framework with:
- multi-agent orchestration
- flows/workflows
- tracing and observability
- seamless integrations
- a unified control plane
That suggests a ClawMem integration could plausibly fit as:
- an optional memory/knowledge backend
- an integration package outside core
- a documented example for durable memory in Crew/Flow setups
What ClawMem would add
ClawMem is oriented around:
- persistent memory across sessions and runs
- auditability of memory changes
- explicit workspace/repository memory boundaries
- optional shared memory across agents and humans
Clarification I am looking for
Would maintainers be open to one of these directions?
- external integration package
- docs/example integration
- first-party optional integration
- not a good fit for CrewAI
Minimal scope
The smallest useful scope seems to be:
- optional integration only
- no default behavior changes
- focus on durable memory persistence/recall rather than modifying CrewAI core orchestration semantics
If this direction sounds reasonable, I can turn it into a more concrete implementation brief.
Summary
I'd like to discuss whether CrewAI would be open to an optional ClawMem-backed memory integration.
This is not a request to replace CrewAI's architecture. The narrower question is whether ClawMem could fit as an optional memory/knowledge backend for long-running multi-agent workflows.
Why this seems worth discussing
CrewAI's README frames the project as a fast and flexible multi-agent automation framework with:
That suggests a ClawMem integration could plausibly fit as:
What ClawMem would add
ClawMem is oriented around:
Clarification I am looking for
Would maintainers be open to one of these directions?
Minimal scope
The smallest useful scope seems to be:
If this direction sounds reasonable, I can turn it into a more concrete implementation brief.