The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the MemAuthority listing page.
MemAuthority is a Git-backed long-term memory system for AI agents, exposed through MCP (Model Context Protocol). It lets a new session, another machine, or another agent recover the project's accumulated context and continue working instead of rediscovering the same decisions and pitfalls.
Rather than attempting to record every single detail, it focuses on distilling:
Lessons and conclusions that future agents should never have to rediscover from scratch.
A clear division of responsibility:
The agent still decides what the content means and whether it should change. MemAuthority makes sure the memory that remains is reliable over time.
MemAuthority is designed for users who prioritize the quality of long-term memory.
You may have experienced the lack of control with built-in platform memories:
Or perhaps you have tried maintaining a MEMORY.md file, only to watch it grow bloated and messy over time — eventually confusing the agent rather than helping it.
MemAuthority is a good fit when:
Want to invest minimal effort curating memory quality, while delegating all routine organization to the agent.
"Investing effort" does not mean manually editing files all day. It means making high-leverage decisions at key moments:
All mechanical heavy lifting — formatting, categorizing, archiving, and targeted retrieval — is handled entirely by the agent.
MEMORY.md?If your project's memory is small, rarely changes, or you simply do not want to spend any attention on memory maintenance, sticking with a plain MEMORY.md is the easiest choice.
Once that file stops being just a note and becomes long-term project state that future sessions need to trust, MemAuthority starts to become useful.
It addresses a higher-order need:
Turning long-term memory maintenance into a reliable, controllable, and engineered workflow.
It provides far more than just "letting an agent edit Markdown." It delivers a robust operational architecture:
A useful way to think about it is:
Authority stores the state a future agent should inherit now; Git stores the full history.
In short:
MEMORY.mdoptimizes for simplicity; MemAuthority optimizes for keeping long-term memory reliable as the project grows.
In an ideal workflow, MemAuthority stays quietly behind the scenes. You interact with the agent using natural, concise instructions:
Use only when the current session genuinely lacks project context:
"Check this project's MemAuthority — pull in only what you need."
The agent should choose the shortest useful path: read directly when the location is known, search when it is not, and use handoff when it needs a quick overall project handoff. If the current conversation already contains enough context, there is no need to call MemAuthority at all.
"List the takeaways from this task worth keeping long-term — I'll decide what to save."
The agent distills candidate items, and you make the final call on what to keep, edit, or discard.
"Record this task."
A common, low-effort command. By default, the agent adopts a conservative strategy — logging it as a low-risk progress entry without altering long-term rules on its own.
"Review the MemAuthority memory actually used in this task. Update it from what just happened or was verified, and remove anything obsolete."
The agent that just completed the task has the freshest code, tool results, runtime facts, and user decisions. It only needs to maintain the memory it actually read and used, rather than scanning the entire Vault every time.
"This direction is worth exploring later — drop it in MemAuthority TODO so it doesn't clutter our current context."
Here, a TODO is not a project management issue tracker, but rather:
A staging ground for ideas worth revisiting later, without consuming cognitive bandwidth today.
Once acted upon, the TODO item should be deleted, and any durable conclusions that emerge are promoted to long-term memory.
MemAuthority does not require you to deliberate over "should this go into rules or progress" every time you want to record something.
When you give an open-ended command like "Record this task", the agent's default behavior is:
progress;What should be actively filtered out by default:
Furthermore, an agent must never elevate something to a long-term rules entry simply because it "sounds important." Durable rules, handoff states, and pitfall lessons should be distilled progressively through real-world work.
System-level guardrails provided by MemAuthority:
The system's promise is not that "a low-quality note will never be written," but rather:
The agent records conservatively, MemAuthority guarantees underlying state integrity, and ongoing real-world work continuously refines and prunes the memory.
Consistency operates on two distinct layers:
Remember: progress is a low-friction entry point for milestone logging, not an immutable, append-only archive.
MEMORY.md or Legacy Notes?No need to rewrite everything by hand.
For legacy migration, MemAuthority takes a principled approach:
Let the agent perform semantic migration, rather than building custom importers for every legacy format into MemAuthority.
As long as the agent can read and understand your legacy material, it can migrate from any source:
MEMORY.md files;Standard Migration Flow:
You can simply instruct your agent:
"Read MemAuthority's memory specification first, then inspect this legacy memory file. Deduplicate, merge, update, and restructure anything worth keeping long-term. Remove anything outdated, repetitive, raw logs, ephemeral notes, or unfit for long-term storage. Propose a migration draft for my review before writing."
Migration is fundamentally a curation decision, not a mechanical copy-paste.
Distilling a bloated 5,000-line legacy dump down to 500 lines of high-signal memory is often the hallmark of a successful migration.
For initial onboarding or large-scale migration, the recommended v1 workflow is:
For the complete guide, see docs/ONBOARDING.md.
Long-term memories in MemAuthority are strictly divided into four roles:
handoff (Handoff State)The minimal essential context required for an agent to immediately take over the project. Keep it concise, actionable, and continuously updated. It should never become a bloated second README.
rules (Long-Term Rules)Architectural constraints, standing decisions, and behavioral guidelines future agents must follow. Record only settled decisions, not protracted debates or historical discussions.
progress (Milestone Progress)Key milestones and state transitions that remain relevant for future work. This is the lowest-friction entry point for logging, but not an append-only transaction log.
pitfalls (Pitfalls & Lessons)Recurring failure modes, non-obvious traps, and proven workarounds that future agents might encounter. Routine errors and one-off typos do not belong here.
A reliable heuristic:
Will knowing this change a future agent's decisions, save substantial trial-and-error, or prevent repeated mistakes?
If not, it probably does not belong in long-term memory.
Because remembering more does not mean reasoning better.
MemAuthority supports Progressive Recall, but the agent does not have to follow a fixed ritual:
handoff is usually the best starting point;Search results are coordinates, not context.
The goal is simple: keep irrelevant memory out of the current context and let the agent decide how much evidence the task actually needs.
MemAuthority v1 is built around a core principle:
Multi-Agent, Single Authority.
Different agents or clients can take turns reading and requesting changes against the same Managed Authority, while MemAuthority maintains a single, linear, deterministic version history. v1 is still designed for a single user and a single writer, not as a collaborative database for simultaneous team editing.
If Agent A updates the memory while Agent B attempts a mutation based on a stale revision, MemAuthority returns an explicit conflict and rejects the write instead of letting stale state overwrite fresh state.
Agent B must then re-fetch the latest state and decide whether to merge, overwrite, abort, or ask the user.
MemAuthority does not decide which subjective opinion is correct. Its responsibility is narrower:
Surface concurrency conflicts explicitly, so divergent edits never silently become incorrect Authority.
Git faithfully records the complete evolution of the Authority for full auditability. Active Memory contains only what remains valuable for future agents today.
History preserves evolution; memory maintains convergence.
Pruning an item from active memory does not erase it from Git history. However, truly sensitive secrets or ephemeral noise should be filtered out before they ever enter the vault.
MemAuthority requires Git and Go 1.26.5 or later. Install the current stable release with:
The v1.x Go module identity intentionally remains github.com/iasi777/v-memory for compatibility even though the canonical repository and product name are now MemAuthority. GitHub redirects the former repository URL to iasi777/memauthority.
Verify:
Expected output:
Existing automation may continue installing and invoking the compatibility executable:
No prebuilt release binaries are currently published. To build from a source checkout instead:
Release CI runs the test suite, vet, and native CLI build on Linux, macOS, and Windows; Linux CI also verifies the production Linux/ARM64 target.
When bootstrapping a new vault or migrating a large legacy corpus, have an agent with file and Git permissions read:
docs/AGENT-GUIDE.md
Once curated, validate the vault:
Review changes, commit them to Git, and launch the Managed MCP Service:
--write-enabled runs the service in read-only mode;state-dir must be located outside the Vault Authority directory;runtime_resource enable the runtime tools automatically; use --runtime-enabled only when you intentionally want to start recording work/deployment topology.For local setups, the simplest approach is having your MCP client spawn the command directly over stdio.
Once connected, MemAuthority automatically provides tool definitions, input schemas, annotations, and resource metadata to the agent. During day-to-day managed operation, you do not need to re-explain parameter schemas to your agent.
See AGENT-GUIDE.md for cross-cutting usage guidelines (on-demand recall, conservative recording, role selection, and legacy migrations).
If exposing via HTTP transport, be sure to review SECURITY.md and the frozen v1.3.2 Transport / Auth specification first.
If your primary need falls into one of these categories, dedicated alternatives are a better fit:
MEMORY.md is fine;MemAuthority is not a chat archiver, not an exhaustive knowledge base, and not a task tracker.
Its single focus is preserving:
Lessons and conclusions that future agents should never have to rediscover from scratch.
The current public compatibility baseline is v1.3.2. Earlier released contract snapshots remain unchanged.
Authoritative definitions of Vault storage formats, MCP tools, Managed runtime behavior, mutation/refusal rules, security boundaries, transport/authentication behavior, and compatibility policy are maintained under docs/contract/v1.3.2/.
This README and the user guides are explanatory; the versioned contract is authoritative when details differ.
AI Agent Memory, Long-Term Memory, MCP Memory Server, Git-backed Memory, Agent Memory Infrastructure, Agent Continuity
For v1.3.2, the primary command prints memauthority 1.3.2; the compatibility command prints v-memory 1.3.2.
Before exposing the service over HTTP transport, make sure to read SECURITY.md.
--write-enabled;docs/ONBOARDING.md — Quickstart, legacy migration, and first-time setup guidedocs/MCP-CONFIG.md — stdio / HTTP connection guide and configuration specsdocs/AGENT-GUIDE.md — Practical rules for agents on recall, recording, maintenance, and migrationdocs/FAQ.md — Frequently asked questions, design boundaries, and trade-offsexamples/README.md — Runnable sample Vault and first local MCP sessionSECURITY.md — Supported security line, deployment boundaries, and private reportingdocs/contract/v1.3.2/ — Versioned v1.3.2 public contractMemAuthority recognizes and supports the LINUX DO community.
Released under the Apache License 2.0. See LICENSE for details.
Attribution and third-party notices are documented in NOTICE and THIRD_PARTY_NOTICES.md.