Generated banner for AutoMem
Generated logo for AutoMem

AutoMem

Memory framework

First committed by jack-arturo

Published in verygoodplugins/automem. Publisher page

827 GitHub stars

What it is

Long-term memory for AI assistants. Graph + vector store that recalls decisions, relationships, and context across sessions.
— the description by jack-arturo

AutoGineer overview, from the brain’s own files

AutoMem is a memory service designed to provide AI assistants with persistent, long-term recall. By combining a graph database (FalkorDB) for structured relationships and a vector database (Qdrant) for semantic search, it enables agents to retrieve not just similar snippets, but the context and reasoning behind past decisions. It supports a wide range of AI tools via the Model Context Protocol (MCP) and a REST API, allowing a single memory store to be shared across multiple platforms like Claude, Cursor, and GitHub Copilot. The system includes automated consolidation cycles to manage memory relevance and importance over time, ensuring that the agent's knowledge base remains efficient as history grows.

How it works

Memory model: Hybrid

AutoGineer overview, from the brain’s own files

AutoMem operates as a service with two primary storage layers: FalkorDB for storing memories as nodes with typed relationships, and Qdrant for storing vector embeddings. When an AI client requests a recall, the system performs a hybrid query that combines semantic similarity, graph traversal, and temporal alignment to rank results. A background enrichment pipeline and consolidation engine process memories to maintain relevance, while the MCP bridge allows various AI agents to interact with the memory service locally or remotely.

Folders
FolderRoleFiles
.githubagent-config9
docsdocs18
scriptsscripts39
teststests78
.railwayfolder2
automemfolder70
benchmarksfolder9
mcp-sse-serverfolder14

The agent reads

The agent writes

Requirements

Runtimes: Python

Databases: FalkorDB, MongoDB, PostgreSQL, Qdrant, Redis, SQLite

API keys (by name): ADMIN_API_TOKEN, AUTOMEM_API_TOKEN, AUTOMEM_TEST_ADMIN_TOKEN, AUTOMEM_TEST_API_TOKEN, CLASSIFICATION_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, QDRANT_API_KEY, VOYAGE_API_KEY

Works with: Claude Code, OpenAI Codex, GitHub Copilot, Cursor, Kiro, OpenCode, Amp, Cline, JetBrains Junie, Devin (ex-Windsurf)

Set it up

  1. This brain runs code automatically: 1 script. Review Makefile before opening the folder in Claude Code. No step below turns a hook on for you.

    • Makefile: echo "🔧 Setting up development environment..."; bash scripts/bootstrap_dev.sh; echo "✅ Virtual environment ready!"; echo "💡 Run 'source .venv/bin/activate' to activate"
  2. Not scanned by AutoGineerThe author’s README also describes installing it from a clone of its repository. Read its install section: AutoGineer did not scan that path. https://github.com/verygoodplugins/automem/blob/1a7ba1a6afe69835f62ad7f6013e33301d1ab83e/README.md#run-it
  3. First committed by jack-arturo. Published in verygoodplugins/automem. Licence: MIT License.

Usage

AutoGineer overview, from the brain’s own files

  • Connect local AI tools like Claude Desktop or Cursor to the AutoMem service via the MCP bridge.
  • Use the REST API to programmatically store decisions, preferences, and project context.
  • Query the memory service to retrieve the reasoning behind past technical choices or project milestones.
  • Deploy the memory service on local infrastructure or cloud platforms like Railway for persistent agent access.
“Why did we choose PostgreSQL?”
The agent retrieves the decision node, the rationale, and the considered alternatives, providing the context behind the architectural choice.
“What are our current preferences for message queues?”
The agent traverses the graph to identify the relationship between Kafka and RabbitMQ, surfacing the team's preference for 'boring technology'.

Documentation by jack-arturo

<p align="center"> <img src="https://automem.ai/img/G_Vd7EYWYAM_3SF.jpeg" alt="AutoMem" width="600" /> </p>

