Governed memory for AI coding agents

An AI coding agent is stateless. Every session begins without memory of prior sessions, and because the model is fed its working context anew on each step, a substantial fraction of everything it processes is context it — or a colleague's agent — has processed before. Independent cost analyses across engineering teams have found that re-sent and re-explored context accounts for roughly half or more of total agentic token spend. The effect compounds along three axes: across sessions (today's agent re-derives what yesterday's learned), across developers (each person's agent re-learns the same architecture independently), and across tools (switching from one assistant to another resets accumulated context to zero).

The consequences are not only monetary. As an agent's context window fills with re-established background, output quality degrades — a well-documented failure mode. And at the team level, the deeper loss is that nothing accumulates: an agent that painfully works out why a service uses a custom retry wrapper discards that understanding at session end, and the next developer's agent — sometimes the same afternoon — reconstructs it, or worse, gets it wrong. Teams attempt to counter this with hand-maintained instruction files, but these are static, drift out of date, differ between tools, and capture none of what agents actually learn while working.

We call the cumulative cost of this repeated re-establishment the amnesia tax. It is paid continuously, by every developer, in every tool, on every session.

The mechanical response — give agents persistent memory — is now well-trodden. Numerous tools capture session context and recall it later, many of them cross-tool, several with strong retrieval benchmarks. Persistent cross-tool memory is, as of this writing, effectively a commodity.

Commoditizing capture-and-recall exposes the two problems it does not solve, both of which sharpen precisely at team scale:

