Ideas: CORE

[jack-arturo]

Take a look at https://github.com/RedPlanetHQ/core : any ideas we can borrow?

https://www.reddit.com/r/LLMDevs/comments/1pkwgwy/building_a_knowledge_graph_memory_system_with_10m/

• Run benchmarks for comparisons

[coderabbitai]

📝 CodeRabbit Plan Mode

Generate an implementation plan and prompts that you can use with your favorite coding agent.

✅ Successfully generated implementation plan.

💡 Use @coderabbitai <feedback> to replan

Examples

• Example 1
• Example 2

---

🧪 Issue enrichment is currently in open beta.

You can configure auto-planning by selecting labels in the issue_enrichment configuration.

To disable automatic issue enrichment, add the following to your .coderabbit.yaml:

issue_enrichment:
  auto_enrich:
    enabled: false

💬 Have feedback or questions? Drop into our discord or schedule a call!

[coderabbitai]

Coding Plan

Approach

Evaluate CORE's architecture for ideas that can enhance AutoMem's memory system, focusing on CORE's key differentiators: statement extraction with provenance tracking, contradiction detection and resolution, enhanced entity-relationship extraction, and improved re-ranking. Run benchmark comparisons to validate performance improvements against CORE's 88.24% LoCoMo accuracy.

Observations

AutoMem is a multi-layered memory system with FalkorDB graph storage and Qdrant vector storage backends. The system currently supports temporal memory management, automatic memory classification into types (Decision, Pattern, Preference, etc.), entity extraction during enrichment, and multi-hop recall with entity-aware expansion. The consolidation engine performs dream-inspired memory processing including relevance scoring, creative association discovery, and controlled forgetting. A comprehensive LoCoMo benchmark infrastructure exists with a CORE adapter (evaluate.js) for direct performance comparison.

Assumptions

Assumption 1: Statement Extraction and Storage Model

Options Considered:

• Create a separate Statement node type alongside Memory nodes, maintaining episodic memories while extracting factual statements
• Extend the existing Memory model with statement metadata fields to store extracted statements within memory nodes
• Add a post-processing stage that creates derived Statement memories from original episodic memories

Chosen Option: Create a separate Statement node type alongside Memory nodes, maintaining episodic memories while extracting factual statements

Rationale: This preserves CORE's architecture where statements maintain provenance to their episodic source, enables fact-based recall alongside context-based recall, and aligns with AutoMem's existing graph-oriented design. Statements become first-class entities queryable independently while maintaining bidirectional links to their conversational context.

Assumption 2: Provenance and Source Tracking Implementation

Options Considered:

• Add standardized metadata fields (source, extracted_from, reliability) to the existing freeform metadata JSON
• Create new top-level fields on Memory nodes for provenance tracking
• Implement provenance through relationships only (EXTRACTED_FROM, DERIVED_FROM edges)

Chosen Option: Create new top-level fields on Memory nodes for provenance tracking

Rationale: Combine top-level provenance fields with relationship-based tracking. Add source (origin identifier) and reliability (trustworthiness score 0.0-1.0) as indexed node properties for efficient filtering, while using EXTRACTED_FROM relationships to link statements to episodic memories. This enables CORE's filtering by reliability while maintaining backward compatibility with AutoMem's metadata approach.

Assumption 3: Contradiction Detection Strategy

Options Considered:

• Enhance consolidation's discover_associations() to detect contradictions using semantic analysis of statement pairs
• Create a dedicated contradiction detection service that runs during enrichment to identify conflicts immediately
• Use LLM-based contradiction detection at recall time to identify conflicts dynamically

Chosen Option: Create a dedicated contradiction detection service that runs during enrichment to identify conflicts immediately

Rationale: This aligns with CORE's Resolution stage, enables immediate conflict flagging when new statements contradict existing knowledge, and leverages the enrichment queue infrastructure AutoMem already has. Store contradiction metadata (reason, resolution status) in CONTRADICTS relationship properties that already exist in the schema.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Establish Statement Extraction Pipeline

This phase introduces CORE's statement extraction capability, transforming episodic memories into atomic factual statements while maintaining provenance links. Statement extraction runs during enrichment to avoid blocking the memory storage API.

Task 1: Extend Memory Model with Provenance Fields

Add standardized provenance tracking to support CORE's reliability-based filtering and source attribution.