<p align="center"> <a href="https://www.npmjs.com/package/@verygoodplugins/mcp-automem"><img src="https://img.shields.io/npm/v/@verygoodplugins/mcp-automem?label=mcp-automem" alt="npm version" /></a> <a href="LICENSE"><img src="https://img.shields.io/github/license/verygoodplugins/automem" alt="License" /></a> <a href="https://automem.ai/discord"><img src="https://img.shields.io/badge/Discord-Join-5865F2?logo=discord&logoColor=white" alt="Discord" /></a> <a href="https://x.com/automem_ai"><img src="https://img.shields.io/badge/X-@automem__ai-000000?logo=x&logoColor=white" alt="X" /></a> <a href="https://automem.ai/benchmarks"><img src="https://img.shields.io/badge/LoCoMo%20(AMB)-85.1%25-success" alt="LoCoMo on the neutral Agent Memory Benchmark" /></a> <a href="benchmarks/EXPERIMENT_LOG.md#results"><img src="https://img.shields.io/badge/LongMemEval%20full-87.0%25-blueviolet" alt="LongMemEval full on AutoMem's internal harness: 87.0%" /></a> <a href="https://automem.ai/benchmarks"><img src="https://img.shields.io/badge/BEAM%2010M%20(AMB)-57.4%25-success" alt="BEAM 10M on the neutral Agent Memory Benchmark" /></a> <a href="https://railway.com/deploy/automem-ai-memory-service?referralCode=VuFE6g&utm_medium=integration&utm_source=github&utm_campaign=generic"><img src="https://img.shields.io/badge/Deploy%20on-Railway-0B0D0E?logo=railway&logoColor=white" alt="Deploy on Railway" /></a> </p>

<p align="center"> <strong>Long-term memory for AI assistants — fast, private, and yours.</strong> </p>

AutoMem

AutoMem gives your AI a memory that survives the chat.

Save the decisions, preferences, notes, and context that matter. The next time you open Claude, Cursor, Codex, ChatGPT, or another connected assistant, it can bring back the right details instead of making you repeat yourself.

Ask, “Why did we choose PostgreSQL?” and AutoMem can return the decision, the alternatives you considered, the principle behind it, and the work that followed — not just a pile of similarly worded snippets.

Why AutoMem feels different

No LLM call in the middle of recall. AutoMem looks up memories directly through its graph and vector index. That keeps normal retrieval fast and avoids an extra generative-LLM charge every time your assistant needs context. It still uses embeddings — from Voyage, OpenAI, or a local provider — and optional enrichment can add more structure over time.

More than vector search. A vector match finds something similar; AutoMem also records typed relationships between memories. It can follow the connections between a decision, its rationale, and its consequences, so your assistant has a better chance of returning the why, not only the words it recognizes.

One memory across your tools. Use the local MCP bridge with Claude Desktop, Cursor, Claude Code, Codex, Copilot, and more. For cloud agents, Remote MCP connects the same service to ChatGPT Developer Mode, Claude.ai, and ElevenLabs over HTTPS. Your memory is not locked to one chat app.

Own the data and the setup. Run AutoMem locally with Docker, on your own infrastructure, or as a small Railway service group. It exposes both MCP and a REST API, so it fits into the tools and workflows you already use.

Proven where long context gets hard

On the independent Agent Memory Benchmark's BEAM long-context tests, AutoMem scored 57.4% at 10 million source tokens while giving the answerer an average of only ~2.6–4.8k retrieved tokens. That is the kind of efficiency that lets memory stay useful as an agent's history grows.

The full picture — test setup, raw outputs, methodology, historical runs, and reproduction commands — is in automem.ai/benchmarks and benchmarks/EXPERIMENT_LOG.md.

How it works

AutoMem combines two storage layers behind a single API:

  • FalkorDB stores memories as nodes with 11 typed relationships between them. The graph is the canonical record.

  • Qdrant stores an embedding for every memory. Recall is a hybrid query — semantic similarity, graph traversal, temporal alignment, tag overlap, and importance — ranked by a 9-component score.

flowchart TB
    subgraph service [AutoMem Service Flask]
        API[REST API<br/>Memory Lifecycle]
        Enrichment[Background Enrichment<br/>Pipeline]
        Consolidation[Consolidation<br/>Engine]
        Backups[Automated Backups<br/>Optional]
    end

    subgraph storage [Dual Storage Layer]
        FalkorDB[(FalkorDB<br/>Graph Database)]
        Qdrant[(Qdrant<br/>Vector Database)]
    end

    Client[AI Client] -->|Store/Recall/Associate| API
    API --> FalkorDB
    API --> Qdrant
    Enrichment -->|11 edge types<br/>Pattern nodes| FalkorDB
    Enrichment -->|Semantic search<br/>1024-d vectors| Qdrant
    Consolidation --> FalkorDB
    Consolidation --> Qdrant
    Backups -.->|Optional| FalkorDB
    Backups -.->|Optional| Qdrant

