# What is decision memory for dev teams

*Decision memory defined. What changed, why, what was rejected, who decided, what it supersedes. How it differs from conversation memory and RAG.*

Ask an AI agent why a service retries on a fixed schedule and it will guess. Someone on the team decided it, for a reason, but the reason isn't anywhere the agent can read. Decision memory is the fix for that gap, and it's worth defining precisely.

## The definition

Decision memory is a durable, shared record of the engineering decisions behind a codebase. One decision records five things. What changed. Why it changed. What was rejected. Who decided. What it supersedes. The record is kept for the whole team, humans and AI agents alike, read before code is changed and written after.

The unit is the point. Not a chat transcript, not a document chunk. A decision.

## How it differs from conversation memory

Conversation memory remembers what was said. It's scoped to a person or a session, and it's the right tool for continuity, an assistant that knows your preferences and picks up where you left off. But a team's decisions are made across many sessions by many people, and what was said is not what was decided. Conversation memory has no notion of a decision being superseded, no record of the alternative that lost, and no shared store the whole team reads. It answers "what happened in my sessions," not "what is in force for this codebase."

## How it differs from RAG

RAG retrieves document chunks by similarity and hands them to the model as context. It answers "what text is roughly about this," which is the right question for large unstructured corpora. Decision memory answers "what is currently decided about this, and why." That needs structure a chunk doesn't have, a supersession chain, a rejected-alternatives field, a link to the element it governs. The two coexist fine. They index different things.

## How kgai implements it

kgai, which we build, implements decision memory as an append-only, immutable decision log projected deterministically into a small graph, so every machine replays the same record to the same result. Capture happens at the write boundary through a skill and hooks while the agent works. Supersession is an explicit link with a reason, dead ends stay queryable, and recall, lexical matching plus graph traversal with no embeddings in the read path, returns only decisions still in force. No daemon, no server. Sync is opt-in over an S3 bucket you own. MIT, a Claude Code plugin plus a standalone kg CLI.

Without a record like this, teams get [decision drift](https://kgai.dev/blog/decision-drift), and the archaeology lands on whoever asks [why the code is like this](https://kgai.dev/blog/git-blame-why).

If your team's why still lives in heads and old threads, decision memory is the missing layer. Install it once and the record starts building itself.

## Try kgai

Two commands, MIT, nothing leaves your machine until you configure a bucket:

```
claude plugin marketplace add kgaidev/kgai
claude plugin install kgai@kgai-marketplace
```

Source: https://github.com/kgaidev/kgai
See how kgai compares to other tools: https://kgai.dev/compare
All notes: https://kgai.dev/blog/

---

Canonical: https://kgai.dev/blog/what-is-decision-memory · Written by kgai maintainers · kgai is MIT open source