• Add source field to Memory nodes in automem/stores/graph_store.py to track origin (e.g., "api", "conversation", "import")
• Add reliability float field (0.0-1.0) to Memory nodes for trustworthiness scoring, defaulting to 0.7 for user-provided memories
• Update memory storage query in automem/api/memory.py to persist source and reliability fields alongside existing metadata
• Modify automem/config.py to define default reliability scores for different memory sources
• Ensure backward compatibility by making these fields optional with sensible defaults

Task 2: Create Statement Node Type and Schema

Define Statement as a first-class graph entity alongside Memory nodes to enable fact-based recall.

• Add Statement node label to FalkorDB schema in automem/stores/graph_store.py with properties: content, entity_ids, relationship_type, timestamp, confidence, source, reliability
• Define EXTRACTED_FROM relationship type connecting Statement nodes to source Memory nodes with properties: extraction_timestamp, extraction_confidence
• Update automem/config.py MEMORY_TYPES to include "Statement" as a distinct classification
• Create utility functions in automem/stores/graph_store.py for Statement CRUD operations (create_statement, link_to_source_memory)

Task 3: Implement Statement Extraction Service

Build the core extraction logic that transforms episodic memories into structured statements with entity-relationship triplets.

• Create automem/services/extraction.py module implementing extract_statements_from_memory() function
• Use LLM prompting (OpenAI) to identify entities, relationships, and statements from memory content following CORE's pattern (Entity → Statement → Relationship)
• Parse LLM response to extract structured data: entities (people, tools, projects, concepts), statements (factual claims), relationships (action verbs connecting entities)
• Generate confidence scores based on extraction quality and source reliability
• Return list of Statement objects with metadata ready for graph insertion

Task 4: Integrate Statement Extraction into Enrichment Pipeline

Connect statement extraction to AutoMem's existing enrichment workflow to process memories asynchronously.

• Modify enrichment worker in the application initialization layer (likely app.py) to call extract_statements_from_memory() for each queued memory
• Store extracted Statement nodes in FalkorDB with EXTRACTED_FROM relationships linking back to source Memory nodes
• Update entity extraction logic in enrichment to populate entity tags on Statement nodes in addition to Memory nodes
• Preserve existing enrichment functionality (entity tagging, metadata updates) while adding statement extraction as a new enrichment stage
• Add error handling and retry logic for statement extraction failures without blocking other enrichment tasks

🤖 Prompt for AI agents

Implement statement extraction pipeline to transform episodic memories into
atomic factual statements with provenance tracking.

Extend Memory node schema with `source` and `reliability` fields in
graph_store.py
Create Statement node type with properties: content, entity_ids,
relationship_type, timestamp, confidence, source, reliability
Define EXTRACTED_FROM relationship connecting Statements to source Memories
Add Statement CRUD utilities in graph_store.py
Update config.py with default reliability scores and Statement memory type

Create automem/services/extraction.py with extract_statements_from_memory()
function
Use LLM to parse memory content into entity-relationship triplets following
CORE's pattern
Generate confidence scores based on extraction quality

Integrate extraction into enrichment pipeline in app.py
Call extract_statements_from_memory() for each queued memory
Store Statement nodes with EXTRACTED_FROM relationships to source memories
Add error handling without blocking other enrichment tasks

Phase 2: Implement Contradiction Detection and Resolution

This phase adds CORE's Resolution capabilities to detect conflicting statements, track perspective evolution, and preserve multiple viewpoints with resolution metadata.

Task 1: Create Contradiction Detection Logic

Build semantic analysis to identify contradictory statements within the knowledge graph.

• Create automem/services/contradiction.py module implementing detect_contradictions() function
• For each new Statement, query graph for existing Statements with overlapping entities and similar topics using semantic search
• Use LLM-based comparison to identify contradictions (e.g., "X uses Y" vs "X uses Z" for mutually exclusive technologies)
• Compute contradiction confidence based on semantic opposition and temporal distance (recent vs old statements)
• Return pairs of contradicting Statement nodes with contradiction metadata (reason, confidence)

Task 2: Store Contradiction Relationships with Resolution Metadata

Leverage AutoMem's existing CONTRADICTS relationship type to preserve conflicting perspectives.

