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.

More notes

Muse Code memory keeps notes. Your decisions need connections.
Muse Code remembers Markdown notes, which suits procedures and quirks. Engineering decisions are links between things, and they change. Jev decides on the state you give it. Give it your team's decisions.
Jev answers typed questions inside an agent loop. Its docs warn about noisy state. A graph of decisions in force is a small, clean state to decide against. Your CLAUDE.md got too long because nothing ever leaves it
Rules files grow when there is no rule for removal. A superseded decision is that rule, and it makes trimming CLAUDE.md routine. Claude Code forgets between sessions, and the fix is not a bigger context
A larger window would replay the transcript. What the next session needs is the decision and the option you turned down, kept as a record. Memory as a file format is a good idea. Mutable files are the flaw.
A memoryfield is a portable, greppable store, and that part is right. The open question is what happens when a page stops being true. Postmortems capture incidents. Who captures the decisions after?
The corrective decision is the postmortem's real output, and it dies in a doc nobody reopens. How to keep it where the next change will look. Tech debt is a list of decisions nobody wrote down
Tech debt without the original why cannot be repaid rationally. Keep each shortcut's reason next to the code in an append-only decision log. Comments explain the line. Nothing explains the system.
Code comments answer why for one line. Nobody writes the comment for a decision that spans twelve files. Where that reasoning should live instead. Turning off Claude Code's auto memory is reasonable. Keep the decisions.
Auto memory saves what the agent noticed, in a capped index. Switching it off is fine. What your team decided still needs somewhere to live. The playbook commits six artifacts. Where does a reversed decision go?
Anthropic's AI-native SDLC playbook commits an artifact per stage. Reversals get edited into intent.md in place. Give them a record of their own. Half your standup is re-announcing decisions
Standup announcements evaporate by lunch. Why team decisions need a record that accumulates, not a broadcast that has to be repeated. The rewrite proposal that comes back every quarter
Some proposals never die because the no was never written down. How a queryable record of rejections ends the quarterly rewrite argument. The wiki was supposed to be the team's memory. It's a graveyard.
Wikis rot because editing them is a chore nothing triggers. Capture at the write boundary has a trigger, and supersession instead of an edit. Two agents in one repo will disagree unless they share a past
Parallel agents edit the same repo from different context, so they contradict each other. A shared decision store gives both the same past. Onboarding an engineer whose AI already knows the codebase's past
A new engineer's AI can read every past decision on day one. What onboarding becomes when the why lives in a log instead of people's heads. Your team's decisions live in Slack. Slack is not memory.
Slack search finds messages, not conclusions. Why dev team decisions need identity and lifecycle, and recall that returns only what still holds.