Which integrations are available for this server?

Supports using Google Gemini models for fact extraction, conflict reconciliation, and embedding generation in the memory pipeline. Supports running fully offline local models via Ollama for fact extraction, reconciliation, and embedding generation. Supports using OpenAI models as the LLM provider for extracting atomic facts, reconciling memory conflicts, and generating embeddings.

How do I use agent-memory?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@agent-memory Remember that I moved to San Francisco and now work at Stripe." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

agent-memory

by satvik-sahore

Overview Schema Source Related Servers Discussions Admin

Python

Hybrid

🧠 Self-Learning AI Agent: Long-Term Memory Engine

Python FastAPI Qdrant MCP License

A production-grade Long-Term Memory Microservice & Model Context Protocol (MCP) Server for AI Agents. Enables continuous, cross-session learning by dynamically extracting atomic user facts, resolving state conflicts (ADD, UPDATE, DELETE, NOOP), and persisting vectors in Qdrant.

🌟 Why This Architecture?

Traditional RAG and naive chat-history appending have critical flaws:

Context Window Bloat: Appending full raw transcripts increases latency, token costs, and attention drift.
Contradictions & Stale State: If a user says "I live in San Francisco" and 3 months later says "I moved to Tokyo", naive RAG retrieves both chunks, causing hallucinations.
My Solution: A Two-Phase Memory Pipeline where an LLM parses atomic facts and performs explicit state mutations (ADD, UPDATE, DELETE, NOOP) directly on the vector store.

Related MCP server: AGI MCP Server

🏗️ System Architecture

flowchart TD
    subgraph Ingestion ["1. Client Interfaces & Ingestion"]
        A["💬 User / Agent Chat"] --> C["⚡ FastAPI REST API (/v1/chat)"]
        B["🤖 Claude Desktop / Cursor IDE"] --> D["🔌 MCP 2.x Server (stdio)"]
        C --> E["📥 Async Ingestion Queue (asyncio.Queue)"]
        D --> E
    end

    subgraph TwoPhase ["2. Two-Phase Agentic State Machine"]
        E --> F["🧠 Phase 1: Fact Extractor (LLM)"]
        F -->|Atomic Facts & Triples| G["📋 Candidate Facts"]
        
        G --> H["🔍 Semantic Search Candidates"]
        Q1[("💾 Qdrant Vector Store (Current State)")] -.->|Existing User Memories| H
        
        H --> I["⚖️ Phase 2: Conflict Reconciler (LLM)"]
        G --> I
        
        I -->|State Mutation Decision| J{"Operation"}
        J -->|ADD| K["✨ Insert New Vector Point"]
        J -->|UPDATE| L["🔄 Overwrite Stale Vector & Payload"]
        J -->|DELETE| M["🗑️ Delete Vector Point"]
        J -->|NOOP| N["⏸️ Ignore Redundant Duplicate"]
    end

    subgraph Storage ["3. Storage & Knowledge Graph Layer"]
        K --> Q2[("💾 Qdrant Vector DB (Synchronized State)")]
        L --> Q2
        M --> Q2
        Q2 --> O["⏳ Ebbinghaus Temporal Decay & Spaced Reinforcement"]
        Q2 --> P["🕸️ GraphRAG Topological Entity Visualizer"]
    end

✨ Key Features