• Extend CONTRADICTS relationship properties in automem/config.py to include: reason (explanation text), confidence (0.0-1.0), detected_at (timestamp), resolution_status (enum: "unresolved", "superseded", "preference_shift", "context_dependent")
• Create CONTRADICTS edges between Statement nodes in automem/stores/graph_store.py with full metadata
• Ensure bidirectional navigation of contradictions using Cypher queries
• Add utility function create_contradiction() in automem/stores/graph_store.py for inserting CONTRADICTS relationships

Task 3: Integrate Contradiction Detection into Enrichment

Run contradiction detection automatically when new statements are extracted to maintain knowledge graph integrity.

• Add detect_contradictions() call to enrichment pipeline after statement extraction completes
• For each detected contradiction, create CONTRADICTS relationship with appropriate metadata
• Update source Memory nodes to flag them with has_contradictions: true metadata field for recall filtering
• Implement batching to avoid O(N²) comparisons - only check new statements against recent/relevant existing statements
• Add configuration in automem/config.py for contradiction detection thresholds and lookback windows

Task 4: Expose Contradiction Information in Recall API

Surface contradiction metadata during memory retrieval to inform users of conflicting information.

• Modify recall response in automem/api/recall.py to include contradiction warnings when returned memories have contradicting statements
• Add optional include_contradictions parameter to recall API for fetching related contradictory statements
• Include resolution_status in response to indicate whether contradictions are resolved or active
• Update metadata scoring in recall to optionally down-rank memories with unresolved contradictions based on configuration

🤖 Prompt for AI agents

Implement contradiction detection and resolution to identify conflicting
statements and preserve multiple perspectives.

Create automem/services/contradiction.py with detect_contradictions() function
Query graph for Statements with overlapping entities using semantic search
Use LLM to identify contradictions between statement pairs
Compute contradiction confidence from semantic opposition and temporal distance

Extend CONTRADICTS relationship in config.py with properties: reason,
confidence, detected_at, resolution_status
Add create_contradiction() utility in graph_store.py for inserting CONTRADICTS
relationships
Ensure bidirectional navigation using Cypher queries

Integrate detect_contradictions() into enrichment pipeline after statement
extraction
Create CONTRADICTS relationships for detected conflicts
Flag source Memory nodes with has_contradictions metadata
Implement batching to avoid O(N²) comparisons

Modify recall.py to include contradiction warnings in responses
Add include_contradictions parameter to fetch related conflicting statements
Expose resolution_status and optionally down-rank unresolved contradictions

Phase 3: Enhance Recall with Statement-Based Retrieval and Re-Ranking

This phase implements CORE's multi-strategy search (facts vs episodes) and sophisticated re-ranking to improve recall accuracy and diversity.

Task 1: Add Statement-Based Recall Path

Enable querying against extracted statements in addition to episodic memories for fact-focused queries.

• Extend automem/api/recall.py to support statement_search mode that queries Statement nodes rather than Memory nodes
• Implement hybrid recall strategy: search both Statements (for factual queries) and Memories (for contextual queries) in parallel
• Use query analysis to determine whether to prioritize statements or episodes based on question type (e.g., "What technology does X use?" → statements, "When did we discuss X?" → memories)
• Merge results from both searches with source indicators (statement vs episode) for transparency

Task 2: Implement Diversity-Based Re-Ranking

Add CORE's diversity-aware re-ranking to surface varied perspectives rather than redundant similar results.

• Create automem/services/reranking.py module implementing diversify_results() function
• After initial vector/graph search, cluster results by semantic similarity to identify redundant matches
• Apply maximal marginal relevance (MMR) algorithm: iteratively select results that balance relevance (original score) and diversity (dissimilarity to already-selected results)
• Adjust diversity weight based on query type (higher diversity for exploratory queries, lower for specific fact lookups)
• Return reordered results that highlight both obvious matches and deeper connections

Task 3: Add Reliability-Based Filtering

Implement CORE's filtering by relationship strength and reliability to surface high-quality knowledge.

• Extend automem/api/recall.py filtering logic to support min_reliability parameter (default 0.5)
• Filter Statement nodes and Memory nodes by reliability field before vector search to exclude low-quality entries
• Apply relationship strength filtering when performing graph traversal in multi-hop recall (already partially implemented)
• Add configuration in automem/config.py for default reliability thresholds per memory type
• Expose reliability scores in recall response for transparency