If Qdrant is unavailable, the graph still serves recall in a degraded mode. If FalkorDB is down, the API returns 503 — the graph is the source of truth.

Multi-hop bridge discovery

Ask "why boring tech for Kafka?" and AutoMem doesn't just match the word "Kafka". It traverses the graph from the seed memories to find the bridge that connects them:

  • Seed 1: "Migrated to PostgreSQL for operational simplicity"

  • Seed 2: "Evaluating Kafka vs RabbitMQ for message queue"

  • Bridge: "Team prefers boring technology — proven, debuggable systems"

Both seeds carry an EXEMPLIFIES edge to the bridge memory. AutoMem ranks the bridge above the seeds and surfaces it in the recall response, so the assistant answers with your reasoning, not isolated facts. Tune via expand_relations, relation_limit, and expansion_limit on GET /recall.

11 authorable relationship types
TypeUse caseExample
RELATES_TOGeneral connectionBug report → Related issue
LEADS_TOCausal relationshipProblem → Solution
OCCURRED_BEFORETemporal sequencePlanning → Execution
PREFERS_OVERUser preferencesPostgreSQL → MongoDB
EXEMPLIFIESPattern examplesCode review → Best practice
CONTRADICTSConflicting infoOld approach → New approach
REINFORCESSupporting evidenceDecision → Validation
INVALIDATED_BYOutdated infoLegacy docs → Current docs
EVOLVED_INTOKnowledge evolutionInitial design → Final design
DERIVED_FROMSource trackingImplementation → Spec
PART_OFHierarchical structureFeature → Epic

Three more edge types are added automatically by the enrichment pipeline and consolidation engine: SIMILAR_TO, PRECEDED_BY, and DISCOVERED.

Memory consolidation, neuroscience-inspired

AutoMem implements biological memory consolidation cycles. Wrong rabbit holes fade naturally. Important memories with strong connections strengthen over time.

CycleFrequencyPurpose
DecayDailyExponential relevance scoring (age, access, connections, importance)
CreativeWeeklyREM-like processing that discovers non-obvious connections
ClusterMonthlyGroups similar memories, generates meta-patterns
ForgetOff by defaultArchives low-relevance memories (<0.2), deletes very old (<0.05)

Tune intervals via CONSOLIDATION_*_INTERVAL_SECONDS. See docs/ENVIRONMENT_VARIABLES.md.

For more on the recall scoring formula, enrichment internals, and how AutoMem differs from RAG and pure vector databases, see docs/COMPARISON.md.

Research foundation

AutoMem implements techniques from peer-reviewed memory research:

  • HippoRAG 2 (Ohio State, 2025) — graph + vector hybrid for associative memory

  • A-MEM (2025) — Zettelkasten-inspired dynamic memory organization

  • MELODI (DeepMind, 2024) — gist-based memory compression

  • ReadAgent (DeepMind, 2024) — episodic memory for context extension

Full writeups, findings, and how AutoMem implements each → docs/RESEARCH.md.

Run it

Railway (60 seconds)

Image: Deploy on Railway

Recommended Railway projects run AutoMem as a small service group: automem (the API), automem-graph-viewer (the standalone UI), falkordb (graph), qdrant (vectors), and mcp-automem (the MCP bridge for ChatGPT, Claude.ai, and ElevenLabs). Services use pre-built Docker images and auto-redeploy on :stable, so Railway does not spend compute rebuilding source.

→ Full setup: INSTALLATION.md

Docker Compose (local)
git clone https://github.com/verygoodplugins/automem.git
cd automem
make dev
ServiceURLPurpose
AutoMem APIhttp://localhost:8001Memory REST API
FalkorDBlocalhost:6379Graph database
Qdrantlocalhost:6333Vector database
FalkorDB Browserhttp://localhost:3000Local graph inspection UI

Database and browser ports bind to localhost by default; the API binding is unchanged.

→ Full setup: INSTALLATION.md

Python (development)
make install
source .venv/bin/activate
PORT=8001 python app.py