🧠 Dynamic Two-Phase Lifecycle:
1. Extraction: Extracts durable, self-contained third-person facts while discarding conversational noise.
2. Reconciliation: Semantic lookup finds candidate conflicts; LLM decides ADD, UPDATE, DELETE, or NOOP.
🕸️ Interactive GraphRAG Knowledge Visualizer:
- Live topological node-link graph visualizer built on HTML5 Canvas force physics.
- Automatically extracts Entity-Relation Triples (Subject -> Relation -> Object) for multi-hop associative retrieval.
⚡ Sub-150ms Asynchronous Ingestion Queue:
- Event-driven background queue (asyncio.Queue) offloads fact extraction and vector synchronization, enabling instant conversational replies.
🗂️ Multi-Tier Scoped Memory:
- Hierarchical isolation across user (persistent), session (ephemeral/task-level), and workspace (shared team conventions).
⏳ Cognitive Temporal Decay (Ebbinghaus Forgetting Curve):
- Mathematical recency weighting: $\text{Score} = (1 - w) \cdot \text{Similarity} + w \cdot e^{-\lambda \Delta t}$.
- Spaced reinforcement: Automatically touches and refreshes retention every time a memory is recalled.
📊 Interactive Visual Memory Explorer & AI Chat Playground:
- Full-featured dark-mode web dashboard (/dashboard) with live chat playground, real-time memory bank feed, and similarity confidence meters.
🔌 Dual Serving Interfaces:
- FastAPI REST Endpoints: High-performance HTTP service with OpenAPI docs (/docs).
- Model Context Protocol (MCP 2.x): Plug-and-play tools (remember_conversation, recall_memories, forget_memory) for Claude Desktop, Cursor, and agentic workflows.
💾 Hybrid Qdrant Support: Runs via Docker or automatic embedded local disk mode (./qdrant_data) with zero cloud cost.
🌐 Multi-Provider Support: Seamlessly swappable across Google Gemini (gemini-3.5-flash-lite), OpenAI (gpt-4o-mini), or 100% offline local models via Ollama.
🛡️ Production Hardened: Adaptive exponential backoff retry handler parsing upstream rate-limit windows (429/503).

📁 Repository Structure

├── src/
│   ├── api/                 # FastAPI REST API routes & controllers
│   │   ├── __init__.py
│   │   └── routes.py        # /v1/memories/process, /search, /user, /delete
│   ├── db/                  # Vector database layer
│   │   ├── __init__.py
│   │   └── qdrant.py        # Qdrant client manager & schema initializers
│   ├── llm/                 # Unified LLM provider client (Gemini / OpenAI)
│   │   ├── __init__.py
│   │   └── client.py        # Structured JSON generation & embedding generation
│   ├── memory/              # Two-Phase Memory Pipeline Core
│   │   ├── __init__.py
│   │   ├── models.py        # Pydantic schemas (Fact, Operation, MemoryRecord)
│   │   ├── extractor.py     # Phase 1: Atomic fact extractor
│   │   ├── reconciler.py    # Phase 2: Conflict reconciler
│   │   └── service.py       # High-level memory orchestrator
│   ├── mcp_server/          # Model Context Protocol (MCP 2.x) integration
│   │   ├── __init__.py
│   │   └── server.py        # Standardized MCP server & tools
│   ├── config.py            # Pydantic Settings management
│   └── main.py              # FastAPI ASGI entrypoint & lifecycle
├── scripts/
│   ├── verify_setup.py      # Setup & database connectivity verifier
│   └── demo_pipeline.py     # Interactive visual lifecycle demo
├── tests/
│   ├── test_phase1.py       # Infrastructure & DB tests
│   ├── test_phase2.py       # Two-phase pipeline & lifecycle tests
│   ├── test_phase3_api.py   # FastAPI REST endpoint tests
│   └── test_phase3_mcp.py   # MCP tools test suite
├── docker-compose.yml       # Multi-container orchestration (API + Qdrant)
├── Dockerfile               # Multi-stage production container build
├── requirements.txt         # Project dependencies
└── pytest.ini               # Pytest configuration

🚀 Quickstart Guide

1. Clone & Setup Environment

# Clone the repository
git clone https://github.com/your-username/self-learning-ai-agent.git
cd self-learning-ai-agent

# Create and activate virtual environment
python3 -m venv .venv
source .venv/bin/activate

# Install dependencies
pip install -r requirements.txt

2. Configure Environment Variables

cp .env.example .env

Edit .env with your API key and preferred models:

# Google Gemini (Free Tier / Zero Cloud Cost)
OPENAI_API_KEY=AIzaSy...
PROVIDER=gemini
EMBEDDING_MODEL=gemini-embedding-2
EMBEDDING_DIMENSION=3072
EXTRACTION_MODEL=gemini-3.5-flash-lite
RECONCILIATION_MODEL=gemini-3.5-flash-lite

# Vector DB Settings (Automatically falls back to local disk if Docker is off)
QDRANT_HOST=localhost
QDRANT_PORT=6333
SIMILARITY_THRESHOLD=0.60

3. Verify Setup & Run Interactive Demo