Task 4: Enhance Recall Response with Statement Context

Provide both statements (facts) and episodes (context) in recall responses following CORE's output model.

• Modify recall response schema in automem/api/recall.py to return structured data: facts (array of Statement nodes) and episodes (array of source Memory nodes)
• For each returned Statement, include EXTRACTED_FROM relationship data to link back to episodic source
• Add context field to statements containing relevant excerpts from source memories
• Maintain backward compatibility by keeping existing response format as default with optional include_statements: true parameter

🤖 Prompt for AI agents

Enhance recall with statement-based retrieval, diversity re-ranking, and
reliability filtering.

Extend recall.py to support statement_search mode querying Statement nodes
Implement hybrid recall searching both Statements and Memories in parallel
Use query analysis to prioritize statements vs episodes based on question type
Merge results with source indicators

Create automem/services/reranking.py with diversify_results() function
Cluster results by semantic similarity to identify redundancy
Apply maximal marginal relevance (MMR) algorithm balancing relevance and
diversity
Adjust diversity weight based on query type

Add min_reliability parameter to recall.py filtering logic
Filter Statement/Memory nodes by reliability before vector search
Apply relationship strength filtering in multi-hop recall
Add reliability thresholds to config.py

Modify recall response schema to return facts (Statements) and episodes
(Memories)
Include EXTRACTED_FROM relationship data linking statements to sources
Add context field with source memory excerpts
Maintain backward compatibility with include_statements parameter

Phase 4: Benchmark Validation and Optimization

This phase validates improvements against CORE's benchmark performance and optimizes the system based on results.

Task 1: Run CORE Adapter Benchmark

Execute comparative evaluation using the existing CORE adapter to measure current vs improved performance.

• Run baseline benchmark using tests/benchmarks/core_adapter/evaluate.js to establish current AutoMem performance on LoCoMo dataset
• Document baseline results across all 5 categories: single-hop, multi-hop, temporal reasoning, open-domain knowledge, complex reasoning
• Compare against CORE's reported 88.24% average accuracy to identify performance gaps
• Save baseline results as BENCHMARK_BASELINE_PRE_CORE_INTEGRATION.md for historical tracking

Task 2: Run Post-Implementation Benchmarks

Measure performance impact of statement extraction, contradiction detection, and enhanced recall.

• After implementing Phases 1-3, run full LoCoMo benchmark again using the CORE adapter
• Test with both legacy recall mode (memories only) and hybrid mode (statements + memories) to measure improvement delta
• Analyze category-specific improvements to identify which CORE features impact which reasoning tasks
• Generate evaluation_results.json output and compare against CORE's benchmark scores

Task 3: Optimize Statement Extraction and Recall

Fine-tune implementation based on benchmark results to close performance gap with CORE.

• Profile statement extraction quality - identify where LLM extractions miss key information or hallucinate
• Tune contradiction detection thresholds to balance precision (avoid false positives) vs recall (catch real contradictions)
• Adjust re-ranking diversity weights based on category performance (e.g., more diversity for multi-hop queries)
• Optimize reliability scoring defaults based on which thresholds yield best benchmark accuracy
• Iterate on prompts and configurations until performance meets or exceeds CORE's 88.24% benchmark

Task 4: Document Benchmark Results and Findings

Create comprehensive documentation comparing AutoMem + CORE features vs baseline AutoMem vs CORE.

• Create BENCHMARK_CORE_INTEGRATION_RESULTS.md documenting: baseline scores, post-integration scores, improvement deltas, feature-specific impact analysis
• Include breakdown by LoCoMo category showing where statement extraction and contradiction detection provide most value
• Document optimal configuration parameters discovered during optimization
• Provide recommendations for when to use statement-based vs memory-based recall based on query patterns observed in benchmarks

🤖 Prompt for AI agents

Validate improvements through benchmarking and optimize based on results.

Run baseline benchmark using tests/benchmarks/core_adapter/evaluate.js on LoCoMo
dataset
Document results across 5 categories: single-hop, multi-hop, temporal reasoning,
open-domain knowledge, complex reasoning
Compare against CORE's 88.24% accuracy
Save results as BENCHMARK_BASELINE_PRE_CORE_INTEGRATION.md

Run post-implementation benchmarks after Phases 1-3
Test legacy recall (memories only) vs hybrid mode (statements + memories)
Analyze category-specific improvements
Generate evaluation_results.json and compare to CORE