The trust gap. The prevailing design captures memory silently and writes it to a proprietary local or cloud database. This is convenient and invisible — and that is exactly the problem for a team. Silent, unreviewed memory cannot be audited (who approved this? when? on what basis?), cannot be diffed (how did our shared understanding change this week?), and cannot easily be taken elsewhere (the knowledge is locked in someone else's store). Most seriously, an incorrect or malicious memory silently becomes an instruction to every agent on the team — a shared memory is a shared attack surface, and an unreviewed one is an ungoverned one. Engineering organizations govern their code with rigorous review and their AI's memory with nothing.

The legibility gap. Vendor dashboards report activity — lines accepted, active users, requests made. None of this answers the question a staff engineer or engineering leader actually asks: are my engineers using AI well, and how do I make the whole team as good as our best one? Effectiveness is invisible. Which practices ship better code? Where is AI-generated code being reviewed carefully versus rubber-stamped? What does the best AI-augmented engineer do differently, and how is it propagated? No memory tool answers this, and the engineering-intelligence platforms that attempt to measure AI impact do so from the outside — correlating repository and ticket metadata — without visibility into the session itself.

These two gaps, not capture-and-recall, are the problems worth solving.

TeamBrain is built on five principles, each a direct response to the analysis above.

1. Git is the source of truth. The team's memory is a set of human-readable markdown files in a repository — not rows in a database mediated by a service. This single decision yields portability (a git clone is a complete export), auditability (git history is the audit trail), and diffability (changes to shared understanding are ordinary diffs) for free.

2. Human-approved writes only. No process writes to the shared memory without a pull request. Automation proposes; humans merge. Governance is not a bolted-on review UI — it is the pull-request workflow the team already trusts for code, applied unchanged to the team's machine-generated knowledge.

3. Metadata by default, never content. Capture records the shape of work — which files were touched, whether commands succeeded, how many retries occurred, how a session ended — not raw prompts or file contents. Redaction runs on-device before anything is stored. Privacy is an architectural property, not a policy promise.

4. Vendor-neutral by construction. Memory is served to agents over the Model Context Protocol, an open standard. Claude Code, Cursor, and Codex read from the same memory through the same interface; a new tool works the day it ships. No agent is privileged by design.

5. Portable, always. Because the memory is plain markdown in the customer's repository, leaving is trivial — which is precisely why teams can adopt without fear. Portability is a feature, not a leak.

TeamBrain has four parts, and one loop that connects them.

The brain. A directory in the repository holds the team's memory as markdown files across four classes: decisions (why the team chose an approach), conventions (rules agents must or should follow), map (how the codebase is structured), and learnings (gotchas and workarounds distilled from real sessions). Each memory is a small file with structured front-matter recording its class, scope, status, and — for machine-proposed memories — the evidence behind it.

The server. A local process serves the memory to any agent over the Model Context Protocol. Retrieval is hybrid — lexical and semantic — runs against a local index, and works offline; reading memory requires no external API call. At session start, an agent receives the required rules plus the memories most relevant to the work at hand, within a bounded token budget.

Capture. Lightweight hooks record what sessions do, as metadata, redacted on-device. Nothing about a session leaves the developer's machine except through the two governed channels below.

The distiller and the gate. On a schedule, a job reads recent session metadata and merged changes, identifies patterns worth remembering (a gotcha hit repeatedly across sessions; a question agents keep asking with no good answer), and proposes new memories — as a pull request, with evidence attached and conflicts against existing memories flagged. A human reviews and merges, exactly as they would a code change. Once merged, the memory is served to every agent, in every tool, on the next session.

The loop, end to end: a session happens → hooks capture its shape → the distiller proposes a memory → a human approves it in a pull request → every agent on the team knows it next session, in any tool. The differentiating step is not the capture — many tools capture — it is that the approval is an ordinary pull request in the repository the team already governs.

Distilled memory captures judgment — the decisions and gotchas worth a human's review. It does not, and should not, capture the mechanical structure of the codebase itself. Yet re-deriving that structure is a large part of the amnesia tax: an agent starting fresh greps, opens files, and traces call paths to answer "where does X live?" and "what calls Y?" — questions whose answers already exist in the source.

CodeMap addresses this directly. It is a machine-generated, always-current map of the codebase — per-module and per-file summaries plus their relationships — built incrementally in continuous integration. On each merge, only the files that changed are re-summarized; the rest are reused. An agent then asks a structural question and receives a compact answer drawn from the map, rather than re-exploring the repository from scratch — a roughly two-hundred-token answer in place of a forty-thousand-token exploration.

Two design choices keep CodeMap coherent with the rest of the system. First, it is served through the same protocol tools agents already use — it adds no new interface. Second, because a code map is a derived artifact — regenerable from source at any commit — it is indexed directly rather than routed through pull-request approval. The governance gate applies to human knowledge, where judgment is involved; it would be pure friction applied to a mechanical restatement of code that already exists in the repository. Governance is reserved for the things that warrant it.

The same metadata that lets TeamBrain distill memory also, in aggregate, answers the leadership question no current tool addresses: is our AI use actually working? FlightDeck is the layer that turns session metadata and engineering outcomes into an honest read on AI effectiveness — which practices correlate with better-reviewed, lower-rework code; where AI-heavy changes are receiving shallow review; what the most effective engineers do differently and how to spread it.

FlightDeck is built on three commitments that follow from the principles above. It is consented — the data exists only because developers installed TeamBrain for their own benefit. It is aggregate — there are no individual scorecards or leaderboards, by construction; the code path that produces leadership views cannot group by person. And it is metadata-based — it derives insight from the shape of work and its outcomes, not from the content of prompts or code, preserving the privacy stance that makes the whole system trustworthy. The goal is enablement, not surveillance: to help a team get better at using AI, not to watch its members.

A shared memory that feeds every agent is a security-sensitive artifact, and TeamBrain treats it as one. Retrieved memories are presented to agents as clearly delimited data, not as instructions, and proposed memories are screened for injection patterns before a human ever reviews them — but the primary defense is the human gate itself: nothing enters the shared memory without review. Capture is metadata-only by default, with on-device redaction of secrets and sensitive tokens screened against a public, continuously-tested corpus. There is no phone-home: the only outbound channels are the team's own git remote, the team's own model provider (used solely by the distiller, with the team's own key), and the team's own notification webhook. And because everything durable is a file in the team's repository, the team can inspect, modify, or leave with the entire system at any time.

AI coding agents made individual developers faster and, in doing so, revealed a gap they cannot close on their own: engineering is a team activity, and team knowledge must be shared, trusted, and legible. The industry has largely solved the mechanical half of this — agents can now remember. The unsolved half is governance: memory a team can review, own, and carry with it, and a view of AI effectiveness that leaders can actually act on. TeamBrain's wager is that the right place for a team's AI memory is the same place its code already lives — in the repository, under review — and that the same foundation, honestly instrumented, can finally tell a team not just that it uses AI, but whether it uses AI well.