How it works

What Renor stores, how a new value replaces an old one, how recall chooses what to return, and what is not built yet.

Renor gives AI tools and agents durable memory so they recall context without being told again. The cycle has three steps:

1. Connect. Add one MCP address to the AI tools you use and sign in once. See the Quickstart.
2. Remember. Your agent saves what should last: a fact, a decision or a note. Nothing is saved unless an agent or you asks for it. Renor does not record your chats.
3. Recall. Before it works, your agent calls get_context and gets the current facts and the closest notes.

Architecture

Agents reach Renor through one MCP address. A gateway checks who you are and passes the call to the process that serves your workspace. That process keeps two things:

• a Markdown store, which is the memory: a facts ledger (subject, predicate, value, history) and notes (your words, filed by day);
• a SQLite index derived from it for search: chunks, keyword search, entities, and vectors where semantic search is on. The index can be deleted and rebuilt from the store.

Each workspace has its own memory directory, its own index and its own server process.

What a memory is

• A fact is a subject, a predicate and a value (Fjord, database, SQLite), saved with the sentence you said. Facts go to an append-only ledger.
• A note is your words, kept whole in a Markdown file under the day it was saved.
• If you import Markdown notes, they are notes too, under Imported/<label>.

How an agent writes

• remember takes a statement in plain words, up to 4,000 characters. A longer one is refused, never cut. On its own it is saved as a note and is searchable at once; a note holding a control character (U+0000 to U+001F except tab, newline and carriage return, or U+007F) is refused and nothing is written.
• With subject, predicate and object as well, it is saved as a fact. Use this only for a value that stays current until it changes: a city, a project’s database, a deadline.
• save_memory is the fact form alone. remember_note appends a timestamped line to a day’s log.
• Saving the same statement for the same fact again changes nothing. A save returns a receipt: store, supersede or nochange, with an event id.
• An optional scope such as project:fjord keeps a memory with one project.

How a new value replaces an old one

Say an agent saves that a project uses PostgreSQL, and later saves that it moved to SQLite. Asked which database the project uses, Renor answers SQLite and keeps PostgreSQL as history, with the dates it was current.

remember   subject Fjord · predicate database · object PostgreSQL
  → action "store"
remember   subject Fjord · predicate database · object SQLite
  → action "supersede"   (closes PostgreSQL, creates SQLite)

get_context("what database does Fjord use?")
  → facts: [ { subject: "Fjord", predicate: "database", object: "SQLite" } ]

retrieve_memory { subject: "Fjord", predicate: "database", include_history: true }
  → SQLite      current: true
    PostgreSQL  current: false, validTo: <when it was replaced>

retrieve_memory with as_of and an ISO date returns what was current at that time.

Replacement happens only when the agent saves the new value with the same subject, predicate and scope, spelled the same way. An agent that records “we moved to SQLite” as a plain note leaves the earlier note in place: Renor does not read the sentence to work out that it contradicts anything. It warns (possibleDuplicates) when it sees the same predicate under a name one word longer or shorter, or in another scope, and changes nothing on its own.

How recall chooses

get_context returns:

• Facts first: the current values of the facts that best match, read from the ledger: up to 12 for a query (20 with no query), within the share of the token budget that facts get. Matches beyond that are left out. A fact saved a moment ago is found by exact words before the index has caught up.
• Then notes, by meaning and by words. The reply’s retrieval field says how they were matched: hybrid (a search by meaning plus a keyword search), semantic (meaning only), keyword (exact words only: semantic search is off, or still being built) or facts (facts only: no query, or no note search could answer).
• A token budget: the whole reply fits max_tokens (800 by default, at most 4,000). When matches do not all fit, keyword matches go first, then the lowest-scoring meaning matches, but the newest relevant match is kept.
• An honest miss: if nothing closely matches, the reply says relevant: false, and the listed items are only the nearest ones.

Renor does not inject anything by itself. Your agent calls get_context, and the host application decides whether and when it does that.

Embeddings are computed by Google Vertex AI (gemini-embedding-001, 768 dimensions): the workspace sends it the text of notes when they are indexed and the query when it searches. Retrieval also follows the [[wikilinks]] you write between notes: a note linked from a match can be added as a further match (its reason is graph). Renor does not build a knowledge graph from your text.

Retire and restore

retire_memory takes one memory out of recall without deleting it. restore_memory puts it back exactly as it was. A wrong fact is corrected by saving the right value, not by retiring. Retiring is reversible by design, so it is not erasure. The owner can then delete a retired note or log entry permanently on the dashboard’s Memories page, which cannot be undone and frees a retired note’s storage; agents cannot. A retired log entry already stopped counting toward storage when it was retired. A retired fact stays in the ledger; see Security for erasing one or an account.

Several agents, one workspace

A workspace belongs to one owner account. Every MCP client that account signs in reads and writes the same memory. Each memory records a source, the name of the app or agent that saved it. A named connection’s author is authenticated; only an unnamed fallback label is self-reported. scope separates projects inside a workspace, but it is a folder, not a permission: a read without a scope sees every scope.

When the workspace is unreachable

An idle workspace stops, and the gateway starts it again on its next call, which takes a few seconds (on-demand sleep is on in production). If it cannot be started, the call fails with a 503 and a Retry-After header. In every such case the call fails and nothing is written: Renor does not queue a write for later. An agent should treat a failed Renor call as “no memory this time”, not as “nothing relevant”.

Speed

One measurement, taken on 2026-10-06 from one network location: a hosted get_context took about 430 to 500 ms at the median. The engine’s own work was about 20 ms of that, measured separately on a test workspace shaped like a live one (87 notes, 1,845 chunks and 994 fact rows); the rest was network, one account lookup and, for a new query, the embedding call. It was one day, one place and a load that was not quiet, so read the milliseconds as rough. Renor publishes no latency guarantee.

What Renor does not do today

• Self-hosting runs the engine alone. The engine is open source under AGPL-3.0 at https://github.com/patrickpassosb/renor-engine; the website, dashboard, sign-up and operations come only with the hosted service.
• It does not record your conversations.
• It does not notice that a plain note contradicts another note.
• It has no per-agent permissions and no sharing of one memory between people.
• Its only self-serve permanent deletion is of retired notes and log entries, on the dashboard; a retired fact or a whole account is erased by email to [e-mail].
• It documents no REST API for memory; MCP is the interface.
• It has no independent audit or published uptime figure.