Profile extraction quality and identify LLM issues
Tune contradiction detection thresholds for precision/recall balance
Adjust re-ranking diversity weights based on category performance
Optimize reliability scoring defaults
Iterate until meeting or exceeding CORE's 88.24% benchmark

Create BENCHMARK_CORE_INTEGRATION_RESULTS.md with baseline, post-integration
scores, deltas, and impact analysis
Breakdown by LoCoMo category
Document optimal configuration parameters
Provide recommendations for statement vs memory-based recall

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement statement extraction pipeline to transform episodic memories into
atomic factual statements with provenance tracking.

Extend Memory node schema with `source` and `reliability` fields in
graph_store.py
Create Statement node type with properties: content, entity_ids,
relationship_type, timestamp, confidence, source, reliability
Define EXTRACTED_FROM relationship connecting Statements to source Memories
Add Statement CRUD utilities in graph_store.py
Update config.py with default reliability scores and Statement memory type

Create automem/services/extraction.py with extract_statements_from_memory()
function
Use LLM to parse memory content into entity-relationship triplets following
CORE's pattern
Generate confidence scores based on extraction quality

Integrate extraction into enrichment pipeline in app.py
Call extract_statements_from_memory() for each queued memory
Store Statement nodes with EXTRACTED_FROM relationships to source memories
Add error handling without blocking other enrichment tasks
===============================================================================

Task: 2

Implement contradiction detection and resolution to identify conflicting
statements and preserve multiple perspectives.

Create automem/services/contradiction.py with detect_contradictions() function
Query graph for Statements with overlapping entities using semantic search
Use LLM to identify contradictions between statement pairs
Compute contradiction confidence from semantic opposition and temporal distance

Extend CONTRADICTS relationship in config.py with properties: reason,
confidence, detected_at, resolution_status
Add create_contradiction() utility in graph_store.py for inserting CONTRADICTS
relationships
Ensure bidirectional navigation using Cypher queries

Integrate detect_contradictions() into enrichment pipeline after statement
extraction
Create CONTRADICTS relationships for detected conflicts
Flag source Memory nodes with has_contradictions metadata
Implement batching to avoid O(N²) comparisons

Modify recall.py to include contradiction warnings in responses
Add include_contradictions parameter to fetch related conflicting statements
Expose resolution_status and optionally down-rank unresolved contradictions
===============================================================================

Task: 3

Enhance recall with statement-based retrieval, diversity re-ranking, and
reliability filtering.

Extend recall.py to support statement_search mode querying Statement nodes
Implement hybrid recall searching both Statements and Memories in parallel
Use query analysis to prioritize statements vs episodes based on question type
Merge results with source indicators

Create automem/services/reranking.py with diversify_results() function
Cluster results by semantic similarity to identify redundancy
Apply maximal marginal relevance (MMR) algorithm balancing relevance and
diversity
Adjust diversity weight based on query type

Add min_reliability parameter to recall.py filtering logic
Filter Statement/Memory nodes by reliability before vector search
Apply relationship strength filtering in multi-hop recall
Add reliability thresholds to config.py

Modify recall response schema to return facts (Statements) and episodes
(Memories)
Include EXTRACTED_FROM relationship data linking statements to sources
Add context field with source memory excerpts
Maintain backward compatibility with include_statements parameter
===============================================================================

Task: 4

Validate improvements through benchmarking and optimize based on results.

Run baseline benchmark using tests/benchmarks/core_adapter/evaluate.js on LoCoMo
dataset
Document results across 5 categories: single-hop, multi-hop, temporal reasoning,
open-domain knowledge, complex reasoning
Compare against CORE's 88.24% accuracy
Save results as BENCHMARK_BASELINE_PRE_CORE_INTEGRATION.md

Run post-implementation benchmarks after Phases 1-3
Test legacy recall (memories only) vs hybrid mode (statements + memories)
Analyze category-specific improvements
Generate evaluation_results.json and compare to CORE

Profile extraction quality and identify LLM issues
Tune contradiction detection thresholds for precision/recall balance
Adjust re-ranking diversity weights based on category performance
Optimize reliability scoring defaults
Iterate until meeting or exceeding CORE's 88.24% benchmark

