Skip to content

What is Institutional Memory?

Last updated

Institutional memory in code review is the accumulated knowledge of a codebase's past decisions, incidents, patterns, and architectural constraints, kept so that later reviews can apply it. Without it, a review has only the diff and whatever the reviewer remembers.

Why does institutional memory matter for engineering teams?

When a senior engineer leaves, their knowledge of why certain patterns exist, what failed in production, and where the architecture is fragile leaves with them. Institutional memory captures this knowledge in a form that future reviews can use.

How does Argus handle institutional memory?

After each review, Argus writes its critical and warning findings (and suggestions scored 70 or higher), patterns learned from high-scoring findings, per-file summaries, and a PR summary into Postgres-backed memory with embeddings. Each later file review gets a memory briefing in its prompt: the file's stored summary, repo and org-wide patterns, org rules, and past false positives marked 'do not re-flag'. When someone with write access dismisses a finding with a 馃憥 reaction, or with a reply the model classifies as a dismissal, a later finding at 0.80 similarity or higher is dropped and one at 0.75 or higher is downgraded a level; security findings are only downgraded. Memory needs an embeddings provider you configure to do any of this; the default, Voyage's voyage-4 at 1,024 dimensions, needs a key (EMBEDDINGS_API_KEY on the backend, or the dashboard's Memory embeddings card).

Run Argus on your own repositories

Open source under AGPL-3.0, with no paid tier and no feature gating.

Self-hosted only: Docker Compose or Fly.io, Postgres with pgvector, a GitHub App and a Clerk app you create, your model keys and an embeddings endpoint.