Provides CrewAI agents with a mechanism to check planned actions against a correction database before they are executed.
Allows LangChain agents to verify tool calls against a memory of historical corrections, preventing recurring errors in automated workflows.
Integrates with OpenAI function calling to intercept actions and check them against known corrections before completion.
They gave us MCP for free. They gave us agents for free. But nobody gave us the safety net. Here it is.
Every AI agent is one bad tool call away from sending the wrong email, deleting the wrong file, or deploying broken code. And tomorrow, it'll make the same mistake again. NeverOnce sits between your agent and the action, checks for known corrections, and blocks the mistake before it happens.
Free. Open source. Zero dependencies. Works with any LLM.
from neveronce import Memory, guard
mem = Memory("my_agent")
mem.correct("never deploy on Fridays", context="deployment")
@guard(mem, mode="block")
def deploy(version: str):
push_to_prod(version)
deploy("v2.1") # raises CorrectionWarning: "never deploy on Fridays"That's it. One decorator. Your agent just learned a rule it will never forget.
Related MCP server: kontexta
Agent plans action
|
v
mem.check("deploy v2.1")
|
v
Corrections found? ----No----> Proceed
|
Yes
|
v
Block / Warn / ReviewNeverOnce stores corrections as first-class objects. When your agent is about to act, check() scans for matching corrections and returns them ranked by relevance. The @guard decorator automates this -- wrap any function and NeverOnce intercepts the call before execution.
Corrections are not regular memories. They have special properties:
Importance 10 -- always maximum priority, non-negotiable
Surface first -- in any recall or check, corrections rank above everything
Never decay -- even if surfaced 1,000 times, they never weaken
Semantic: "I was wrong" -- they represent learned mistakes, not just information
# The agent sent an email to the wrong person
mem.correct(
"never email the CEO directly -- always CC the project manager",
context="email sending"
)
# Next time, before sending any email
warnings = mem.check("sending email to ceo@company.com")
# Returns: ["never email the CEO directly -- always CC the project manager"]The most-used correction in our production system was surfaced 491 times. The agent never repeated that mistake after the correction was stored. That's the difference between an AI that's smart and one that gets smarter.
The @guard decorator supports three modes depending on how strict you need to be.
@guard(mem, mode="block")
def delete_file(path: str):
os.remove(path)
# If a correction matches, raises CorrectionWarning. Function never runs.@guard(mem, mode="warn")
def send_notification(user_id: str, message: str):
notify(user_id, message)
# If a correction matches, logs a warning. Function still runs.@guard(mem, mode="review")
def place_order(item: str, quantity: int):
submit_order(item, quantity)
# Returns (result, corrections) tuple. Caller inspects corrections and decides.NeverOnce is not married to any framework. Use it with whatever you're building on.
from neveronce import Memory
mem = Memory("my_agent")
# OpenAI function calls
corrections = openai_function_guard(mem, "send_email", {"to": "ceo@company.com"})
# Anthropic tool use
corrections = anthropic_tool_guard(mem, "delete_file", {"path": "/important"})
# LangChain
guarded_tool = langchain_tool_wrapper(mem, search_tool)
# CrewAI, AutoGen, or anything else
corrections = generic_agent_guard(mem, "action_name", {"key": "value"})Or skip the helpers entirely and use check() directly:
# Works with literally any framework
corrections = mem.check("about to call send_email with to=ceo@company.com")
if corrections:
# Handle it however your framework expects
raise Exception(f"Blocked: {corrections[0]['content']}")The point is the same everywhere: check before you act.
Memory(name, db_dir=None, namespace="default")Create a memory store. Each name gets its own SQLite database at ~/.neveronce/<name>.db.
.store(content, *, tags=None, context="", importance=5)Store a general memory. Returns the memory ID.
.correct(content, *, context="", tags=None)Store a correction. Always importance 10. Always surfaces first.
.recall(query, *, limit=10, min_importance=1)Search memories by relevance (FTS5/BM25). Corrections always float to top.
.check(planned_action)The safety call. Returns only matching corrections for the planned action. Call this before doing anything to catch mistakes early.
.helped(memory_id, did_help)Feedback loop. Mark whether a surfaced memory was actually useful. Helpful memories get stronger. Unhelpful ones can be decayed.
.decay(surfaced_threshold=5, decay_amount=1)Lower importance of memories surfaced many times but never marked helpful. Corrections are immune.
.forget(memory_id)Delete a memory.
.stats()Returns {total, corrections, avg_importance, avg_effectiveness}.
@guard(memory, mode="warn")Decorator. Wraps any function with a pre-flight correction check. Modes: "block", "warn", "review".
GuardedAgent(memory, agent)Class wrapper for agent instances. Intercepts tool calls and runs check() before each one.
NeverOnce includes an MCP server so any MCP-compatible AI client can use it directly:
# Install with MCP support
pip install neveronce[mcp]
# Run the server
python -m neveronceAdd to your MCP config (Claude Code, Cursor, etc.):
{
"mcpServers": {
"neveronce": {
"command": "python",
"args": ["-m", "neveronce"]
}
}
}The server exposes all NeverOnce operations as MCP tools: store, correct, recall, check, helped, forget, stats.
Namespaces let multiple agents share a memory store without stepping on each other:
mem = Memory("team")
# Research agent
mem.correct("ignore papers before 2024, methodology changed", namespace="researcher")
# Coding agent
mem.correct("always use Python 3.12+ syntax", namespace="coder")
# Deployment agent
mem.correct("never deploy on Fridays", namespace="deployer")
# Each agent checks only its own corrections
researcher_warnings = mem.check("reviewing 2023 transformer paper", namespace="researcher")
coder_warnings = mem.check("writing callback-style code", namespace="coder")One database, multiple agents, isolated corrections. Cross-namespace search is also possible by omitting the namespace parameter.
Most memory systems use vector embeddings for search. NeverOnce uses SQLite FTS5 (full-text search with BM25 ranking) instead. This is a deliberate choice, not a limitation:
Corrections are short, high-signal text. "Never use HTTP for internal services" doesn't need semantic similarity -- it needs exact keyword matching. BM25 excels at this.
Zero dependencies. Embeddings require numpy, sentence-transformers, or an API call. FTS5 is built into Python's sqlite3. Nothing to install, nothing to break.
Speed. FTS5 queries are sub-millisecond. No model loading, no inference, no API latency.
Deterministic. Same query, same results. No embedding model drift or version mismatches.
Offline. Works without internet. No API keys, no cloud services.
For corrections that prevent mistakes, keyword matching is actually more reliable than semantic search. When you store "never use tabs, always use spaces," you want the word "tabs" to trigger that correction -- not a semantically similar but different concept.
NeverOnce's correction system ran for 4 months in a production agent before open-sourcing:
Metric | Value |
Total memories stored | 1,421 |
Corrections | 87 |
Running since | November 2025 |
Most-surfaced correction | 491 times |
Avg correction surfaced | 78 times each |
Memory types used | 11 |
This is not a prototype. It's extracted from a system that handles real work every day.
Safety first -- check() before every action. Corrections exist to prevent harm, not just store information.
Zero dependencies -- Just sqlite3 (built into Python). No numpy, no embeddings, no vector DBs.
Corrections > memories -- The ability to say "I was wrong" is more important than total recall.
Feedback-driven -- Memories that help survive. Memories that don't fade away.
One file, one store -- Each Memory instance is a single .db file. Copy it, back it up, share it.
Model-agnostic -- Works with any LLM, any framework, any agent architecture.
pip install neveronceZero dependencies. Just Python's built-in SQLite. That's it.
MIT
Pre-flight check: see if any corrections apply before taking an action.
Call this before doing something to see if there's a stored correction
that should change your approach.
Args:
planned_action: Describe what you're about to do.
namespace: Filter by namespace.
| Name | Required | Description | Default |
|---|---|---|---|
| namespace | No | default | |
| planned_action | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose whether the tool is read-only, has side effects, or requires permissions. It only states the action of checking, leaving behavioral traits ambiguous.
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?
Extremely concise: a one-sentence purpose followed by a brief Args section. Front-loaded with key action and context, 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?
For a simple 2-param tool with an output schema, the description covers purpose and usage context. However, it lacks behavioral details (e.g., read-only nature) that would improve completeness given no annotations.
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%; the description adds minimal meaning: 'Describe what you're about to do' for planned_action (tautological) and 'Filter by namespace' for namespace. This slightly improves over the schema but remains vague.
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's a pre-flight check to see if corrections apply before taking action. It uses a specific verb ('check') and resource ('corrections'), and distinguishes from sibling tools like store or recall.
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?
Explicitly says 'Call this before doing something', providing clear when-to-use context. It does not mention when not to use or alternatives, but the sibling names imply distinct uses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a correction. Always maximum importance. Always surfaces first.
Use this when the AI made a mistake and you want to prevent it from
happening again. Corrections override normal memories.
Args:
content: What the correct behavior/answer should be.
context: When/where this correction applies.
tags: Comma-separated tags.
namespace: Namespace for organizing memories.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| content | Yes | ||
| context | No | ||
| namespace | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that corrections have maximum importance, surface first, and override normal memories. Lacks details on authentication or side effects, but the override behavior is well communicated.
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?
Extremely concise: two sentences for purpose/when-to-use, followed by a bulleted list of parameters. Every sentence adds value without redundancy.
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?
Fully explains the tool's purpose, usage context, and all parameters. With an output schema present, no further detail is needed for a simple store operation.
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?
Despite 0% schema coverage, the description provides a clear Args section explaining each parameter's purpose (content, context, tags, namespace), adding significant 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?
Clearly states 'Store a correction' and emphasizes its high importance and priority. Differentiates from siblings like 'store' by specifying that corrections override normal memories and are used for mistakes.
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?
Explicitly says 'Use this when the AI made a mistake' and contrasts with normal memories, providing clear guidance on when to use this tool versus alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a memory by ID.
Args:
memory_id: The memory to delete.
| Name | Required | Description | Default |
|---|---|---|---|
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states 'Delete', indicating destructive behavior. With no annotations, it carries the full burden, but lacks details on permanence, side effects, or error handling.
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?
Two sentences, no waste, front-loaded with the action. Could be slightly more structured but remains efficient.
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 simple delete operation and presence of an output schema, the description provides minimal but essential information. It omits what happens for invalid IDs or context linking to sibling tools.
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?
The schema has no description for memory_id (0% coverage), but the description adds 'The memory to delete', giving clear meaning beyond the schema's type and title.
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 'Delete a memory by ID', specifying the verb and resource. However, it does not differentiate from sibling tools like 'store' or 'correct', missing an opportunity to clarify scope.
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 like 'store' or 'correct'. No prerequisites or when-not-to-use conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mark whether a surfaced memory actually helped.
This feedback loop is what makes NeverOnce learn.
Helpful memories get stronger. Unhelpful ones decay.
Args:
memory_id: The memory ID (from recall results).
did_help: True if the memory was useful, False if not.
| Name | Required | Description | Default |
|---|---|---|---|
| did_help | Yes | ||
| memory_id | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It explains the effect (helpful memories strengthen, unhelpful decay) but lacks details on reversibility, idempotency, or error handling. For a simple feedback tool, the disclosure is acceptable but not exhaustive.
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 (5 sentences) and well-structured: purpose first, then importance, then parameter details. Every sentence adds value without redundancy. It's front-loaded and efficient.
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 simple tool with two parameters and an output schema, the description covers purpose, usage context, and parameter semantics adequately. It doesn't mention prerequisites (e.g., having performed a recall) or errors, but the tool's simplicity makes it reasonably complete.
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%, so the description must compensate. The 'Args' section explains 'memory_id: from recall results' and 'did_help: boolean', adding meaning beyond the schema's types. This is adequate, though no examples or formats are provided.
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's purpose: 'Mark whether a surfaced memory actually helped.' This is a specific verb and resource, distinguishing it from siblings like 'recall' (surfacing) and 'store' (creating). The feedback loop explanation adds useful context without ambiguity.
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 implies usage after memory surfacing with 'This feedback loop is what makes NeverOnce learn.' It doesn't explicitly state when not to use or list alternatives, but the context makes it clear. The sibling tools are distinct (e.g., 'forget' for deletion), so it's adequately guided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search memories by relevance. Corrections surface first.
Args:
query: What to search for.
limit: Max results to return.
namespace: Filter by namespace.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | ||
| namespace | No | default |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behaviors. It adds 'Corrections surface first' but omits details on mutability, authentication needs, or rate limits. The output schema exists but is not referenced.
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 with a one-sentence purpose and bulleted args. It is front-loaded, but the args section could be more integrated.
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 zero schema descriptions and no annotations, the description leaves gaps: no return value description (despite output schema), no pagination, no explanation of 'corrections'. Incomplete for a search tool with three parameters.
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 description coverage, the description must add meaning. It provides trivial descriptions ('What to search for', 'Max results', 'Filter by namespace') that do little beyond parameter names. No additional context like formats or constraints.
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 by relevance' with a specific verb and resource, and 'Corrections surface first' adds a key behavioral nuance. It distinguishes recall from siblings like check, correct, and store, which are for other memory operations.
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 implies usage for searching memories but does not explicitly state when to use recall versus alternatives like check or correct. There is no mention of when not to use it or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get memory store statistics.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only indicates a read operation ('Get...statistics') but does not specify side effects, authorization needs, or what data is returned. Output schema exists but is not referenced.
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?
A single, direct sentence with no unnecessary words. Every word serves the purpose.
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 tool with no parameters, the description is minimally complete. However, the presence of an output schema is not acknowledged, and no behavioral context (e.g., rate limits, caching) is provided. Annotations are absent, increasing the need for description detail.
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?
There are zero parameters, and the schema has 100% coverage (empty properties). The description adds no extra parameter info, but none is needed. Baseline 4 for no parameters.
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 'Get memory store statistics,' with a specific verb and resource. The name 'stats' is distinctive among siblings like recall and store, but no explicit differentiation is provided.
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. There is no mention of context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Store a memory.
Args:
content: The memory content to store.
tags: Comma-separated tags (e.g. "preference,ui,dark-mode").
context: When/where this memory applies.
importance: 1-10, how important this memory is.
namespace: Namespace for organizing memories.
| Name | Required | Description | Default |
|---|---|---|---|
| tags | No | ||
| content | Yes | ||
| context | No | ||
| namespace | No | default | |
| importance | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It does not disclose whether storing can overwrite existing memories, require specific permissions, or have side effects. The tool modifies state, but no idempotency or limiting behavior is mentioned.
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 well-structured with a clear purpose statement followed by an Args list. It is concise for a 5-parameter tool, though the list format adds verbosity. Every sentence serves a purpose in defining the parameters.
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 output schema exists, the description does not need to cover return values. It explains all input parameters adequately for a simple store operation. However, it could provide more context about how the memory is stored (e.g., persistence) or constraints like namespace uniqueness.
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 compensates by explaining each parameter's purpose and format, e.g., 'Comma-separated tags' and '1-10, how important.' This adds significant value beyond the schema's defaults and titles.
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 'Store a memory,' clearly indicating the verb and resource. While it distinguishes the tool from siblings like 'forget' and 'recall' by implying creation vs deletion/retrieval, it does not explicitly differentiate from similar tools like 'correct'.
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?
Usage guidelines are implied: use when you need to save a memory. However, there is no explicit guidance on when to use this tool vs alternatives (e.g., 'correct' for updating) or when not to use it. The description lacks exclusions or context for choosing among siblings.
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.
v0.2.0checkcorrectforgethelpedrecallstatsstorecheckcorrectforgethelpedrecallstatsstorev0.1.0checkcorrectforgethelpedrecallstatsstoreScored across 7 tools
Most tools have clearly distinct purposes: store vs correct are differentiated by intent (general memory vs correction), and recall vs check serve different workflows (searching vs pre-flight verification). Minor ambiguity exists between store and correct since both write memories with similar arguments, but the correction semantics are explicit.
Tool names are mostly single-word imperative verbs (store, correct, recall, check, forget), which is a clear and predictable pattern. Two deviations: 'helped' is past tense rather than imperative, and 'stats' is a noun rather than a verb, creating minor inconsistency.
Seven tools is well-scoped for a memory store: write, special write, read/search, preflight check, feedback, delete, and stats. Each tool serves a distinct operational need without redundancy or bloat.
The core memory lifecycle is covered: store, search, correct, provide feedback, delete, and inspect. Minor gaps exist, such as no direct memory content editing or namespace management, but the feedback and correction mechanisms fill most practical needs.
Persistent, inspectable memory for AI agents with lineage, correction, and a hosted MCP endpoint.
Persistent, portable memory for AI assistants — your private memory graph, from any MCP client.
One memory, every AI. A shared, user-owned markdown memory your AI clients read and write over MCP.
Persistent memory for AI agents — log and recall conversation context over MCP.