Create BENCHMARK_CORE_INTEGRATION_RESULTS.md with baseline, post-integration
scores, deltas, and impact analysis
Breakdown by LoCoMo category
Document optimal configuration parameters
Provide recommendations for statement vs memory-based recall

💡 Iterate on the plan with: @coderabbitai <feedback>

Example Feedback
- @coderabbitai You can skip phase 3. Add a simple unit test case for phase 2.
- @coderabbitai For assumption 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord or schedule a call!

[Sophist-UK]

I just came across this repo after discussing memory requirements for AI here.

And apologies in advance for the length of this comment and the brain dump nature.

Summary: Scalability (large scale memory association complexity, performance and costs (storage, memory processing and excessive tokens for processing)) and Privacy (leakage, security classifications, domain separation) and Auditability are significant areas of concern.

Auditability: You need human readable text alongside vectors so that you can check memories are correct and edit or delete to make corrections. You need functional support to enable such reviews. You also need to check that human readable version and vector versions align - otherwise that would be a hacker entry point. To limit these audits to recent changes, you need an immutable change journal. You need consistency management to avoid inconsistent memories being stored that week create confusion - humans change their minds, and obsolete choices need to be replaced rather than having conflicting memories.)

Scalability: Over future decades memories will grow - AI agents are relatively newborn now and memory requirements are still small, but they won't stay that way. This growth will bring many challenges, and probably take a mixture of mimicking how human brains cope and hard learned IT security best practices. Memories have different levels of sensitivity, and certain agents should only have access to certain memories. (I wouldn't want an email agent replying to my work emails to have access to my ai-assisted erotic fiction history.) Some memories should be ephemeral i.e. package tracking codes are probably not needed more than (say) a week after the package has arrived - if it doesn't arrive you might want to remember it for longer, but in 2 years time do you really need to remember it? Recent memories should probably have higher priority - if I want to e.g. include the contract of an old friend in an ai completion, I don't want to send 1M tokens containing every memory I have of that person. Like human memories, default associative retrieval of older memories should have narrowed context, but (unlike human memories) should definitely still be retrievable by a detailed search. Partitioned storage may be needed so that frequent/recent memories are on fast, relatively expensive storage, whilst long term, infrequently accessed memories should be on slower cheaper storage. For true scalability/availability/resilience (think Enterprise scale rulesets), a federated/hierarchical storage approach might be needed.

Privacy/Security: Leakage of personal data is a major concern, and security needs to be built-in from the ground up and be incredibly well architected from the start. This is complicated and needs proper thought, but e.g you might want to define domains and have one or several tags for each memory, and you need a layer of controls to say which agents (or groups of agents) can access which domains and tags, and perhaps some way to register and authenticate an agent using e.g. a key. You might want domains to be hierarchical i.e. business/personal, each containing sub-domains, and similarly for tags to be hierarchical (family, wife/son).

Bad news: this is a lot of work.
Good news: some of this is enterprise level which can be chargeable.
Good news: you seem to be at the forefront of this and taking a lead.
Good news: agentic coding can help a lot.

[Sophist-UK]

Just looked at the Reddit link and have the following additional thoughts:

1. Reddit suggests normalizing memories to a consistent style (which seems like a good idea) - but if you are going to do that, you may want to store the original text too.

2. I can also foresee the need of desire to store a semantic vector and plain text versions in several different languages.

3. The Reddit article suggests that performance might be an issue for even medium sized memory sets. Careful choice of underlying vector and graph technologies might be important.

4. Perhaps not all memories need to use graph associations. Could there be a subset where vector database is sufficient which would potentially reduce the overhead? If so, how do you present this through a unified interface?

5. If you are going to normalize answers, would it help graph scalability by creating a gist vector containing just keywords. Indeed, could this allow the vector database search to be sufficient?

6. Some of this stuff (in both these comments) sounds like it is going to need its own AI processing.

[Sophist-UK]

Interesting YouTube video from IBM on ai security, much of which is applicable to storage security...

https://youtu.be/d8d9EZHU7fw

[jack-arturo]

Hey @Sophist-UK, thanks for chiming in, and apologies for the delay in getting back to you... wanted to give this a proper response.

We actually just finished a DeepWiki scan of the Automem repo and I'm blown away by the quality of the docs it generates. A few of your questions/concerns would have sent me digging through the code but now it's all written out in detail (with diagrams!)

