Memento is a local-first AI agent memory and intelligence middleware providing persistent memory, goal enforcement, and autonomous cognitive capabilities via a SQLite-backed temporal graph — at zero cloud cost.
Core Memory Operations
Store and retrieve memories using hybrid FTS5 + vector embedding search with Reciprocal Rank Fusion (RRF)
Add, consolidate, share, and evaluate memories across sessions and workspaces
Automatically inject relevant memories before every tool call
Project & Goal Management
Set and track project goals with multi-level enforcement (context injection, LLM alignment checks, file-watcher daemon)
Manage project state (vision, milestones, blockers) with key-value storage
Get project summaries including active goals and recent activity
Session Lifecycle
Begin, resume, and hand off sessions with full working memory snapshots
Auto-checkpoint every 25 tool calls with session diff tracking
Generate LLM-agnostic handoff prompts for transferring context between agents
Knowledge Graph
Build a Project Memory Graph with typed entities (files, components, decisions, bugs, features) and relationships (depends_on, blocks, implements)
Run impact analysis to see what breaks when something changes
Extract knowledge graph entries from existing memories automatically
Query cross-workspace stats for federated setups
Cognitive & Autonomous Features
Dream synthesis: Generate creative insights from memory patterns
Goal alignment: Evaluate code/plans against active goals
Spider-sense warnings: Detect anomalies and risks proactively
Auto-generate tasks from memory and goal analysis
Background autonomous agent with passive, active, and autonomous modes for consolidation, KG extraction, and drift detection
Active Coercion (Code Immune System)
Apply preset rule packs or define custom deterministic regex/tree-sitter rules
Block anti-patterns at commit time via git hooks — no LLM involvement
Configuration & Diagnostics
Configure enforcement levels, daemon, autonomy, schedulers, and dependency tracking
Health diagnostics: system status, memory stats, KG health, search quality, cache performance, and relevance reports
Manage proactive notifications for goal drift and anomaly alerts
Workspace & Dependency Tools
Audit dependencies to find unused (orphan) or undeclared (ghost) packages
Migrate memories across workspaces with deterministic heuristics
Full workspace isolation: each project gets its own .memento/ SQLite database with no context bleeding
Federation: multiple workspaces can share a knowledge graph via Unix socket
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Memento remember the deadline for project is next Monday"
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.
Memento is a local-first, open-source MCP middleware that gives your AI agents (Cursor, Claude Desktop, Trae, etc.) persistent memory, proactive goal enforcement, and autonomous intelligence — all running on a zero-cost SQLite temporal graph with Reciprocal Rank Fusion (RRF) retrieval.
No cloud databases. No API calls for storage. Everything stays on your machine.
Built on SQLite FTS5 (full-text search) and cosine similarity (vector embeddings). Fuses keyword matches and semantic meaning via Reciprocal Rank Fusion. WAL-mode enabled for concurrency.
Keep your AI aligned with project objectives at three escalation levels:
Level 1 — Context Injection: Automatically injects active goals into every search result. Active by default.
Level 2 — Strict Mentor: Forces the AI to submit code/plans for goal alignment evaluation via LLM.
Level 3 — Daemon Push: File-watcher monitors your workspace and proactively flags goal drift.
Deterministic regex/tree-sitter rules that block anti-patterns at commit time and in the IDE. 100% deterministic — zero LLM hallucination risk during enforcement.
Background cognitive loop with four levels:
off: No background behavior (default).
passive: Observe health and patterns every 5 min. No modifications.
active: Consolidate memories, extract KG, warm caches, detect anomalies every 2 min.
autonomous: All of the above plus dream synthesis, goal drift detection, task generation, health reports every 1 min.
Each project gets its own .memento/ directory with an isolated SQLite database. No context bleeding between projects. Configure via MEMENTO_DIR or per-project .cursor/mcp.json.
Auto-checkpoints every 25 tool calls with full L1 working memory snapshot.
Auto-resume restores goals and context from the previous session.
LLM-agnostic handoff prompts for session transfer between agents.
Semantic entity-relationship graph on top of the Knowledge Graph. Track files, components, decisions, and their dependencies. Impact analysis shows what breaks when you change something.
Related MCP server: Memento
Memento exposes 14 action-based tools via MCP. Each tool uses an action parameter instead of separate tools per operation:
Tool | Actions | Purpose |
| (main router) | Primary proactive memory interface |
|
| Vision, milestones, blockers, goals |
|
| Session lifecycle and handoff |
|
| Project Memory Graph |
|
| FTS, vNext pipeline, routing trace |
|
| Memory write operations |
|
| All configuration |
|
| Cognitive engine operations |
|
| Diagnostics |
|
| Active Coercion management |
|
| Knowledge Graph operations |
|
| Proactive notifications |
| (standalone) | Dependency audit |
| (standalone) | Workspace memory migration |
pip install memento-mcpOr run without installing:
uvx memento-mcpAdd to your global mcp.json (e.g. ~/.cursor/mcp.json):
{
"mcpServers": {
"memento": {
"command": "memento-mcp",
"env": {
"OPENAI_API_KEY": "your-api-key",
"OPENAI_BASE_URL": "https://api.openai.com/v1",
"MEM0_MODEL": "openai/gpt-4o-mini"
}
}
}
}For per-project workspace isolation, add to .cursor/mcp.json in your project root:
{
"mcpServers": {
"memento": {
"command": "memento-mcp",
"env": {
"OPENAI_API_KEY": "your-api-key",
"OPENAI_BASE_URL": "https://api.openai.com/v1",
"MEM0_MODEL": "openai/gpt-4o-mini",
"MEMENTO_DIR": "${workspaceFolder}"
}
}
}
}Add .cursor/ to your .gitignore to avoid committing API keys.
memento-mcp --help
memento --helpSet MEMENTO_EMBEDDING_BACKEND=none to disable embeddings. Memento falls back to FTS5-only search — no API key needed.
MEMENTO_EMBEDDING_BACKEND=none memento-mcpVariable | Default | Description |
| — | Required for OpenAI embeddings and cognitive features |
|
| OpenAI-compatible endpoint (e.g. OpenRouter) |
|
| LLM model for cognitive features |
|
| Embeddings model |
| auto-detect |
|
| cwd | Workspace root for |
|
| Enable local web UI ( |
|
| Local UI port |
| — | Auth token for local web UI |
|
| Require confirmation before applying coercion rules |
|
| Inject relevant memories on every tool call ( |
|
| Number of memories to inject proactively |
|
| Decay λ for semantic memories (~200d half-life) |
|
| Decay λ for episodic memories (~50d half-life) |
|
| Decay λ for working memories (~14d half-life) |
|
| Write |
|
| Auto-checkpoint frequency |
| — | Path to a shared KG SQLite file (federation — multiple workspaces share one graph) |
| — | Unix socket path for push notifications between agents (replaces 30s WAL polling) |
Memento works from the terminal too:
# Auto-capture git context as a memory
memento capture --auto
# Save a free-form note
memento capture --text "Resolved auth timeout by increasing JWT expiry"
# Search memories
memento search "how did I fix the promise bug"
# Show workspace status
memento statusMemento operates at two levels:
Goal awareness: Every tool call is checked against active goals. If work drifts, a warning is appended.
Auto-resume: L1 working memory (goals, context) restores from the previous session's checkpoint.
Auto-checkpoint: Every 25 events, a full session snapshot is saved with project state and handoff prompt.
Session diff: Each checkpoint computes the delta from the previous session (goals changed, files touched).
memento_configure)L2 enforcement: Goal alignment checks via LLM on explicit request.
L3 daemon: File-watcher with proactive goal drift notifications.
Autonomous agent: Background consolidation, KG extraction, dream synthesis, task generation.
Active coercion: Deterministic code pattern enforcement.
Consolidation/KG schedulers: Background deduplication and knowledge extraction.
Example activation sequence:
memento_project(action="set_goals", goals=["Implement auth flow", "Refactor DB layer"])
memento_configure(action="enforcement", level="level2", enabled=true)
memento_configure(action="consolidation_scheduler", enabled=true, interval_minutes=30)
memento_configure(action="autonomy", level="active")Memento is released under the GNU Affero General Public License v3.0 (AGPL-3.0). If you modify Memento and offer it as a network service, you must release your modified source code under the same license.
See LICENSE for details.
Audit the workspace dependencies to find orphans (declared but unused) and ghosts (used but not declared).
| Name | Required | Description | Default |
|---|---|---|---|
| workspace_root | No | MANDATORY: The absolute path of the current project/workspace root. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It does not state whether the tool is read-only, modifies dependencies, or requires network access. The word 'audit' implies inspection, but this is implicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-front-loaded sentence that defines the tool's purpose and key terminology. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description should compensate with more context (e.g., return format, side effects, permissions). It falls short given the complexity of dependency auditing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. However, the description calls workspace_root 'MANDATORY' while the schema lists it as optional (no 'required' array), creating confusion. This inconsistency reduces clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool audits workspace dependencies and defines the two categories (orphans and ghosts). It distinguishes itself from siblings by focusing on dependency auditing, but does not explicitly differentiate from similar tools like memento_project or memento_graph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., memento_health, memento_search). No mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Active Coercion management. Actions: list_presets, apply_preset, list_rules, add_rule, remove_rule, install_hooks.
| Name | Required | Description | Default |
|---|---|---|---|
| rule | No | ||
| action | Yes | ||
| preset | No | ||
| rule_id | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses no behavioral traits such as side effects (e.g., destructive nature of remove_rule), authorization requirements, or state modifications beyond action names.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely short but fails to provide necessary details. It is under-specification rather than conciseness, lacking any meaningful structure or prioritization.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (5 parameters, nested objects, no output schema), the description is completely inadequate. It provides no information about return values, input constraints, or error handling.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not add any meaning to parameters like preset, rule_id, rule, workspace_root. The agent is left with no clue about their purpose or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description says 'Active Coercion management' which is vague and unclear in context. It lists actions but does not specify what coercion means or how it differs from sibling tools like memento_configure or memento_cognitive.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives. The description only lists action names without any context on preferred use cases or when to avoid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cognitive engine. Actions: dream (creative insight), align (goal check), warnings (spider-sense), tasks (auto-generate).
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes | ||
| content | No | Code/plan to evaluate (for align). | |
| context | No | Topic/context (for dream, warnings). | |
| active_context | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral transparency. It states actions and their intents (e.g., 'align (goal check)') but fails to explain side effects, state changes, or limitations. For example, 'warnings (spider-sense)' is ambiguous—does it check something? Does it modify state? The description lacks details on error conditions, idempotency, or required setup.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise—two lines, front-loaded with the core concept ('Cognitive engine') followed by a colon and a bullet-like list of actions. Each action gets a one-word hint. There is no extraneous text. While it could be slightly more structured (e.g., separate lines), it efficiently conveys the gist.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, 5 parameters with low schema coverage, and four distinct actions, the description is incomplete. It does not explain return values, error handling, or use cases. For example, 'tasks (auto-generate)' is vague—what tasks? Based on what? The lack of any output description or further context makes the tool under-specified for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 40% (2 of 5 parameters have descriptions). The description adds meaning to the 'action' enum by associating each value with a one-word explanation (e.g., 'dream (creative insight)'), supplementing the schema's pure enum list. However, the parameters 'active_context' and 'workspace_root' are completely undocumented in both schema and description. The description does not compensate for the missing schema descriptions elsewhere.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states it's a 'cognitive engine' and lists four actions with brief explanations (dream, align, warnings, tasks). Each action has a one-word hint (e.g., 'creative insight'). This clearly communicates the tool's purpose and distinguishes it from sibling tools that have different names like memento_search or memento_remember. However, it doesn't explain how these actions relate to each other or what the tool outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus its siblings (e.g., memento_search, memento_remember). There is no indication of prerequisites, context, or examples. The description only lists available actions without explaining the decision criteria for choosing one action over another or when this tool is preferred over alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Configure Memento. Actions: enforcement, coercion, daemon, autonomy, consolidation_scheduler, kg_scheduler, dependency_tracker, superpowers, access.
| Name | Required | Description | Default |
|---|---|---|---|
| level | No | ||
| state | No | ||
| tasks | No | ||
| action | Yes | ||
| enabled | No | ||
| warnings | No | ||
| workspace_root | No | ||
| interval_minutes | No | ||
| install_git_hooks | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description provides no behavioral details such as side effects, permissions required, or destructive potential. For a configuration tool, this is a critical omission.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely brief but at the cost of clarity. It front-loads the verb 'Configure' but the rest is a bare list of actions. This is under-specification, not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (9 parameters, many enums, no output schema, no annotations), the description is severely incomplete. It fails to explain what the tool does for each action or how parameters interact.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage and 9 parameters, the description only lists action enum values without explaining their meaning or the purpose of other parameters like 'level', 'state', or 'warnings'. It adds virtually no value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Configure Memento' and lists actions, giving a general sense of purpose. However, it lacks specifics on what each action configures, making it vague and not fully clear for distinguishing among sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like memento_coercion or memento_cognitive. The absence of usage context or when-not-to-use conditions hurts decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Copy-only migration: redistribute memories from a source DB into per-workspace DBs using deterministic text heuristics. Produces a JSON report.
| Name | Required | Description | Default |
|---|---|---|---|
| report_path | No | ||
| source_db_path | Yes | ||
| workspace_root | No | MANDATORY: The absolute path of the current project/workspace root. | |
| workspace_roots | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It states 'copy-only migration' indicating non-destructive behavior, but fails to explain side effects, idempotency, error handling, or safety considerations like whether the source DB is modified or if the tool can be re-run safely.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a single sentence and a result note. It front-loads the key action and output, avoiding unnecessary verbosity. However, it could benefit from structured sections for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a migration tool with no output schema and limited schema descriptions, the description omits important context such as the format of the JSON report, expected behavior under failure, required permissions, and the exact nature of the 'deterministic text heuristics'. This leaves significant gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only 25% of schema parameters have descriptions (workspace_root has a description but contradictory 'MANDATORY' vs not required in schema). The tool description does not compensate for the missing parameter explanations for source_db_path, workspace_roots, and report_path, leaving agents uncertain about input requirements.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it is a 'copy-only migration' tool that redistributes memories from a source DB into per-workspace DBs using deterministic text heuristics, which distinguishes it from other memento tools that handle queries or configurations. However, it could explicitly contrast with sibling tools like memento_remember or memento_search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It implies usage when migration is needed, but lacks conditions, prerequisites, or when not to use it. No mention of alternatives among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memories. Modes: basic (FTS), advanced (vNext pipeline), explain (routing trace).
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | basic | |
| limit | No | ||
| query | Yes | Search query. | |
| trace | No | ||
| filters | No | ||
| active_context | No | ||
| workspace_root | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose whether the tool is read-only, has side effects, or any safety information. It only explains search modes without behavioral details like performance or resource consumption.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise, using a single sentence to state purpose and list modes. It is front-loaded with the key verb and resource, but could be more structured and informative without adding verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 7 parameters (including nested objects) and no output schema, the description is insufficient. It does not cover return format, filter behavior, or the role of trace and active_context, leaving the agent with incomplete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 14% (query has description). The description adds meaning for the mode parameter by explaining the modes, but the other 6 parameters (limit, filters, trace, active_context, workspace_root) lack any additional description, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Search memories' as the primary function and distinguishes three modes (basic, advanced, explain), differentiating it from sibling tools like memento_remember (for creating memories) and memento_audit_dependencies.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description lists modes but does not provide explicit guidance on when to use this tool versus alternatives or when to choose each mode. Usage is implied by the name and hierarchy, but no exclusions or contextual cues are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.2.1mementomemento_graphmemento_healthmemento_kgmemento_notificationsmemento_projectmemento_remembermemento_sessionv0.3.1mementomemento_audit_dependenciesmemento_coercionmemento_cognitivememento_configurememento_graphmemento_healthmemento_kgmemento_migrate_workspace_memoriesmemento_notificationsmemento_projectmemento_remembermemento_searchmemento_sessionScored across 6 tools
Most tools expose distinct functional areas—search, migration, dependency audit, configuration, cognitive actions, and coercion—so an agent can typically tell them apart. However, memento_configure includes 'coercion' and 'dependency_tracker' actions that overlap with memento_coercion and memento_audit_dependencies.
All tools share the consistent memento_ prefix and snake_case style, but the suffixes mix verb phrases like audit_dependencies and migrate_workspace_memories with noun/module names like cognitive and coercion. This is readable but lacks a uniform verb_noun pattern.
Six tools is a well-scoped count for a server with this breadth of operational areas. Each tool represents a distinct functional domain, and the number is comfortably within the ideal range.
The server covers search, migration, audit, configuration, cognitive actions, and coercion management, but it lacks direct memory lifecycle operations such as create, update, or delete memories. For a memory-focused server, this is a notable gap even though the maintenance and control surface is fairly complete.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Persistent memory and knowledge graphs for AI agents. Hybrid search, context checkpoints, and more.
Persistent memory for AI agents. Semantic search, memory graph, W3C DID identity.