Requires Python 3.10+ (3.12 recommended). → INSTALLATION.md

Contributing: feature PRs target the develop branch. main only moves via validated release merges, so users deploying from main (e.g. Railway auto-deploys) see one deploy per release instead of one per PR.

Connect your AI

ClientModeSetup
Claude Desktop, Cursor, Claude Code, Codex, Copilot, AntigravityLocal MCP bridgenpx @verygoodplugins/mcp-automem setup
ChatGPT (developer mode), Claude.ai web/mobile, ElevenLabs AgentsRemote MCP (HTTPS)docs/MCP_SSE.md
Anything elseDirect REST APIdocs/API.md

The MCP bridge is published as @verygoodplugins/mcp-automem. It handles client-specific config (rules files, hooks, templates) and proxies to your AutoMem service — local or Railway.

Direct API call:

import requests

token = "your-automem-api-token"

requests.post(
    "https://your-automem.railway.app/memory",
    headers={"Authorization": f"Bearer {token}"},
    json={
        "content": "Chose PostgreSQL over MongoDB for ACID compliance",
        "type": "Decision",
        "tags": ["database", "architecture"],
        "importance": 0.9,
    },
)

Screenshots

<!-- CAPTURE CHECKLIST — replace each placeholder image once captured: 1. docs/img/graph-recall.png — FalkorDB browser at http://localhost:3000 showing a memory node with multiple typed edges visible (PREFERS_OVER, EXEMPLIFIES, RELATES_TO). Proves the graph is real. 2. docs/img/claude-recall.png — Claude Desktop conversation where the assistant cites a recalled memory inline, with the AutoMem MCP tool call visible in the trace. 3. docs/img/railway-services.png — Railway dashboard showing the production service group (automem, automem-graph-viewer, mcp-automem, qdrant, falkordb). A version exists as a GitHub user-attachment in INSTALLATION.md; capture a clean version and host it in-repo. Until each PNG exists, the table cells will render as broken-image icons on GitHub. -->

Screenshots will be added once the referenced in-repo image assets are available.

Known limitations

