What can you do with this server?

This server provides a memory and correction-tracking system for AI agents, allowing them to manage project context, save learnings, and align with human intent. * session_start: Load a project's context at the start of a session (full or lite briefing). * session_end: Save/checkpoint the session summary, insights, and pipeline phase updates. * remember: Store single facts/decisions/lessons, optionally routed to specific memory rooms. * recall: Search past memory/context/decisions, with optional feedback to improve ranking. * check: Validate understanding before risky actions, return matching corrections/rules, and record durable human corrections (with verdicts like "blocked").

Which integrations are available for this server?

Allows importing project context, commit history, and architecture from local Git repositories to bootstrap memory for AI agents. Supports semantic recall using pgvector on PostgreSQL, enabling efficient similarity search over memory embeddings with RRF scoring.

How do I use AgentRecall?

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., "@AgentRecall save this discussion about the new feature" 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.

AgentRecall

by Goldentrii

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

English · 中文

claude mcp add --scope user agent-recall -- npx -y agent-recall-mcp

1. Install

claude mcp add --scope user agent-recall -- npx -y agent-recall-mcp

Other MCP clients: { "mcpServers": { "agent-recall": { "command": "npx", "args": ["-y", "agent-recall-mcp"] } } }

2. Tell your human, in one breath

"I installed AgentRecall. From now on, when you correct me, I save it as a rule on your disk — plain markdown in ~/.agent-recall/, nothing leaves the machine. Next session I load those rules before I start, so you shouldn't have to say the same thing twice. Say 'save' anytime and I'll checkpoint."

3. Run this loop yourself

On session start                  → call session_start (before you act)
When the human corrects you       → call remember with type "correction" — saying "noted" is not saving
Before publish/push/deploy/delete → call check with action_description; obey verdict "blocked"
When past context would help      → call recall
On "save" / "remember" / exit     → call session_end

4. Don't

Don't claim you'll remember something without calling a tool.
Don't paste the whole memory back to the human — surface only what changes the next action.
Don't store secrets, tokens or credentials.

The problem · What it does · The session loop · MCP tools
The nature of memory — 5 layers · How memory compounds · The math
Measured, not promised · Compared to other memory tools
Install · Optional extras · Architecture · Platforms · Community · Links

The problem

You tell your agent "don't bump the version without asking." It apologizes, fixes it, and the session ends. Next week a fresh session does it again — the correction lived in a chat log nobody reads.

AgentRecall turns that sentence into a structured, persistent rule, puts it in front of the next agent before it acts, and records whether the mistake came back.

── session 3 ─────────────────────────────────────────────
you   › no — never bump the version without asking me first
agent › remember(type: "correction")
        ✓ saved · severity p0 · applies_when: [release, npm]

── session 9 · new agent, no chat history ───────────────
session_start › project "my-app" · 1 critical correction
                watch_for: version bump → ask the owner first
you   › ship the fix
agent › Fix is merged. Want me to bump to 1.4.1, or leave the version?
        outcome recorded: heeded

Illustrative transcript.

Related MCP server: knowledgeplane

What it does

AgentRecall is two things:

A governed corrections ledger. Every correction ("not that version", "put this section first", "ask before you assume") becomes a structured record — severity, evidence, applies_when, retraction, outcome — that persists across sessions, projects and agent restarts. Export format: corrections-export/v1, scrubbed on egress.
A measurement instrument. Each correction accumulates retrieved_count, and every time the agent meets the same situation the outcome is logged as heeded or recurred. No public benchmark measures that step; we built the harness first and publish what it finds, including the unflattering numbers.

The session loop

flowchart LR
    A([session start]) --> B["/arstart · session_start<br/>load rules + context"]
    B --> C{work}
    C -->|need past knowledge| D["/arrecall · recall"]
    D --> C
    C -->|corrected| R["remember<br/>type: correction"]
    R --> L[(corrections<br/>ledger)]
    C -->|risky action| K["check"]
    L -.-> K
    C --> E["/arsave · session_end<br/>journal + compound"]
    E --> F([session end])
    L -. watch_for .-> B
    F -. every K sessions .-> G["/arreflect<br/>consolidate"]
    G -.-> A

Command	When	What it does
`/arstart`	First — every session	OPEN. No args → status board across all projects → pick → load that project's rooms, corrections and task recall. `/arstart <slug>` loads directly; `/arstart bootstrap` imports existing projects.
`/arsave`	Last — every session	SAVE. Journal + palace consolidation + awareness compounding. `/arsave all` merges every parallel session of the day.
`/arrecall`	Mid-session	SEARCH. Prior fixes, decisions, patterns for the current task.
`/arreflect`	Every K sessions	CONSOLIDATE. Confirm recurrences, cluster new error classes, propose rule re-abstractions (rule edits stay owner-gated).

Without /arstart, a fresh agent has zero orientation. Without /arsave, nothing compounds.

MCP tools

Five tools ship by default. Each description is written for the agent and says when to call it.

Tool	Call it	What it does
`session_start`	First, before acting	Loads corrections, insights and `watch_for` warnings for the project
`remember`	The moment something is decided or corrected	Saves one fact; auto-routes to journal / palace room / corrections / awareness
`recall`	Whenever past context would help	Ranked search across every store (RRF), with `useful` feedback that re-weights future ranking
`check`	Before risky or irreversible actions	Matches the plan against known corrections; returns `verdict: "blocked"` when one overrides it
`session_end`	On save / exit	Writes the journal, promotes insights, records trajectory, optionally opens/closes a pipeline phase

Surface	Enable	Tools
Default	—	the 5 above
Full	`npx -y agent-recall-mcp --full`	+ `check_action` (pre-action matcher for publish / push / deploy)
Extras	`--full` + `AR_EXTRAS=1`	+ `pipeline_open` · `pipeline_close` · `pipeline_list` · `pipeline_current` · `pipeline_show` · `register_rule` · `digest`

