How Fredrin memory works

One agent forgets everything between sessions. Ten agents running in parallel forget in ten directions, and each fills the gap with its own guess.

You find out in review, one diff at a time. Shared memory is how parallel work stays consistent: the same words, the same settled decisions and the same known traps, in front of every run before it writes a line.

Memory is a folder of plain markdown, versioned with your code. There is no separate knowledge service to run, sync or back up.

Fredrin adopts what you already have. An existing CONTEXT.md, AGENTS.md or docs/ bundle is read where it is. A new project gets .fredrin/memory/.

Nothing is copied into Fredrin's database. Stop using Fredrin and your memory is still in git, with its full history, readable by any agent or person.

Each ticket runs in its own branch and worktree. Before it writes code, the Worker reads the slice of memory that matches the ticket.

If the work changes how something behaves, the Worker updates the concept doc in the same pull request. A choice that is expensive to undo gets a new decision record.

You review memory the way you review code: in the diff. Once it merges, the next ticket starts from it.

The top five pointers ride on the ticket itself, for about 200 tokens, so every run sees them. The full pack is one command away.

All of it runs inside the ticket's worktree, on whichever machine runs the Worker. The docs are read straight from git; only the ticket's own text comes over the network.

Decisions get reversed. The old record still uses the words people search with, so a plain search keeps serving it as if it were current.

Fredrin never starts a pack from a superseded, deprecated or rejected decision. A match on one is credited to the decision that replaced it, so a ticket written in yesterday's words lands on today's call.

The old record can still appear, labelled historical. And nothing decays with age: an old decision that still holds keeps its full weight.

Every run leaves a free relevance label: the memory files the Worker actually opened. Fredrin compares them with what it served.

Files that were read but not served are the useful signal. Each one points at a link or a synonym the docs are probably missing.

An offline benchmark needs no run history. Each decision's own links are the answer key, and the decision is held out while its prose is used as the query.

On Fredrin's own repository (2,207 docs, September 2026), the pack recovers 87% of the live docs a decision cites, and the first relevant doc usually ranks first (MRR 0.845).

The Memory tab rolls this into one health score and names the single biggest fix. When the docs drift, one click files a cleanup ticket that merges near-duplicate decisions. It is told to consolidate, never delete, and you review it like any pull request.

The files are the easy part. What turns them into memory is everything around them:

• A ranking engine that understands supersession and stays inside a token budget.
• Checks wired into dispatch, the edit, and the finish.
• A write-back path that goes through code review, not around it.
• A scorecard that tells you when recall slips, and a cleanup pass for when it does.

Each piece is small. Together they are a system your team would have to own, tune and keep working while it ships product. With Fredrin it is there from the first ticket, and it stays plain files if you ever leave.