Auditability: AutoMem uses a dual graph + vector storage and recall methodology, but actually both the graph databases and vector databases are mirrors of each other— they store the same human-readable content, in almost exactly the same format.

(This has saved me a couple of times where one or the other services failed during the early days. If you forget to add persistent storage to the graph database 🫣, it can be fully restored from the vector database. There's even a script for that. )

More info at https://deepwiki.com/verygoodplugins/automem/4.1-data-stores

Scalability: Our consolidation logic is based on the way biological memory works, it runs in the background through recurring cycles of decay, creative, cluster, and forget.

All memories naturally decay over time (importance scores drop). When they decay far enough, they are archived, and then deleted. When a memory is recalled, its decay reverses (importance goes up). The idea is to keep relevant and important information persistent, while letting ephemeral things (today's weather, etc) naturally fade over time.

There's still some fine-tuning to be done there. Objectively, I feel like the decay is running too quickly in some cases. I've been running some tests on that this week. More info at https://deepwiki.com/verygoodplugins/automem/4.3.3-consolidation-engine

Privacy/Security: Memories are tagged when they're inserted, as well as by the background enrichment system. When performing a recall, you can use a tag query to gate responses by tag.

In our case, with software development, memories specific to a project are tagged to that project, and when we resume work, we pre-query based on the project tag to return only memories created in that scope.

However, an agent could decide to do a semantic recall, or a time-based recall, which would return any and all matching memories regardless of scope. There's been some discussion around adding a hard firewall between sets of memories. We will likely add it as an option, but I've so far never let down by the agent's discretion, and I've found a hard firewall between domains can create some unusual outcomes....

For example, my agent AutoJack has access to everything in my personal life and at work, stored in the same memory graph. An early test was to add him to a Slack channel with six trusted (though devious 😅) colleagues and leave him open for conversation 24/7.

I can see in the logs that the memory recalls would surface all kinds of personal context, but he never once let anything slip in a work context— even when asked directly.

I get that most people won't "trust" an AI to make that distinction, but in my case, it's working fine.

When I ran tests with a hard break between domains (internal Slack vs external Slack vs WhatsApp, etc.), it led to a kind of split personality disorder. The tone of the recall also informs how new memories are saved and associated.

The fact that AutoJack knows I was up all night with pain from an injury when a colleague asks whether I'll be able to fix X bug today, even if it isn't said in the conversation, affects the reply and then future memories, which are then recalled later... etc., building a single personality over time.

When memories were separated by Slack workspace, for example, after a few days, it became like chatting with two different agents. They had different priorities, used different sentence structures, different emojis, different tool preferences, incentive to take action vs wait for approval, etc.

For me, I have a single agent integrated into everything I do, so it's important to me that whether we're coding or cooking, I'm interacting with the same personality, and I know what to expect.

Of course, if you're building customer support chatbots or something, it makes total sense for their memory to be isolated. We'll certainly support it at a technical level. But you lose the "wow" factor that comes after working with a single agent for a week or two and suddenly it's able to make the same decisions you would make, or even push back when you're headed down a rabbit hole or neglecting other priorities. For me that's the most valuable aspect of the memory system and that only comes from giving the agent full context.

With regards to the Reddit post / additional thoughts, I believe we've already solved most of these problems in a scalable way. My own memory bank has ~9,000 memories and some 45,000 relationships between them, and even on the $5 / mo Railway plan, most of my recalls come in at under 100ms.

Because we don't store everything forever (like the human brain), I'm interested to see how that count changes over time.

Anecdotally, I feel like the memory count increased rapidly at the beginning, but has hovered around 8k or 9k for a month or more (though the number of associations continues to grow).

I don't see any technical ceiling, but due to the nature of the consolidate/decay/forget cycles, memory count naturally plateaus rather than growing linearly over time — so infrastructure requirements stay relatively flat regardless of how long the system has been running.

Starting to set up more large-scale tests in the coming weeks, and I'll be sure to post results. I'm interested now, too, in plotting memory + association counts over time, correlated with interactions, to see how the growth curve flattens as consolidation kicks in.

In the meantime take a look through https://deepwiki.com/verygoodplugins/automem/ for a deep dive into the tech side of it.

Happy to answer any more questions, thanks for chiming in, and welcome to the project 🙂