AutoMem is pre-1.0 and honest about its rough edges. The active ones for recall quality:

  • Tags are a hard gate, not a soft boost. Tags filter before scoring, so a memory missing the queried tag won't surface even on a perfect semantic match. Within a tag scope, high-importance off-topic memories can still over-rank — mitigated by the opt-in RECALL_RELEVANCE_GATE, not yet on by default (#130).

  • Temporal and preference updates. Recall doesn't yet reliably prefer the newest version of a conflicting fact, or fully resolve multi-session preference updates. The RECALL_RECENCY_BIAS=auto re-rank helps temporal-intent queries but stays opt-in pending broader validation (#158, #159).

  • The MCP SSE bridge doesn't forward state_mode. The HTTP recall API supports it; the SSE proxy doesn't pass it through yet (#172).

  • Entity-node synthesis is experimental and off by default. First-class Entity nodes (IDENTITY_SYNTHESIS_ENABLED) are gated off while people-entity word-pair noise is addressed (#181).

Docs, community, and license

Setup

API and integration

  • API reference — endpoints, scoring, enrichment

  • Remote MCP — ChatGPT, Claude.ai, ElevenLabs

  • Migrations — embedding dimensions, 0.16.0 data migrations, MCP SQLite import

Research and comparison

Operations

Community

Sibling repos

MIT licensed. Deploy anywhere. No vendor lock-in.

docs/HEALTH_MONITORING.md

Health Monitoring Guide

AutoMem includes a built-in health monitoring system that watches for data inconsistencies and optionally triggers automatic recovery.

For the current command catalog and safety notes for health_monitor.py and recover_from_qdrant.py, see scripts/README.md.

Quick Start

# Run health checks every 5 minutes (alert only, no auto-recovery)
python scripts/health_monitor.py --interval 300

This will:

  • ✅ Monitor FalkorDB, Qdrant, and API health

  • ✅ Check memory count consistency

  • ✅ Log warnings if drift detected

  • ✅ Send alerts via webhook (if configured)

  • ❌ NOT automatically trigger recovery (safe!)

With Webhook Alerts
# Send alerts to Slack/Discord/etc
python scripts/health_monitor.py \
  --interval 300 \
  --webhook https://hooks.slack.com/services/YOUR/WEBHOOK/URL

Safety Features

Default: Alert Only

By design, auto-recovery is DISABLED by default. This prevents unexpected system changes without human oversight.

When drift is detected, the monitor will:

  1. Log a warning with drift percentage

  2. Send webhook alert (if configured)

  3. Provide recovery command to run manually

  4. NOT automatically trigger recovery

Opt-In Auto-Recovery

To enable auto-recovery (use with caution):

python scripts/health_monitor.py \
  --auto-recover \
  --interval 300 \
  --webhook https://your-webhook-url

10-second safety delay: When starting with --auto-recover, you have 10 seconds to cancel (Ctrl+C) before it activates.


Thresholds

Warning Threshold (5% default)

Minor drift - sends warning alert but does not trigger recovery.

Example: FalkorDB has 610 memories, Qdrant has 636 (4.1% drift)

  • Status: Warning

  • Action: Alert sent

  • Recovery: No

Critical Threshold (50% default)

Major data loss - triggers recovery process (if enabled).

Example: FalkorDB has 200 memories, Qdrant has 636 (68.6% drift)

  • Status: Critical

  • Action: Alert sent; with --auto-recover, missing graph memories are salvaged only if FalkorDB has fewer memories than Qdrant. A Qdrant deficit requires manual vector repair.

  • Recovery: Yes (if enabled)

Customize Thresholds
python scripts/health_monitor.py \
  --drift-threshold 10 \
  --critical-threshold 30 \
  --interval 300

Or via environment:

export HEALTH_MONITOR_DRIFT_THRESHOLD=10
export HEALTH_MONITOR_CRITICAL_THRESHOLD=30
python scripts/health_monitor.py --interval 300

Alert Channels

Webhook (Slack, Discord, etc.)
# Slack
python scripts/health_monitor.py \
  --webhook https://hooks.slack.com/services/T00/B00/XXXX

# Discord
python scripts/health_monitor.py \
  --webhook https://discord.com/api/webhooks/XXXX/YYYY

Webhook Payload:

{
  "level": "critical",
  "title": "Data Loss Detected - Manual Recovery Required",
  "message": "Major data loss detected. Drift: 68.6%",
  "details": {
    "drift_percent": 68.6,
    "auto_recover_enabled": false,
    "recovery_command": "python scripts/recover_from_qdrant.py"
  },
  "timestamp": "2025-10-05T12:00:00Z",
  "system": "AutoMem Health Monitor"
}
Email (Coming Soon)

Email alerts are planned but not yet implemented. Use webhooks for now.


Usage Examples

One-Time Health Check
# Quick check without continuous monitoring
python scripts/health_monitor.py --once

Output:

{
  "timestamp": "2025-10-05T12:00:00Z",
  "falkordb": {
    "status": "healthy",
    "memory_count": 636
  },
  "qdrant": {
    "status": "healthy",
    "points_count": 636
  },
  "api": {
    "status": "healthy"
  },
  "consistency": {
    "status": "consistent",
    "drift_percent": 0.0
  }
}
Continuous Monitoring (Production)
# Run as background service with systemd
sudo tee /etc/systemd/system/automem-health.service << EOF
[Unit]
Description=AutoMem Health Monitor
After=network.target

[Service]
Type=simple
User=automem
WorkingDirectory=/opt/automem
Environment="PATH=/opt/automem/venv/bin:/usr/bin"
ExecStart=/opt/automem/venv/bin/python scripts/health_monitor.py --interval 300 --webhook https://your-webhook
Restart=always
RestartSec=60

[Install]
WantedBy=multi-tier.target
EOF

sudo systemctl enable automem-health
sudo systemctl start automem-health
Docker Compose

Add to docker-compose.yml:

services:
  health-monitor:
    build: .
    command: python scripts/health_monitor.py --interval 300
    environment:
      - FALKORDB_HOST=falkordb
      - QDRANT_URL=http://qdrant:6333
      - AUTOMEM_API_URL=http://flask-api:8001
      - HEALTH_MONITOR_WEBHOOK=${WEBHOOK_URL}
    depends_on:
      - falkordb
      - qdrant
      - flask-api
    restart: unless-stopped
Railway Deployment

Deploy as separate service:

  1. Create new service: "Health Monitor"

  2. Use same repo, different start command

  3. Set environment variables:

    FALKORDB_HOST=${{FalkorDB.RAILWAY_PRIVATE_DOMAIN}}
    QDRANT_URL=${{Qdrant.QDRANT_URL}}
    AUTOMEM_API_URL=${{AutoMemAPI.RAILWAY_PUBLIC_DOMAIN}}
    HEALTH_MONITOR_WEBHOOK=https://your-webhook
  4. Start command: python scripts/health_monitor.py --interval 300


What Gets Monitored

FalkorDB Health
  • ✅ Connection status

  • ✅ Memory count (via MATCH (m:Memory) RETURN count(m))

  • ✅ Response time

  • ❌ Graph integrity (coming soon)

Qdrant Health
  • ✅ Connection status

  • ✅ Points count

  • ✅ Collection status

  • ❌ Vector quality (coming soon)

API Health
  • ✅ HTTP status (via /health endpoint)

  • ✅ Response time

  • ✅ FalkorDB/Qdrant connection status from API

Threshold precedence is explicit CLI flag > environment variable > default. --drift-threshold 0 and --critical-threshold 0 are accepted.

Consistency Check
  • ✅ Memory count drift between FalkorDB and Qdrant

  • ✅ Drift percentage calculation

  • ✅ Severity classification (ok/warning/critical)

  • ❌ Content checksum validation (coming soon)


Recovery Behavior

Alert-Only Mode (Default)

When critical drift detected:

  1. Log warning:

    ⚠️  CRITICAL: FalkorDB has 68.6% drift from Qdrant
    🚨 AUTO-RECOVERY DISABLED - Please run recovery manually:
       python scripts/recover_from_qdrant.py
  2. Send webhook alert:

    • Level: critical

    • Title: "Data Loss Detected - Manual Recovery Required"

    • Includes recovery command

  3. No automatic action - human decides when to recover

Auto-Recovery Mode (Opt-In)

When critical drift is detected and FalkorDB has fewer memories than Qdrant:

  1. Send "recovery starting" alert

  2. Execute the adjacent recover_from_qdrant.py script to insert missing Memory nodes without deleting or overwriting existing graph data.

  3. Monitor recovery progress

  4. Send completion/failure alert

Qdrant payloads contain no graph edges or Entity nodes. Salvage preserves surviving relationships but cannot restore lost ones. Re-enrichment can recreate some derived relationships; a FalkorDB backup is needed for the original graph. Prefer python scripts/restore_from_backup.py --dry-run --falkordb-only when a graph backup is available. Auto-recovery does not select or apply backups automatically.

The source is fully fetched and validated before graph writes. An empty/invalid source or any failed write returns a nonzero exit code, reported as recovery failure. If Qdrant has fewer memories, the monitor alerts for manual vector repair and does not run graph recovery. Memory counts alone do not prove data integrity.

Example Alert Flow:

1. 🚨 CRITICAL: Data Loss Detected
   → Webhook: "Data Loss Detected"

2. 🔧 AUTO-RECOVERY ENABLED: Starting recovery
   → Webhook: "Auto-Recovery Triggered"

3. ✅ Recovery completed successfully
   → Webhook: "Auto-Recovery Completed - 636 memories restored"

Troubleshooting

Monitor Won't Start

Error: Cannot connect to FalkorDB

Fix: Check environment variables:

echo $FALKORDB_HOST
echo $FALKORDB_PORT
echo $FALKORDB_PASSWORD
No Alerts Received

Check webhook URL:

curl -X POST https://your-webhook-url \
  -H "Content-Type: application/json" \
  -d '{"text":"Test alert from AutoMem"}'
False Positive Alerts

Drift can occur normally due to:

  • In-flight writes (memory being stored)

  • Consolidation in progress

  • Network delays

Solution: Increase drift threshold:

python scripts/health_monitor.py --drift-threshold 10  # More lenient
Recovery Not Triggering

Auto-recovery only triggers when:

  1. --auto-recover flag is set

  2. Drift exceeds critical threshold (default: 50%)

  3. Both stores are healthy and FalkorDB has fewer memories than Qdrant

Check: Run one-time check to see current drift:

python scripts/health_monitor.py --once | grep drift_percent

Best Practices

Production Recommendations
  1. Start with alert-only mode - monitor for a week before enabling auto-recovery

  2. Set up webhook alerts - know immediately when issues occur

  3. Run as systemd service - restart automatically if it crashes

  4. Monitor the monitor - use systemd status checks

  5. Test recovery manually - verify it works before enabling auto-recovery

When to Enable Auto-Recovery

✅ Good use cases:

  • Stable production environment

  • Tested recovery process multiple times

  • 24/7 webhook monitoring

  • Clear runbooks for failures

❌ Bad use cases:

  • Development/staging environments

  • Untested recovery process

  • No alerting configured

  • Unclear root cause of drift

Alert Fatigue Prevention
  • Set appropriate thresholds (too sensitive = noise)

  • Use different channels for warnings vs critical

  • Implement rate limiting (built-in: won't spam)

  • Review and adjust thresholds based on experience


See Also

273 files · 249 not served here

Advantages

  • Avoids redundant LLM calls during recall by using direct graph and vector index lookups. evidence: README.md
  • Records typed relationships between memories to surface the 'why' behind decisions rather than just isolated facts. evidence: README.md
  • Provides a unified memory store accessible across multiple different AI tools and chat applications. evidence: README.md

Limitations

  • Tags act as a hard filter, meaning memories without the queried tag are excluded even if they are semantically relevant. evidence: README.md
  • The system does not yet reliably resolve conflicting facts or prioritize the newest version of information automatically. evidence: README.md
  • The MCP SSE bridge currently lacks support for passing through state_mode configurations. evidence: README.md

Security

Risk level: Medium risk

This brain runs

Git hooks (8)

  • .pre-commit-config.yaml: pre-commit hooks from https://github.com/psf/black at 24.4.2 (contributor tooling: runs only after pre-commit install) · uses the network
  • .pre-commit-config.yaml: pre-commit hooks from https://github.com/pycqa/isort at 5.13.2 (contributor tooling: runs only after pre-commit install) · uses the network
  • .pre-commit-config.yaml: pre-commit hooks from https://github.com/pycqa/flake8 at 7.1.1 (contributor tooling: runs only after pre-commit install) · uses the network
  • .pre-commit-config.yaml: pre-commit hooks from https://github.com/compilerla/conventional-pre-commit at v3.2.0 (contributor tooling: runs only after pre-commit install) · uses the network
  • .pre-commit-config.yaml: pre-commit hooks from https://github.com/pre-commit/pre-commit-hooks at v4.6.0 (contributor tooling: runs only after pre-commit install) · uses the network
  • .pre-commit-config.yaml: pre-commit hooks from https://github.com/Yelp/detect-secrets at v1.5.0 (contributor tooling: runs only after pre-commit install) · uses the network
  • .pre-commit-config.yaml: bash -c 'PYTEST_DISABLE_PLUGIN_AUTOLOAD=1 ./venv/bin/pytest tests/ --ignore=tests/benchmarks --ignore=tests/test_integration.py -x -q'
  • .pre-commit-config.yaml: bash -c 'command -v coderabbit >/dev/null 2>&1 || { echo "coderabbit CLI not installed, skipping"; exit 0; }; coderabbit review --type committed --plain'

Agent instructions that run or fetch something (39)

  • AGENTS.md: `make install`: Create `.venv` (and symlink `venv -> .venv`) and install dev deps.
  • AGENTS.md: `make dev`: Start local stack via Docker (FalkorDB, Qdrant, API).
  • AGENTS.md: `make test`: Run unit tests (fast, no services).
  • AGENTS.md: `make test-integration`: Start Docker and run full integration tests.
  • AGENTS.md: `make fmt` / `make lint`: Format with Black/Isort and lint with Flake8.
  • AGENTS.md: `make bench-eval BENCH=locomo-mini`: Run snapshot-based benchmark (~2 min).
  • AGENTS.md: `make deploy` / `make status`: Deploy/check Railway.
  • AGENTS.md: Quick health: `curl :8001/health`. · uses the network
  • AGENTS.md: Run `pre-commit install` and `make fmt && make lint` before committing.
  • AGENTS.md: Unit tests: `make test`.
  • AGENTS.md: Integration: `make test-integration` (requires Docker).
  • AGENTS.md: | Tier | Benchmark | Command | Runtime | Cost | When to use | |------|-----------|---------|---------|------|-------------| | 0 | Unit tests | `make test` | 30s | free | Every change | | 1 | LoCoMo-mini (2 convos, 304 Qs) | `make bench-eval BENCH=locomo-mini` | 2-3 min | free / ~$0.20 …[+355 chars]
  • AGENTS.md: `make bench-eval BENCH=locomo-mini CONFIG=baseline` — eval from snapshot (~2 min).
  • AGENTS.md: `make bench-compare BENCH=locomo CONFIG=<name> BASELINE=baseline` — A/B compare two configs.
  • AGENTS.md: `make bench-compare-branch BRANCH=<branch>` — compare a branch against baseline.
  • AGENTS.md: `make bench-ingest BENCH=locomo` — ingest + snapshot (run once per embedding change).
  • AGENTS.md: `make bench-health` — recall health check (score distribution, entity quality, latency).
  • AGENTS.md: Run `make bench-eval BENCH=locomo-mini` on `main` to confirm the current baseline.
  • AGENTS.md: Run the same eval on the branch.
  • AGENTS.md: Promote to `make bench-eval BENCH=locomo` (full) before merge.
  • AGENTS.md: `benchmarks/snapshots/` — Qdrant/FalkorDB snapshot data (gitignored, regenerate with `make bench-ingest`).
  • AGENTS.md: `benchmarks/results/` — per-run result JSONs (gitignored).
  • AGENTS.md: release-please and GHCR `:stable` then run on `main`.
  • CLAUDE.md: `GET /consolidate/status` - Check consolidation scheduler status and last run times
  • CLAUDE.md: Adds short summaries, timestamps (`enriched_at`), and per-run metrics under `metadata.enrichment`.
  • CLAUDE.md: # Run tests
  • CLAUDE.md: make test-integration # Starts services and runs integration tests
  • CLAUDE.md: make test-live # Same as above via Makefile
  • CLAUDE.md: JIT_ENRICHMENT_ENABLED=true # Run entity/summary extraction inline on recall for unenriched memories
  • CLAUDE.md: Install spaCy locally to improve entity extraction:
  • CLAUDE.md: pip install spacy
  • CLAUDE.md: python -m spacy download en_core_web_sm
  • CLAUDE.md: **Local Development** - Make changes and test with `make dev`
  • CLAUDE.md: **Unit Tests** - Verify with `make test`
  • CLAUDE.md: **Integration Tests** - Validate with `make test-integration`
  • CLAUDE.md: **Deploy to Railway** - Push changes with `make deploy`
  • CLAUDE.md: **Live Validation** - Test deployed instance with `make test-live`
  • CLAUDE.md: **Benchmarking** - Validate performance with `make test-locomo-live`
  • CLAUDE.md: # Run integration tests against Railway

Install scripts (1)

  • Makefile (make install): echo "🔧 Setting up development environment..."; bash scripts/bootstrap_dev.sh; echo "✅ Virtual environment ready!"; echo "💡 Run 'source .venv/bin/activate' to activate"
  • Medium risk: runs-git-hook-remote-exec (.pre-commit-config.yaml:9)
  • Medium risk: runs-git-hook-remote-exec (.pre-commit-config.yaml:16)
  • Medium risk: runs-git-hook-remote-exec (.pre-commit-config.yaml:23)
  • Medium risk: runs-git-hook-remote-exec (.pre-commit-config.yaml:30)
  • Medium risk: runs-git-hook-remote-exec (.pre-commit-config.yaml:38)
  • Medium risk: runs-git-hook-remote-exec (.pre-commit-config.yaml:50)
  • Medium risk: runs-instruction-instruction-network (AGENTS.md:23)
  • Low risk: network-instructions (.pre-commit-config.yaml:2)
  • Low risk: network-instructions (CLAUDE.md:299)
  • Low risk: network-instructions (Makefile:91)
  • Low risk: scripts-present (scripts/bootstrap_dev.sh)

Attribution and licence

First committed by
GitHub avatar of jack-arturojack-arturo
Publisher
Very Good Plugins (Community)
Source
verygoodplugins/automem · commit 1a7ba1a
Licence
MIT License (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
jack-arturo, mikemikimike, zackkatz, dexhunter

AutoGineer is not affiliated with or endorsed by jack-arturo or Very Good Plugins.

Install from source

249 of its files are not served here, so there is no ZIP. verygoodplugins/automem at 1a7ba1a