Glen is a semantic git: tracing code back to the conversation that wrote it

Git is the best memory system software engineering has. It records every change to every line, who made it, when, and in what order, and it never forgets any of it. What it records badly is why. The why lives in a commit message, and most commit messages are written in four seconds by someone who wants to push.

That used to be an acceptable loss, because the why mostly lived in the head of the person who wrote the code, and you could go ask them. When an agent writes the code, the why is no longer in anyone's head. It sits in a session transcript: the prompt, the three approaches the agent tried, the test that failed, the teammate's Slack message it was told about, the moment the developer said "no, keep the old interface". All of that reasoning existed, in full, for about an hour. Then the session closed and git kept the diff.

Glen keeps the rest. We call it a semantic git: the same idea of an append-only, attributable history, applied to what the code means instead of what the lines are.

What git can't answer

Run git blame on a confusing block and you get a SHA, a name and a date. Run git show on that SHA and you get a message like fix webhook retries and a diff. If you're lucky, the PR has a description. You still don't know:

• Why it retries five times and not three
• Whether the queue was considered and rejected, or never considered
• What the person was told that made them write it this way
• Whether this is the intended design or a point-fix that passed the test in front of it

Those are the questions you actually have when you're about to change the code. A human engineer answers them by finding the author. An agent answers them by guessing, then reading the surrounding files to make the guess look grounded.

The link: commit to conversation

Glen records every agent session your team runs through its plugins for Claude Code, Codex, Cursor and the rest. That gives us the transcripts. The part that turns a pile of transcripts into something like git is the link between a commit and the session that produced it. Glen writes that link two ways, so either one surviving is enough.

A commit trailer. Running glen install inside a repository adds a prepare-commit-msg git hook, and your existing hook still runs first. When a commit is made from a directory with an active Glen session, the hook appends a trailer with git interpret-trailers:

fix webhook retries

Glen-Conversation: 7f3c2a9e-...

The trailer travels with the commit. It survives a push, a fork, a cherry-pick, and a rebase that keeps messages, because it's part of the commit object, the same way Co-Authored-By is.

A commit anchor. When the agent itself runs git commit, the plugin's post-tool hook reads the new HEAD and records an anchor on the server: the SHA, the repository's remote URL, the branch, and the conversation id. That covers commits whose messages get rewritten later, and it's what lets a pull request find its sessions by branch.

Neither link is written in private mode. An off-the-record session doesn't get a trailer or an anchor, so nothing in git points at a conversation that was never stored.

glen code-search: blame for reasoning

With the link in place, walking from a line of code back to its reasoning is a short pipeline. You, or more often your agent, run:

glen code-search src/billing/webhooks.ts:40-85 "why does this retry five times instead of using the queue"

1. Blame the range. The CLI runs git blame -w -M -C --porcelain -L 40,85 on the file. The flags matter: -w ignores whitespace changes, and -M -C follow lines that were moved within a file or copied from another one. A refactor that moved the function into a new module doesn't break the trail back to the session that wrote the logic.
2. Collect the commits. It keeps the distinct SHAs, drops the all-zero SHA git uses for uncommitted lines, and reads each commit's Glen-Conversation trailer.
3. Resolve to conversations. The server matches the SHAs against commit anchors for that repository in your organization, adds the trailer ids, and resolves both to stored sessions. Nothing crosses organizations: a SHA in a public fork resolves to nothing unless your org recorded it.
4. Rank by your question. If several sessions touched those lines, the server ranks them against the question you asked and returns the most relevant first, up to ten.
5. Return the reasoning. Your agent gets the transcripts behind those commits, within a 12,000-character budget, with the ranked titles on top. If no session is linked, it gets no_anchor and knows the reasoning was never recorded, instead of being handed something that sounds plausible.

The agent then reads the actual conversation where the decision was made. It's the closest thing to asking the agent that wrote the code, because it's that agent's own context: the prompt it was given, what it tried, and what the developer told it.

Why line-level beats keyword search for this

Glen also has an org-wide search, glen search, and for "how do we handle webhooks" that's the right tool. It searches everything your team recorded and returns one synthesized answer with a source on every claim.

For "why is this code like this", keyword search is the wrong shape. The question is anchored to specific lines, and the right evidence is defined by provenance, not by similarity: the sessions that produced those lines, and only those. A semantic search for "webhook retries" returns every conversation that mentioned retries, including the three that were about a different service. Blame returns the one that wrote line 52.

That's the whole idea behind calling it a semantic git. Git's strength is that its history is exact: a line has one commit, and that commit has one parent. Glen keeps that exactness and attaches meaning to it.

Where the analogy holds, and where it stops

The last row is where the analogy stops. Git gives everyone with read access the same history. Glen applies access control per observation at recall time, so an agent only gets what its user can already see. A decision made in a private Slack channel never reaches an agent whose user isn't in it.

The other place it stops is merges. Git merges text; it doesn't know two commits disagree unless they touch the same lines. Glen reconciles meaning: if a session in March decided billing webhooks go through a queue, and a session in June reversed it, the June decision is the one your agent hears about, even though the two sessions never touched the same file.

What the PR reviewer gets from this

The same link runs Glen's PR reviewer. When it reviews a pull request, it finds the sessions behind the PR's commits by anchor and by branch, and reviews the diff against what the author's agent was asked to do and what it decided along the way. A reviewer that knows the intent can tell the difference between "this is wrong" and "this is what was asked for, and what was asked for is wrong", which is the review comment people actually want.

Try it on your own repo

Install Glen, work as usual for a day, then point your agent at a block it wrote yesterday:

npx @tryglen/cli@latest install

glen code-search path/to/file.ts:10-40 "why was it written this way"

Run the install from inside the repository so the commit hook goes in. Commits made from then on carry the link; older commits return no_anchor, because no session was recorded for them. Your first 15,000 memories are free.

Start free · Read the MCP docs