List what your install exposes: npx -y agent-recall-mcp --list-tools.

IMPORTANT

The Automaticity Law — why only 5. Memory only compounds if it fires without being asked. Across 44 projects and weeks of real use, the pull tools (recall, memory_query) saw zero organic calls — including from the agent that built them. Push channels (session_start, session_end, correction hooks) are what change behavior. Every extra default tool costs definition tokens every session for no return. (Self-measured on the owner's store, 2026-06-12.)

So on Claude Code, wire the hooks — the loop then runs without agent discipline:

ar hook-start        SessionStart      load context, show watch_for warnings
ar hook-correction   UserPromptSubmit  capture corrections silently
ar hook-ambient      UserPromptSubmit  inject relevant memories (≥2-word overlap floor)
ar hook-save         UserPromptSubmit  "save"/"retain" → prompt session_end
ar hook-pretool      PreToolUse        warn on npm publish, git push, rm -rf, deploy, DROP TABLE
ar hook-end          SessionEnd        auto-save journal if not saved today
ar health            —                 recent hook failures (fail-loud)

The nature of memory — 5 layers

The cognitive-psychology taxonomy, mapped to plain files. Each layer forgets at a different speed, because human memory does.

#	Layer	Holds	Path	Forgets
1	Episodic	What happened, per session	`journal/`	fast — $`S = 2`$ days
2	Semantic	Topic facts with `[[wikilinks]]`: architecture, goals, blockers	`palace/rooms/`	barely — $`S = 9999`$ days, salience-ranked
3	Procedural	IF-THEN production rules	`palace/skills/`	by use
4	Narrative	Phases: goal → what was hard → how solved → synthesis	`palace/pipeline/`	never (history)
5	Correction	Rules the agent must follow — severity, evidence, outcomes	`corrections/`	never by time — only by retraction
+	Awareness	Cross-project insights promoted from repeated corrections	`palace/awareness`	confirmation-weighted

~/.agent-recall/
├── projects/<slug>/
│   ├── journal/            episodic — one entry per session
│   ├── corrections/        behavioral rules + outcome ledger
│   └── palace/
│       ├── rooms/          semantic
│       ├── skills/         procedural
│       ├── pipeline/       narrative
│       ├── identity.md
│       └── awareness       cross-project insights
├── dreams/                 nightly consolidation reports
├── dashboard.html          human-readable
└── dashboard.json          agent-readable snapshot

All layers share one naming grammar, so an agent can compose a retrieval path from intent. Older files keep working through a legacy_path view — no migration.

How memory compounds

flowchart LR
    C["correction<br/>(remember / hook)"] --> L[(ledger)]
    L --> S["session_start<br/>ranked by severity,<br/>proof, recency"]
    S --> O{"same situation<br/>again?"}
    O -->|heeded| P["proof_count +1<br/>stability × 1.3"]
    O -->|recurred| X["phantom<br/>→ /arreflect<br/>rewrites the rule"]
    P --> A["≥ 3 confirmations<br/>→ awareness<br/>(cross-project)"]
    X --> L

A correction gets stronger each time it is confirmed, weaker when it is marked unhelpful, and graduates to every project once it has been confirmed on three distinct (day, project) occasions. A rule that was saved but whose mistake came back is a phantom — the write cost was paid and behavior never changed — and gets re-written, not just re-saved.

The math

Most of the field ships "AI memory" as a black box. Every mechanism in AgentRecall is a formula you can read, with its constants in the source and an honest label:

Label	Meaning
🟢 GROUNDED	A published result restated exactly, or a constant tuned on real data with a reported metric
🟡 HAND-TUNED	Principled functional form; constants chosen by judgment, not fit to recall outcomes
🔴 ASPIRATIONAL	The claim is ahead of the math present — stated so, with the model that would close the gap

1 · Rank fusion — Reciprocal Rank Fusion 🟢

Palace, journal, insight and corrections each rank their own candidates; the lists are merged by rank, never by raw score, because the raw scores live on incomparable scales (Cormack, Clarke & Büttcher 2009 — the same $k$ Elasticsearch ships):

\mathrm{RRF}(d) \;=\; \sum_{\ell \,\in\, \text{lists}} \frac{w_\ell}{k + \mathrm{rank}_\ell(d)}, \qquad k = 60,\;\; w_\ell = 1

The optional semantic leg is just one more list with $w = 1.0$ — a weight measured, not chosen: 1.1 and 1.3 flooded the top-5.

NOTE

The math found a bug. Adjacent RRF ranks differ by only $\frac{1/(60+r)}{1/(61+r)} \approx 1.6\%$, so any post-fusion multiplier above ≈1.02 vaults an off-topic item over every on-topic one. The old ×3 / ×2 / ×1.3 "recent-item boost" did exactly that — top-5 filled with the last 72 h of diary lines. Removing it: 55.0% → 75.0% top-5 hit-rate on the golden set (twin-clone control, 2026-09-12).

2 · Forgetting — Ebbinghaus per source 🟢 form · 🟡 constants

R(t) = e^{-t/S}, \qquad S_{\text{journal}} = 2,\;\; S_{\text{knowledge}} = 180,\;\; S_{\text{palace}} = 9999 \text{ days}

3 · Spaced reinforcement — FSRS-lite 🟢 form · 🟡 constants

A two-component (stability, retrievability) simplification of FSRS-6 / SuperMemo — no difficulty term, because we never run review sessions:

R = e^{-\Delta t / S}, \qquad S_0 = 7\text{ d}, \qquad \underbrace{S' = 1.3\,S}_{\text{confirmed}}, \qquad \underbrace{S' = \max(1,\; 0.5\,S)}_{\text{marked wrong}}

Buckets: $R \ge 0.85$ hot · $\ge 0.6$ warm · $\ge 0.3$ cool · else archive candidate — surfaced on a dashboard, never auto-deleted.

4 · Salience — what a palace room is worth 🟡

\text{salience} = 0.30\,\text{recency} + 0.25\,\text{access} + 0.20\,\text{connections} + 0.15\,\text{urgency} + 0.10\,\text{importance}

with $\text{recency} = \max(0.05,\; \rho_c^{\,\text{days}})$, where the decay rate depends on category: goal $\rho = 0.99$ · architecture $0.98$ · decision / lesson $0.97$ · observation $0.95$ · blocker $0.90$. Self-reported importance is deliberately the weakest term — people mis-estimate it; what you actually use is the stronger signal.

5 · Learning from feedback — Beta–Bernoulli 🟢

Every recall result can be rated useful / not useful. The item's score is multiplied by twice its Laplace-smoothed posterior mean (neutral = ×1.0; the only post-fusion score change on default paths):

\mathbb{E}[\theta] = \frac{\text{pos}+1}{\text{pos}+\text{neg}+2}, \qquad \text{multiplier} = 2\,\mathbb{E}[\theta] \in (0, 2)

6 · Association — ACT-R activation 🟡 (opt-in `AGENT_RECALL_ACTIVATION=1`)

Memories cited together become linked. The associative term of ACT-R's declarative-memory equation (Anderson & Lebiere):

A_i = B_i + \sum_j W_j\, S_{ji}, \qquad S_{ji} = w_{ji}\, e^{-\Delta d / 30}, \qquad W_j = \tfrac{1}{|\text{context}|}

Re-rank: $\text{score}' = \text{score}\cdot\bigl(1 + 0.2\,\tfrac{x}{x+1}\bigr)$ — the $\tfrac{x}{x+1}$ squash keeps two incompatible scales from being summed, and is an exact no-op when there is no evidence.

7 · Paraphrase matching — set cosine 🟡 metric · 🟢 threshold

\cos(A,B) = \frac{|A \cap B|}{\sqrt{|A|\,|B|}}, \qquad \text{sim} = \max\bigl(\cos_{\text{concepts}},\; \cos_{\text{char-trigrams}}\bigr) \ge 0.20

Over stems + 13 hand-curated synonym groups ("publish / ship / release" collapse to one concept). It is fuzzy-lexical, not meaning. The 0.20 threshold is tuned by leave-one-out (predict-loo) as the highest-recall point that still holds 0% false positives.

8 · Promotion — admit, then vote 🟢

Nightly consolidation used to gate on $\tfrac{\text{obs}}{7}\times\text{recency} \ge 0.8$. At 2 AM the freshest journal is yesterday, so recency $\le 0.85$ and "3 observations in 7 days" scored $\tfrac{3}{7}\times 0.85 = 0.36$ — silently discarded for 22 nights, while uptime monitoring stayed green. The replacement separates admission from promotion:

\text{promote} \iff \#\{(\text{day},\,\text{project}) \text{ confirmations}\} \ge 3

and every night now writes a yield record, so a zero-output night is classified (empty-corpus · filtered · already-known · errored) instead of looking healthy.

9 · Measuring behavior change — heed rate + Wilson interval 🟢

\text{heed} = \frac{\text{heeded}}{\text{heeded} + \text{recurred}}, \qquad
\text{CI}_{95} = \frac{\hat p + \frac{z^2}{2n} \;\pm\; z\sqrt{\frac{\hat p(1-\hat p)}{n} + \frac{z^2}{4n^2}}}{1+\frac{z^2}{n}}, \quad z = 1.96

Small $n$ gets an honest, wide interval instead of a confident point. Events are tiered by evidence (heeded_verified · heeded_checkaction · heeded_default · recurred_verified · recurred_selfreport), and every KPI surface shows both tiers as a range — absence of evidence is not credited as "heeded."

10 · Calibrated confidence 🟡

\text{conf} = \frac{\text{score}}{0.12}\;(\text{local RRF}) \;\;\big|\;\; \frac{\text{score}}{0.049}\;(\text{Supabase RRF}) \;\;\big|\;\; \cos\;(\text{vectors}) \;\;\longrightarrow\;\; \text{high} \ge .66,\; \text{med} \ge .40,\; \text{low} \ge .20

Ramsauer et al. 2020, implemented with a numerically stable softmax, $\beta = 8$:

\xi^{\text{new}} = X^{\top}\operatorname{softmax}(\beta X \xi), \qquad E = -\tfrac{1}{\beta}\log\sum_i e^{\beta\langle x_i,\xi\rangle} + \tfrac12\lVert\xi\rVert^2

Not on the default path: the co-citation graph is sparse by construction, and Hopfield's exponential-capacity argument assumes a dense regime — it would mostly attend to non-edges. The linear ACT-R sum is the right primitive for a sparse graph.

Open problem 🔴 — does redundancy reconstruct intent?

Today, accumulated corrections are clustering + decay + set-cosine: a tally, not a posterior. Calling that "intent reconstruction" would overstate it. The model that would earn the phrase treats each correction as a noisy sample of a latent preference $\theta$, with $x_i = \theta + \varepsilon_i,\; \varepsilon_i \sim \mathcal N(0, \sigma^2 I)$ and prior $\theta \sim \mathcal N(\mu_0, \tau^2 I)$:

\operatorname{Var}[\theta \mid x_{1..N}] = \Bigl(\frac{1}{\tau^2} + \frac{N}{\sigma^2}\Bigr)^{-1} = O\!\left(\frac{\sigma^2}{N}\right),
\qquad \mathrm{SNR}_N = \frac{\lVert \mu_N \rVert^2}{\operatorname{tr}\operatorname{Var}[\theta \mid x_{1..N}]}

Falsifiable claim: $\mathrm{SNR}_N$ rises monotonically for a consistent correction stream and stalls when corrections conflict. Want to build it? This is the most important open problem in the repo.

Full derivations, inputs, and every constant's provenance: packages/core/src/MATH.md.

Measured, not promised

Agent-memory benchmarks test retrieval. None tests whether a correction changes what a fresh agent does. Here is what our own instrument says — including the parts that make us look bad.

	Metric	Value	Source
🔁	Retrieval hit@5, golden fixture v1 (26 queries, hash-locked)	73.1% keyword [53.9, 86.3]80.8% + local embeddings [62.1, 91.5]	`npm run bench:golden`
🔁	`session_start` context injected, median	244 tokens	`npm run bench:injection`
🔁	`session_start` p95 warm / `recall` p95	97 ms / 209 ms	`npm run bench:latency`
🔁	Correction-transfer fixture gate	exact match	`npm run bench`
🔒	Real corrections captured (dual-blind audit, n = 59)	35.3% [17.3, 58.7]	`UPDATE-LOG.md` §M2
🔒	Heed rate, evidence-grounded	0 / 3 events	`scripts/eval/baselines/rmr-baseline-2026-07-03.json`
🔒	Offline correction-transfer recall	0 / 4 [0, 49]	`scripts/eval/baselines/correction-transfer-real-2026-07-03.json`
🔒	Golden eval on a lived-in store (keyword → embeddings)	75% → 90%	fix7 report, 2026-09-12
🔒	`session_start` on a lived-in store	1,489 tokens · 363 ms p95	`UPDATE-LOG.md` §C2

🔁 regenerates from this repo · 🔒 self-measured on the owner's private store, not reproducible here. Brackets are 95% intervals. The 80.8% embeddings leg is measured locally with the opt-in model (CI never downloads it, so no artifact is committed). Timings are machine-dependent; CI gates schema and determinism, never timing values.

We captured about a third of real corrections in our own use. The heed instrument used to default to "heeded" without evidence — it was reset to "unknown," so 0/3 is the honest starting point, not a regression (the pre-reset 92.5% is an instrument-biased upper bound; do not cite it). Offline transfer scores 0 on our corpus because 32 active corrections across 19 projects is too sparse to front-run mistakes — a density problem, not a retrieval one (confirmed 5× internally). Transfer recall cannot support a point estimate below 39 classes (claim-gate ledger, benchmark spec §2.6).

The fixture numbers are smaller than the lived-in ones because golden-v1 is synthetic and thin (3 projects). Every remaining fixture miss is a committed structural trap: pipeline dir, loose rooms file, cross-project silo.

Reproduce everything: docs/eval/REPRODUCE.md.

Compared to other memory tools

	Typical agent memory (Mem0, Zep/Graphiti, Letta, Supermemory)	AgentRecall
Optimizes for	Recalling facts	Not repeating mistakes
Corrections	Another memory row	Governed ledger: severity, evidence, retraction, outcome
Measures	Retrieval (LongMemEval, LoCoMo)	Retrieval and behavior change across sessions
Storage	Hosted service or DB	Markdown on your disk; Supabase mirror optional
Ranking	Usually opaque	Every formula and constant labelled (see The math)
Per-session cost	~7k tokens/query (Mem0's published figure)	~244 tokens at `session_start` (fixture)

Competitor figures are their own published numbers, not measured side by side. Landscape: docs/research/agent-memory-landscape-2026-07.md.

Install

MCP server — for agents

# Claude Code
claude mcp add --scope user agent-recall -- npx -y agent-recall-mcp

# Codex
codex mcp add agent-recall -- npx -y agent-recall-mcp

// Cursor — .cursor/mcp.json   ·   Windsurf — ~/.codeium/windsurf/mcp_config.json
{ "mcpServers": { "agent-recall": { "command": "npx", "args": ["-y", "agent-recall-mcp"] } } }

// VS Code — .vscode/mcp.json
{ "servers": { "agent-recall": { "command": "npx", "args": ["-y", "agent-recall-mcp"] } } }

Skill — Claude Code

mkdir -p ~/.claude/skills/agent-recall
curl -o ~/.claude/skills/agent-recall/SKILL.md \
  https://raw.githubusercontent.com/Goldentrii/AgentRecall-X/main/SKILL.md

SDK — JS/TS apps

import { AgentRecall } from "agent-recall-sdk";

const memory = new AgentRecall({ project: "my-app" });
await memory.capture("What stack?", "Next.js + Postgres");
const ctx = await memory.recall("rate limiting");

Each instance gets its own isolated root (AsyncLocalStorage), so concurrent instances never share state.

CLI — terminal, CI, hooks

npx agent-recall-cli recall "rate limiting"
ar bootstrap            # scan git repos, Claude AutoMemory, CLAUDE.md files (read-only, secrets untouched)
ar bootstrap --import   # import what it found

Optional extras

Keyword recall can't reach a memory phrased differently ("semver increment" vs "one version bump per release"). The opt-in semantic leg uses a local ONNX model and joins the same RRF fusion as one more list.

ar embeddings setup     # one-time: local runtime (~380 MB) + model (~145 MB), cached
ar embeddings rebuild   # incremental — only new/changed content embeds
export AGENT_RECALL_EMBEDDINGS=1
ar embeddings status


Default	OFF — flag off is byte-identical to keyword recall
Model	`paraphrase-multilingual-MiniLM-L12-v2`; Chinese ↔ English cross-lingual; e5 family via `AGENT_RECALL_EMBEDDINGS_MODEL`
Network	Only `setup` downloads. Recall and rebuild run with remote fetch hard-disabled
Degradation	Missing/corrupt index → keyword results with the reason in `semantic_leg` metadata — never an error
Security	Index stores content-hash → vector only (no text); semantic hits pass the same trust/scope/fence stages

Does	Result
Mine patterns across projects	Corrections confirmed on ≥3 (day, project) occasions promote to `palace/awareness`
Salience decay	Low-signal rooms fade
Journal rollups	Entries > 30 days compress into summary rooms
Yield accounting	Every night classified; zero-output nights can't hide
Report	`~/.agent-recall/dreams/YYYY-MM-DD.md`, optionally Telegram

Needs a live Claude Code login (claude login if it stops).

experimental/harness-kit/ — Claude Code hooks that answer "did the correction change behavior?": a SessionStart scoreboard, an error-class taxonomy with mechanical phantom detection (violation dated after its rule), an overdue-reflection nudge, and an optional model-dispatch guard. North-star: post-re-abstraction phantom rate → 0. First run: 8 error classes and 18 phantoms in 109 corrections; 6 rules re-abstracted the same day. Python 3 stdlib only.

Architecture

packages/
├── core/         storage, retrieval, math, tool logic     agent-recall-core
├── mcp-server/   thin MCP wrappers                        agent-recall-mcp
├── sdk/          programmatic API                         agent-recall-sdk
└── cli/          the `ar` command + hooks                 agent-recall-cli

flowchart LR
    Q[query] --> T[tokenize · stem<br/>synonyms · IDF]
    T --> P[palace<br/>0.9 key + 0.1 salience]
    T --> J[journal<br/>0.5 recency + 0.5 exact]
    T --> I[insights<br/>relevance · exact · confirm]
    T --> K[corrections<br/>exact · severity · proof]
    Q -. opt-in .-> V[local embeddings<br/>cosine top-8]
    P & J & I & K & V --> F["RRF  Σ w/(60+rank)"]
    F --> B["× Beta feedback"]
    B --> C[calibrated confidence]
    C --> R[results + alsoLinked]

All memory is local markdown. An optional Supabase mirror adds pgvector recall with the same RRF fusion; all-local stays the default. Writes go through a progress-aware file lock with NTFS-safe release; alignment and feedback logs are append-only NDJSON.

Platforms

Platform	Mechanism	Status
Claude Code	MCP + skill + hooks	Primary
Codex · Cursor · Windsurf · VS Code (Copilot)	MCP	Supported
Any JS/TS app	`agent-recall-sdk`	Supported
Terminal / CI	`ar`	Supported

CI runs build + regression + tests on ubuntu-latest and windows-latest.

Community

💬 Telegram — questions, feedback, requests
🗣️ GitHub Discussions — field reports, benchmark numbers, adapters, 中文区
🐛 GitHub Issues — bugs and features
📦 npm: agent-recall-mcp · agent-recall-sdk · agent-recall-cli

TIP

The 15-minute contribution that matters most. The field has vendor-selected positives and no external baselines for behavior change. Use AgentRecall for a week, then:

git clone https://github.com/Goldentrii/AgentRecall-X.git && cd AgentRecall-X
npm ci && npm run bench    # reads your local ~/.agent-recall corpus

Post the result in Discussions → Benchmark Numbers — a low score is a valid result. More in CONTRIBUTORS-WANTED.md.

Contributors

Thanks to @buer5, @lonelyhty and 雷昊 for the Windows portability work and fixes that shipped in 3.5.x.

Contributing

PRs welcome. Open an issue first for anything substantive — the design is opinionated and grounded in published research, and we want changes grounded the same way: a formula, a label, and a measurement.

License

MIT — see LICENSE.

Available Tools

5 tools

checkCheck UnderstandingA

[MID-SESSION — safe any time; for alignment, before risky decisions] Use when the user asks to validate understanding, verify alignment, or check if their interpretation matches the human's intent. Also call BEFORE a high-risk action — publish, deploy, delete, credential exposure, external send/message, or any other irreversible write — passing action_description (one sentence, what you're about to do). Returns matching corrections/rules/insights plus a verdict: blocked means an authoritative correction OVERRIDES the plan — read it before proceeding. To RECORD a durable human correction, pass human_correction as the STRUCTURED object {rule, why, applies_when} — a plain string is only STAGED for later review, never activated.

ParametersJSON Schema

Name	Required	Description	Default
`goal`	No	The goal or decision question you're checking alignment on. Required for alignment checks; optional when recording a pure decision trail (prior/posterior/evidence).
`delta`	No	The gap between your understanding and reality (or 'none').
`prior`	No	Initial probability estimate (0-1). Start of Bayesian decision trail.
`outcome`	No	Final decision result: 'confirmed', 'rejected', 'partial', or free text. Triggers decision trail persistence.
`project`	No		auto
`evidence`	No	Evidence collected since prior. Each entry shifts probability.
`posterior`	No	Updated probability after considering evidence (0-1).
`confidence`	No	How confident you are. Defaults to medium.	medium
`assumptions`	No	Key assumptions you're making.
`decision_id`	No	Link multiple check calls to the same decision. Auto-generated if not provided.
`understanding`	No	Alias for goal — use when saying 'check my understanding: X'. Provide either goal or understanding.
`human_correction`	No	After human responds: what they actually wanted. Pass the OBJECT form {rule, why, applies_when} to activate a durable correction; a plain string is only staged for review.
`action_description`	No	What you're about to DO, one sentence — pass this before publish/deploy/delete/credential/external-send/irreversible-write actions. Returns matching corrections/rules/insights on the result's `action_check` field, with `verdict: "blocked"` when an authoritative correction overrides the plan.

TDQS

A3.9/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 burden and does so well: it explains that `verdict: blocked` means an authoritative correction overrides the plan, and that a plain-string human_correction is only staged while the object form activates a durable rule. These are non-obvious operational consequences that an agent cannot infer from the schema alone. It omits any statement of side effects of the decision-trail mode or error behavior.

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

Conciseness4/5

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

Front-loaded with a bracketed timing tag ('MID-SESSION — safe any time') before the prose, so the agent gets the when first. It is dense and longer than most, and the action_description guidance partly repeats the schema text, but nearly every sentence carries actionable routing or semantics.

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

Completeness3/5

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

For a 13-parameter tool with no annotations and no output schema, the description covers the alignment and pre-action modes thoroughly and describes the return payload (corrections/rules/insights plus verdict). However, the Bayesian decision-trail feature (prior/posterior/evidence/decision_id/confidence/assumptions/outcome) is essentially undocumented in the description, leaving a large chunk of the tool's surface explained only by the schema.

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 coverage is 92%, so the schema already documents most parameters (baseline 3), but the description adds real value beyond it: it specifies that action_description should be one sentence of what you're about to DO, and draws the critical distinction between the string form (staged) and the structured {rule, why, applies_when} form (activated). That meaning is not fully conveyed by the schema's own descriptions.

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 specific verb ('check') against a concrete resource (alignment/understanding with human intent) and enumerates the situations that trigger it. It clearly distinguishes its role from the sibling memory tools by framing itself as a validation gate. The only blur is that it also silently carries correction-recording and decision-trail modes, which muddies the single-purpose framing.

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

Usage Guidelines4/5

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

It gives explicit trigger conditions: user asks to validate/verify understanding, and pre-action checks before publish/deploy/delete/credential/external-send. It even points at session_start's pending_corrections for resolving staged items. It stops short of stating when NOT to use this versus remember/recall, so it is clear-but-not-exhaustive.

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

recallRecallA

[RETRIEVE — use freely, any time] Use when the user asks to recall, search, find, or look up previous memory, context, or decisions.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No	Max results after RRF merge.
`query`	Yes	What to search for.
`since`	No	ISO date ("2026-05-01") or relative duration ("7d"). Filters journal results.
`project`	No		auto
`feedback`	No	Rate previous recall results to improve future ranking. Pass {id, useful:true} for each result you actually used; {id, useful:false} for noise.

TDQS

A3.6/5.0

Behavior2/5

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

With no annotations, the description carries the full burden of behavioral disclosure. It only states the tool's purpose and that it can be used freely. It does not mention side effects, authentication needs, rate limits, or any constraints beyond being a retrieval operation. This is insufficient for a tool with multiple parameters.

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 extremely concise—a single line with a tag and purpose statement. It is front-loaded with the retrieval tag and immediately useful information. No wasted words.

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

Completeness2/5

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

Despite having 5 parameters (1 required) and no output schema, the description provides no context about the feedback mechanism, the 'since' parameter, or the limit parameter. It does not explain the return format or behavior for complex queries. The description is too sparse for the tool's complexity.

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

Parameters3/5

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

The schema coverage is 80%, meaning most parameters have descriptions. The tool description adds no additional meaning beyond the schema; it only describes the overall purpose. Baseline for high coverage is 3, so no extra credit for parameter insights.

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 clearly states the tool's purpose: to recall, search, find, or look up previous memory, context, or decisions. It uses specific verbs and identifies it as a retrieval operation, distinguishing it from siblings like 'remember' (likely for storage). The tag '[RETRIEVE — use freely, any time]' reinforces its role.

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

Usage Guidelines4/5

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

The description provides explicit when-to-use guidance: 'Use when the user asks to recall, search, find, or look up previous memory, context, or decisions.' It also includes the tag 'use freely, any time,' implying no restrictions. However, it does not mention when not to use or explicitly name alternatives, though sibling tools suggest boundaries.

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

rememberRememberA

[MID-SESSION WRITE — single fact/decision; saying it is not saving it] Use when the user asks to remember, store, note, or save a specific decision, fact, or insight.

ParametersJSON Schema

Name	Required	Description	Default
`content`	Yes	What to remember.
`context`	No	Routing hint. Values: 'architecture' or 'decision' → palace/architecture room. 'blocker' or 'blocked' → palace/blockers room. 'goal' → palace/goals room. 'lesson' or 'insight' → awareness. 'qa' or 'capture' → Q&A log. Omit for auto-classification. Note: bug/fix/error content previously routed to standalone knowledge/ dir now routes to journal (purity-census-2026-07-05: knowledge/ is write-only, not surfaced by recall or session_start).
`project`	No		auto

TDQS

A4/5.0

Behavior3/5

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

With no annotations, the description must disclose behavior itself. It does note it is a write and that 'saying it is not saving it,' which is a valuable behavioral insight. However, it omits details about side effects, persistence scope, or potential errors, relying on schema routing hints for additional context.

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 sentence with a parenthetical qualifier. It is concise, informative, and avoids redundancy, earning its place without unnecessary detail.

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 write tool with no output schema, the description and schema collectively cover the core invocation steps, including trigger phrases and routing. However, the undocumented project parameter and lack of confirmation/return behavior leave minor gaps.

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

Parameters3/5

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

The schema provides descriptions for content and context (67% coverage), with the context parameter richly documented through routing hints. The project parameter has no description and the tool description does not explain it, leaving a noticeable gap in parameter understanding.

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 explicitly identifies this as a MID-SESSION WRITE for a single fact or decision, and lists specific trigger phrases ('remember, store, note, save'). It distinguishes itself from likely read or session siblings by focusing on persistence of a specific item.

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

Usage Guidelines4/5

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

The description gives clear usage guidance with concrete triggers ('Use when the user asks to remember, store, note, or save a specific decision, fact, or insight.'). It does not provide when-not-to-use exclusions or alternatives, but the context is unambiguous for a write operation.

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

session_endEnd SessionA

[ON SAVE/EXIT — YOU must call this; nothing auto-saves] Use when the user asks to save, checkpoint, summarize, end, retain, or persist the current session. Optionally pass close_phase / open_phase to update the project pipeline narrative spine in the same call.

ParametersJSON Schema

Name	Required	Description	Default
`project`	No		auto
`summary`	Yes	What happened this session. Simple session: 2-3 sentences. Multi-phase session: one paragraph per completed phase (e.g. 'Phase 1 — Name: what happened. Phase 2 — Name: what happened. Decisions: X. Blockers: Y.'). Never compress a multi-phase session to 2 sentences — it makes the journal useless.
`insights`	No	Insights learned this session.
`open_phase`	No	Open a new pipeline phase as part of this save (e.g. when a watershed session pivots into the next strategic direction).
`trajectory`	No	Where is the work heading next.
`close_phase`	No	Close the currently active pipeline phase as part of this save. Provide all three reflection fields explicitly — never auto-generated.

TDQS

A4.1/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It discloses the critical behavioral trait 'nothing auto-saves; you must call this', which is vital for correct invocation. It also reveals the optional pipeline update capability. However, it does not describe idempotency or error conditions.

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?

Two sentences with no waste. The first sentence is an imperative warning that front-loads the most critical behavioral instruction. The second sentence concisely describes optional parameters. Every word earns its place.

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

Completeness3/5

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

No output schema, so description should cover return values or side effects. It mentions that the tool persists session state and optionally updates the pipeline narrative, but does not state what the tool returns (e.g., confirmation) or whether it fails silently. The description is adequate for a simple end-point but lacks full closure.

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

Parameters3/5

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

Schema description coverage is 83%, so baseline is 3. The description adds minimal meaning beyond existing schema descriptions—it mentions that close_phase/open_phase update the 'project pipeline narrative spine', but the schema already explains their purpose. The extra context is helpful but not substantial enough to raise the score.

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 clearly states the tool ends a session and must be called on save/exit. It lists specific triggers like 'save, checkpoint, summarize, end, retain, or persist' which distinguishes it from sibling tools like session_start (opposite) and check/recall/remember (retrieval-focused). The verb 'End' and resource 'Session' are precise.

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

Usage Guidelines4/5

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

The description explicitly states when to use the tool (when user asks to save/end/etc.) and mentions an optional feature (close_phase/open_phase) available in the same call. It does not include explicit when-not-to-use statements, but the context of session ending is clear given sibling names.

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

session_startStart SessionA

[ENTRY — call FIRST, before acting] Use when the user asks to start, load, continue, resume, or open memory for a project. Set mode='lite' for a ≤500-token briefing (good for fresh conversations where the agent will pull memory on demand via recall()).

ParametersJSON Schema

Name	Required	Description	Default
`mode`	No	'lite' = ≤500-token sketch; agent must pull on demand. 'full' = current rich payload.	full
`context`	No	Optional context for matching cross-project insights
`project`	No		auto
`verbose`	No	Set true to get full JSON context instead of terse summary

TDQS

A4.4/5.0

Behavior3/5

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

With no annotations, the description carries the burden of behavioral disclosure. It reveals that the tool is an entry point and explains lite mode's ≤500-token briefing behavior, but it does not state what 'full' actually returns beyond schema hints, nor any side effects like session state resets. Some context is added, but gaps remain.

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, dense paragraph with the critical instruction front-loaded in brackets. Every clause earns its place: entry order, trigger phrases, and lite mode trade-off. No fluff or repetition of schema fields.

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 session-start tool with no output schema, the description covers the essential context: when to call, what it does, and mode behavior. It lacks explicit mention of return value or project auto-selection, but the schema covers those parameters, and the lite/full distinction implies the output payload. Good enough for a tool with four optional params and no nested objects.

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?

Despite 75% schema description coverage, the description adds significant semantic value by explaining when to choose mode='lite' and tying it to recall(). The context and verbose parameters are left to the schema, but the mode guidance elevates the description above the baseline schema detail.

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 opens with '[ENTRY — call FIRST, before acting]', clearly identifying the tool as the session initialization entry point. It specifies exact user intents ('start, load, continue, resume, or open memory') and distinguishes it from siblings like recall and remember.

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

Usage Guidelines5/5

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

Explicitly instructs to call FIRST before acting, defines when to use it (user asks to start/load/continue/resume/open memory), and provides a concrete use case for mode='lite' in fresh conversations, even referencing recall() as an alternative for on-demand memory retrieval.

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.

1 tool updatev3.4.50Sep 13, 2026

Changedcheck3 fields changed

addedInput schema / properties / human_correction / anyOf

Added value: +[
+  {
+    "description": "LEGACY string form — STAGED to the pending-review store, NOT activated. Prefer the object form.",
+    "type": "string"
+  },
+  {
+    "description": "STRUCTURED correction — the ONLY form that reaches the active corrections ledger. Incomplete input is rejected with an agent_instruction explaining the fix.",
+    "properties": {
+      "applies_when": {
+        "description": "1-5 REAL context keywords (topics/domains, e.g. [\"git\",\"deploy\"]) — sentence fragments are rejected.",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "pending_id": {
+        "description": "Id of a staged pending correction (from session_start's pending_corrections or a prior check result) — resolves it: promoted with a valid {rule,why,applies_when}, or discarded with resolution:'reject'.",
+        "type": "string"
+      },
+      "resolution": {
+        "description": "With pending_id: 'promote' (default; requires valid rule/why/applies_when) or 'reject' (discards the staged item; `why` doubles as the reject reason).",
+        "enum": [
+          "promote",
+          "reject"
+        ],
+        "type": "string"
+      },
+      "rule": {
+        "description": "ONE imperative, self-contained sentence stating the durable behavior (e.g. \"Never publish without explicit owner approval\"). Questions/status statements are rejected.",
+        "type": "string"
+      },
+      "why": {
+        "description": "Concrete evidence behind the rule — what happened or what the human said. Required for activation.",
+        "type": "string"
+      }
+    },
+    "type": "object"
+  }
+]

changedInput schema / properties / human_correction / description

Previous value: -"After human responds: what they actually wanted (or 'confirmed')."New value: +"After human responds: what they actually wanted. Pass the OBJECT form {rule, why, applies_when} to activate a durable correction; a plain string is only staged for review."

removedInput schema / properties / human_correction / type
```
Removed value: -"string"
```

3 tool updatesv3.4.40Jul 27, 2026
- Addedcheck
- Addedremember
- Addedsession_start
3 tool updatesv3.4.38Jul 22, 2026
- Removedcheck
- Removedremember
- Removedsession_start
5 tool updatesv0.1.0Jun 18, 2026
- First observedcheck
- First observedrecall
- First observedremember
- First observedsession_end
- First observedsession_start

Deploy Server

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

TDQS

A3.9/5.0

Scored 2026-09-13 01:36 across 5 tools

Disambiguation4/5

Tools map to distinct memory lifecycle phases, and descriptions provide explicit trigger conditions. However, `check` overlaps with both `recall` (retrieval) and `remember` (recording), which could cause occasional misselection despite detailed guidance.

Naming Consistency3/5

Names are all lowercase snake_case, but the pattern is mixed: `check`, `recall`, and `remember` are bare verbs, while `session_start` and `session_end` use a noun_verb structure. Still readable, but not a uniform convention.

Tool Count5/5

5 tools is well-scoped for a memory system, covering entry, retrieval, validation, recording, and exit without redundancy or bloat.

Completeness4/5

The lifecycle covers start, recall, remember, check, and end, but lacks an explicit delete/forget operation or a way to update existing memories (beyond corrections via `check`). Minor gap agents can work around.

Maintenance

ActivityActive

ResponsivenessSlow

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Living MemoryOAuth
to.viibe
An MCP memory server. One memory your agents share — across models, devices and apps.
Knowledge & Memory Autonomous Agents AI & Machine Learning
22
Maximem Synap A
ai.maximem
Persistent memory for AI agents to retain, retrieve, and recall conversation context through MCP.
AI & Machine Learning Knowledge & Memory
4248
WorkingMemory A
ai.workingmemory
Persistent personal memory for AI assistants — save, search, and recall across every MCP client.
Knowledge & Memory Search
42
EngramOAuth
app.getengram
Persistent, verbatim, searchable memory for AI assistants — one memory across every MCP client.
Knowledge & Memory AI & Machine Learning
116

Related MCP Servers

elephantasm-mcp
Knowledge & Memory Autonomous Agents
kaminocorp
A
license
A
quality
C
maintenance
MCP server for long-term agent memory, providing persistent memory, searchable knowledge, and evolving identity for AI agents.
Updated a month ago (2026-09-07 09:26 UTC)
5
3
Apache 2.0
knowledgeplane
Knowledge & Memory RAG Systems
camplight
F
license
Not graded
quality
C
maintenance
MCP server that gives AI agents and teams persistent, shared memory using a knowledge graph with vector embeddings, automatic consolidation of related facts, and hybrid search.
Updated 5 months ago (2026-05-15 08:27 UTC)
3
-
Cortex OS
Knowledge & Memory Autonomous Agents
qi-mouren
A
license
Not graded
quality
C
maintenance
MCP server that provides AI agents with persistent memory, cross-agent sharing, and context management, enabling them to remember conversations, track complex tasks, and evolve skills across tools.
Updated 2 months ago (2026-07-31 12:13 UTC)
2
MIT
collective-memory
Knowledge & Memory RAG Systems Search
Hustada
A
license
A
quality
D
maintenance
MCP server for persistent, semantic memory across AI sessions; store context, decisions, and learnings and recall them with natural language search.
Updated 5 months ago (2026-05-29 20:26 UTC)
2
17 npm
MIT

1. Install

2. Tell your human, in one breath

3. Run this loop yourself

4. Don't

Contents

The problem

What it does

The session loop

MCP tools

The nature of memory — 5 layers

How memory compounds

The math

1 · Rank fusion — Reciprocal Rank Fusion 🟢

2 · Forgetting — Ebbinghaus per source 🟢 form · 🟡 constants

3 · Spaced reinforcement — FSRS-lite 🟢 form · 🟡 constants

4 · Salience — what a palace room is worth 🟡

5 · Learning from feedback — Beta–Bernoulli 🟢

6 · Association — ACT-R activation 🟡 (opt-in AGENT_RECALL_ACTIVATION=1)

7 · Paraphrase matching — set cosine 🟡 metric · 🟢 threshold

8 · Promotion — admit, then vote 🟢

9 · Measuring behavior change — heed rate + Wilson interval 🟢

10 · Calibrated confidence 🟡

Open problem 🔴 — does redundancy reconstruct intent?

Measured, not promised

Compared to other memory tools

Install

MCP server — for agents

Skill — Claude Code

SDK — JS/TS apps

CLI — terminal, CI, hooks

Optional extras

Architecture

Platforms

Community

Contributors

Links

Contributing

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

6 · Association — ACT-R activation 🟡 (opt-in `AGENT_RECALL_ACTIVATION=1`)