# Verify vector DB connectivity
python scripts/verify_setup.py

# Run visual multi-turn memory evolution demo
python scripts/demo_pipeline.py

4. Run Automated Test Suite

pytest -v

🌐 Running the Services

Option A: Local FastAPI Server

uvicorn src.main:app --host 0.0.0.0 --port 8000 --reload

Interactive Swagger API documentation: http://localhost:8000/docs

Option B: Full Stack Docker Compose

docker compose up --build -d

Option C: Launch MCP Server (stdio)

python -m src.mcp_server.server

🔌 Model Context Protocol (MCP) Integration

Connect this memory engine directly to Claude Desktop, Cursor IDE, or Antigravity.

Add to your claude_desktop_config.json (or Cursor MCP settings):

{
  "mcpServers": {
    "agent-memory": {
      "command": "/path/to/self-learning-ai-agent/.venv/bin/python",
      "args": ["-m", "src.mcp_server.server"],
      "cwd": "/path/to/self-learning-ai-agent"
    }
  }
}

Exposed MCP Tools:

remember_conversation(user_id, conversation_text): Extracts facts and reconciles them into memory.
recall_memories(user_id, query, limit): Retrieves semantically relevant facts with similarity scores.
list_user_memories(user_id, limit): Lists all active facts for the user.
forget_memory(memory_id): Manually removes a memory point.

📡 REST API Reference

1. Ingest Conversation & Update Memory State

POST /v1/memories/process

curl -X POST http://localhost:8000/v1/memories/process \
  -H "Content-Type: application/json" \
  -d '{
    "user_id": "alex_01",
    "conversation": "I am a Senior AI engineer based in San Francisco. I switched my primary language from Python to Rust."
  }'

2. Semantic Memory Search

GET /v1/memories/search?user_id=alex_01&query=What+languages+does+the+user+code+in%3F

curl "http://localhost:8000/v1/memories/search?user_id=alex_01&query=What+languages+does+the+user+code+in%3F&limit=3"

3. List All User Memories

GET /v1/memories/user/{user_id}

curl http://localhost:8000/v1/memories/user/alex_01

4. Delete Memory by ID

DELETE /v1/memories/{memory_id}

curl -X DELETE http://localhost:8000/v1/memories/c7b2049e-648b-4b10-a24e-b5f7cf839a82

💼 Resume & Technical Impact Highlights

If you include this project in your portfolio or resume, here are production-oriented bullet points:

Engineered a self-learning long-term memory microservice in Python (FastAPI) utilizing Qdrant vector search to provide AI agents with persistent, cross-session user context.
Implemented a dynamic Two-Phase Memory Pipeline that prompts an LLM to extract atomic facts and programmatically execute state mutations (ADD, UPDATE, DELETE, NOOP), eliminating stale fact contradictions and optimizing LLM token utilization.
Packaged the memory layer into a Model Context Protocol (MCP 2.x) Server, enabling native, zero-latency tool-use integration across IDEs and AI client agents (Cursor, Claude Desktop).
Architected a modular provider layer supporting Gemini, OpenAI, and local Ollama, featuring automated schema validation and adaptive rate-limit backoff retry handlers.
Containerized the full stack with multi-stage Docker builds and automated test suites achieving 100% test pass rates across unit and end-to-end integration flows.

📄 License

MIT License. Free for open-source and commercial use.

Available Tools

4 tools

forget_memoryA

Deletes a specific memory record by its unique ID.

Args: memory_id: The UUID of the memory record to remove.

ParametersJSON Schema

