Skip to content
Fredrin
Documentation

Project memory

Project memory

Your agents forget everything between sessions. Fredrin's answer is not a bigger context window, it is putting the knowledge in your repository where it belongs.

The problem

Every AI coding session starts from zero. You re-explain the architecture, re-explain why the obvious approach does not work here, re-explain the convention that is not written down anywhere. Then the session ends and all of it evaporates.

The usual fix is to stuff more into a prompt. That does not compound: it is the same explanation, retyped, forever.

Files are canonical

Fredrin's project memory lives in your repository, as plain markdown, versioned in git alongside the code it describes.

Two shapes, because they answer different questions:

A concept wiki answers how does this work now. One file per concept, small and atomic, edited in place. Git is its history, so the file always describes the present.

A decision log answers why did we do it this way. Append-only: one new file per decision, never rewritten. When a decision is reversed, the new record says so and names what it replaces.

The two cross-link, so a concept points at the decisions that shaped it and a decision points at the concepts it changed.

Why files rather than a database

Three reasons, and they all matter.

Your agents can already read files. No integration, no plugin, no API. A Worker in a worktree reads markdown the same way it reads source.

It is versioned with the code. A decision and the change it justifies land in the same pull request, so knowledge cannot drift away from the thing it describes.

It is yours. Delete Fredrin tomorrow and your project memory is still sitting in your repository, readable by any tool.

Fredrin mirrors these files so it can search and relate them. It never injects them at runtime and never holds the only copy.

Relevance-scoped retrieval

Reading everything is not the goal. A repository with two hundred concept docs would drown a Worker in context that has nothing to do with its ticket.

Before a Worker starts, Fredrin resolves the slice that actually touches its ticket, the specific concepts and decisions involved, and points the Worker at those. The alternative, reading the last N documents by date, gets less useful as the repository gets larger. This gets more useful.

Knowledge ships with the code

The loop closes on the way out. When a Worker learns something durable while building a ticket, it proposes that back into project memory as part of its own pull request, in separate commits so you can ship code and context independently.

You review it like any other change. Accepted, it is there for every Worker after it.

That is what compounding looks like in practice: the tenth ticket in a repository genuinely starts smarter than the first, and nobody had to run a documentation sprint.

Next steps