Notes for dev teams that share an AI

Sharing what the team learns

How AI dev teams share what they learn, without a memory server
How AI dev teams share decision memory over an S3 bucket they own. Per-writer shards, no server or daemon, the whole graph local on every machine. Your teammate's AI solved this yesterday. Yours is solving it again today.
AI dev teams pay for the same discovery twice. A shared append-only decision log lets the second agent read what the first already worked out. The new dev asked why we skipped Elasticsearch. Nobody remembered.
Onboarding runs on tribal knowledge. A decision history that keeps the dead ends means a new dev's agent knows why Elasticsearch was rejected. When a senior leaves, 'we tried that in March' leaves with them
Tribal knowledge leaves with people. Keep 'we tried that in March' in an immutable decision log instead of a senior engineer's head. git blame tells you what changed. Nothing tells you why.
git blame records what changed and who changed it. A decision log records why, plus the alternatives that were rejected. They work together. Half of every code review is re-explaining old decisions
Reviewers keep re-explaining old decisions to AI-written PRs. Recall before the agent edits means the PR arrives already knowing them. "Wait, I thought we agreed: decision drift between docs and reality"
Docs describe what a team believed at writing time. Decisions keep moving. Explicit supersession keeps agents reading what's in force.

AI assistants on a team

"Claude Code forgets everything between sessions. Your team shouldn't."
"Claude Code keeps your files and CLAUDE.md between sessions, not the reasoning. What actually persists, and how a team decision log holds the why." "Your AI keeps proposing the database your team rejected in March"
"Why AI agents re-propose approaches your team already rejected, and how recording dead ends with their reasons stops the loop." "My CLAUDE.md is 1,000 lines and nobody knows which rules still matter"
"Rules files grow because rules carry no date, author, or reason. How a decision log with supersession makes a long CLAUDE.md prunable again." "Five devs, five agents, five versions of the truth"
"Per-machine agent memory drifts apart. A shared decision store gives every machine the same graph and the same recall, no LLM in the read path." "Repeal needs a record: why your team's rules files only grow"
"Deleting a rule is amnesia. Retiring a decision is an event with a reason. How supersession chains keep team rules from ratcheting forever."

Choosing a tool

claude-mem alternatives for dev teams, and when to keep claude-mem
What claude-mem does well, when a team needs shared decision memory instead, and how the alternatives differ. An honest guide, not a takedown. ADR files vs a decision graph. You probably want both.
ADRs stay the human-readable record your team edits. A decision graph is the machine-readable companion your AI reads at edit time. How they fit together. Do you need a vector database to share team knowledge? No.
Engineering decisions are a small, structured corpus. Lexical search plus graph traversal beats similarity ranking there. Where vectors do make sense. "kgai vs claude-mem: session recall and decision memory are different jobs"
"claude-mem compresses Claude Code sessions so the next one starts informed. kgai keeps a team's decisions. An honest look at where each fits." "kgai vs Mem0: user memory and decision memory solve different problems"
"Mem0 gives assistants memory of their users. kgai gives dev teams memory of their decisions. A fair comparison of two tools that barely overlap." "kgai vs Graphiti: two ways to build a graph that keeps its history"
"Graphiti extracts a temporal knowledge graph from your data with an LLM. kgai records explicit decisions into an immutable log. Where each one fits." "kgai vs Cognee: documents distilled, or decisions recorded"
"Cognee turns your documents into a knowledge graph with an LLM pipeline. kgai records decisions as they're made. An honest comparison for dev teams." "kgai vs Zep: a managed context platform and a local-first decision log"
"Zep is hosted agent memory built on a temporal knowledge graph. kgai is a local decision log your team owns. Which fits depends on whose memory it is." "kgai vs Letta: evolving agent state or an append-only decision record"
"Letta builds stateful agents that edit their own memory. kgai keeps an append-only record of a dev team's decisions. Which you need depends on the job." "kgai vs LangMem: memory for your product's agents or for your dev team"
"LangMem adds memory to LangGraph agents with LLM extraction and consolidation. kgai records a dev team's decisions in an append-only log." "kgai vs mempalace: verbatim transcripts or a decision log"
"mempalace keeps verbatim conversation history with semantic search. kgai keeps an append-only log of team decisions. A different unit of memory." "kgai vs engram: two local-first memories with different units"
"engram and kgai are both local-first memory for AI coding agents with nothing to run. The split is the unit of memory and who owns the team sync." "kgai vs beads: the work queue and the why are different records"
"beads gives coding agents a dependency-aware task tracker. kgai records why the work went the way it did. Two halves of one problem, compared honestly."

Decision memory in practice

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. Dead ends are documentation. Keep the paths your team rejected.
The options that lost are the most useful engineering history. Why rejected decisions belong in a queryable record, struck through but never deleted. "Scoping shared memory: per repo, per node, per teammate"
How kgai scopes team decision memory, and an honest note on what scoping is. Filtering for relevance, not access enforcement. No permissions theater. What a million team decisions taught us about memory at scale
kgai at 1,000,000 decisions across 30 writers. Decision lookups hold at about 100 ms, recall and free-text search are slower. Method in the repo.