Name	Required	Description	Default
`memory_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It correctly discloses the destructive core behavior ('Deletes') and the target record, but it does not mention irreversibility, ownership/permission requirements, or behavior when the memory_id does not exist.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one direct, front-loaded sentence followed by a useful structured Args line. There is no filler, and the Args line earns its place because the schema lacks parameter descriptions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple single-parameter destructive tool with an output schema, the description provides enough to know what action to take and which ID to supply. Additional details about permanence or error behavior would help but are not required for a correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema only provides the parameter type and title, so the description's Args block adds real meaning by specifying that memory_id is 'The UUID of the memory record to remove'. This fully compensates for the 0% schema description coverage in a concise way.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the exact verb 'Deletes', the resource 'memory record', and the selection mechanism 'unique ID'. This clearly distinguishes it from the sibling list/remember/recall tools even though they are not mentioned.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool: when a specific memory record should be removed and its ID is known. However, it does not explicitly state when not to use it or point to alternatives such as recall_memories or list_user_memories.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_user_memoriesA

Lists all active stored memories for a user.

Args: user_id: The unique identifier for the user. limit: Maximum number of memories to return (default: 50).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`user_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and adequately does so by using 'Lists' to imply a read-only operation, specifying the 'active' filter, and documenting the default limit. It does not cover ordering or pagination, but these are minor for a simple list tool with an output schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is front-loaded with the purpose sentence and followed by a compact argument list. There is no filler or redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple two-parameter list operation with an output schema, the description is essentially complete: it defines the scope, the parameters, and the default limit. It would benefit from a brief pointer to recall_memories for search-style retrieval, but that omission is already captured in usage guidelines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the Args section fully compensates by explaining user_id as the unique identifier and limit as the maximum number of memories to return with its default value. This adds real meaning beyond the bare schema titles.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Lists all active stored memories for a user.' It is not a tautology, and it adds scoping ('active', 'for a user'), but it does not explicitly differentiate itself from the sibling recall_memories tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is given about when to use this tool versus recall_memories, forget_memory, or remember_conversation. The description simply states what it does; an agent must infer when it is the right choice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

recall_memoriesA

Retrieves semantically relevant memories from vector storage given a natural language query.

Args: user_id: The unique identifier for the user. query: The topic, question, or context to retrieve facts for. limit: Maximum number of memory records to return (default: 5).

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`query`	Yes
`user_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It explicitly says 'Retrieves' and names the source as vector storage, signaling a non-mutating read operation and semantic-relevance selection. It does not cover edge cases like permissions or errors, but for a read tool the core behavior is disclosed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, front-loaded purpose sentence followed by a compact Args block. Every sentence contributes useful information, and there is no redundant or filler content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity, the description is complete enough for correct invocation: all parameters are explained, default behavior is specified, and an output schema exists so return-value documentation is unnecessary. The missing alternative guidance is already accounted for in usage guidelines.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 0% description coverage, and the description fully compensates with meaningful definitions for all three parameters: user_id, query, and limit. It adds clarity about the query as a topic/question/context and the default limit of 5, which the schema alone does not provide.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific operation: retrieving semantically relevant memories from vector storage given a natural language query. This clearly differentiates it from siblings like list_user_memories, which implies listing rather than semantic search.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool—when semantic recall from a natural language query is needed—but it does not explicitly distinguish this from list_user_memories or other alternatives. An agent must infer the usage boundary from wording and sibling names.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remember_conversationA

Extracts durable facts from conversation text and reconciles them into long-term memory (ADD, UPDATE, DELETE, NOOP).

Args: user_id: The unique identifier for the user. conversation_text: The conversation transcript or user statement to remember.

ParametersJSON Schema

Name	Required	Description	Default
`user_id`	Yes
`conversation_text`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the behavioral burden. It discloses the core side effect: reconciling extracted facts into long-term memory and possibly performing ADD, UPDATE, DELETE, or NOOP. However, it does not explain under what conditions each operation occurs, whether changes are reversible, or what response the caller can expect.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the primary action and operation modes. The Args block is spare and each line adds meaning beyond the schema, which only provides titles. There is no filler or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has only two required string parameters and an output schema, so the description does not need to explain return values. It covers the tool's purpose, its side-effectful operation types, and both arguments. The main gap is the lack of criteria for choosing this tool over sibling memory tools, but overall it is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the Args text is the only documentation for both parameters. The description adds real meaning: 'user_id' is the user's unique identifier, and 'conversation_text' is the transcript or statement to remember. For two simple string parameters, this is sufficient compensation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: it 'Extracts durable facts from conversation text and reconciles them into long-term memory.' The parenthetical operation list (ADD, UPDATE, DELETE, NOOP) clarifies the tool's scope. It does not explicitly name sibling tools, but its write-oriented behavior distinguishes it from list/recall/forget siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool should be used when conversation text should be persisted to long-term memory, but it gives no explicit when-to-use guidance, no exclusions, and no mention of alternatives like recall_memories or forget_memory. The agent must infer the boundary between this and sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Sep 8, 2026
- First observedforget_memory
- First observedlist_user_memories
- First observedrecall_memories
- First observedremember_conversation

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4/5.0

Scored 2026-09-08 19:00 across 4 tools

Disambiguation4/5

Each tool has a distinct core action: list, recall, remember, and forget. The only potential confusion is between list_user_memories and recall_memories, but the descriptions clearly separate 'all active memories' from 'semantically relevant' retrieval.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern: list_user_memories, forget_memory, remember_conversation, recall_memories. The verbs are meaningful and align with their actions.

Tool Count5/5

Four tools is a well-scoped size for a memory server, covering ingestion, retrieval, listing, and deletion. Each tool maps to a clear capability without redundant or excessive surface area.

Completeness4/5

The set covers the core memory lifecycle: adding memories, recalling them, listing them, and deleting them. A direct get-by-ID or explicit update tool is missing, but remember_conversation's reconciliation covers updates through its ADD/UPDATE/DELETE/NOOP behavior.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

MemorySync AOAuth
io.memorysync
Persistent memory for AI agents. Search and store durable facts, preferences and decisions.
Autonomous Agents Developer Tools Knowledge & Memory
151
agentbay-mcp AOAuth
io.github.thomasjumper
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
Knowledge & Memory Autonomous Agents Agent Orchestration
21
AI Context FlowOAuth
network.plurality
Universal memory for AI agents and tools. Save, organize and search context anywhere.
Knowledge & Memory Search
22
Penfield Memory AOAuth
io.github.penfieldlabs
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Knowledge & Memory RAG Systems Vector Databases
1726

Related MCP Servers

BuildAutomata Memory MCP
Knowledge & Memory RAG Systems Vector Databases
brucepro
F
license
Not graded
quality
D
maintenance
Provides AI agents with persistent, searchable memory that survives across conversations using semantic search, temporal versioning, and smart organization. Enables long-term context retention and cross-session continuity for AI assistants.
Updated 9 months ago (2025-12-27 04:00 UTC)
14
-
AGI MCP Server
Knowledge & Memory Vector Databases RAG Systems
randyandrade
F
license
B
quality
D
maintenance
Enables persistent memory for AI systems by providing tools for episodic, semantic, and procedural data storage through a vector-and-graph-enhanced database. It allows models to maintain long-term continuity using similarity search, thematic clustering, and identity tracking.
Updated a year ago (2025-06-29 02:45 UTC)
24
1
-
Memsolus MCP Serverofficial
Knowledge & Memory RAG Systems Autonomous Agents
memsolus
A
license
A
quality
D
maintenance
Provides persistent long-term memory for AI agents through semantic search and automated knowledge graph extraction. It enables agents to store, recall, and reason over facts, preferences, and relationships across multiple conversations and sessions.
Updated 3 months ago (2026-06-06 18:33 UTC)
14
14 npm
MIT
Recall
Knowledge & Memory AI & Machine Learning
joseairosa
A
license
Not graded
quality
C
maintenance
Provides persistent, cross-session memory for AI agents, allowing them to store and automatically retrieve information across different conversations and sessions without repeating context.
Updated 20 days ago (2026-08-30 14:06 UTC)
9 npm
175
MIT

🧠 Self-Learning AI Agent: Long-Term Memory Engine

🌟 Why This Architecture?

🏗️ System Architecture

✨ Key Features

📁 Repository Structure

🚀 Quickstart Guide

1. Clone & Setup Environment

2. Configure Environment Variables

3. Verify Setup & Run Interactive Demo

4. Run Automated Test Suite

🌐 Running the Services

Option A: Local FastAPI Server

Option B: Full Stack Docker Compose

Option C: Launch MCP Server (stdio)

🔌 Model Context Protocol (MCP) Integration

Exposed MCP Tools:

📡 REST API Reference

1. Ingest Conversation & Update Memory State

2. Semantic Memory Search

3. List All User Memories

4. Delete Memory by ID

💼 Resume & Technical Impact Highlights

📄 License

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Memsolus MCP Serverofficial