The last post made a promise: that the interesting thing isn't one engineer's agents sharing a memory, but a whole team's. This is that post, and it's the last beat in the series.
So far every post has been about a single setup. One repo, one person, their agents reading and writing the same why-layer. That's already worth having. But it undersells the design, because the same mechanism that lets your morning agent talk to your afternoon agent lets your agent talk to mine.
The unit of memory is the repo, not the person
Go back to where the memory lives. It's written through to git notes, anchored to commits, travelling inside the repository's own history. Nothing about that is scoped to a user. A note attached to a commit is attached for everyone who has that commit.
So when you fetch, the why comes with the diffs. Not your why specifically: the team's. The decision a colleague's agent recorded on Tuesday is on your agent's first query on Wednesday, because it arrived the same way every other object in the repo arrives. You didn't sync a second system. You did a git fetch, which you were going to do anyway.
This is the quiet payoff of putting memory in git rather than beside it. A memory that lives in a per-user store has to be deliberately shared: invited, granted, replicated. A memory that lives in the repo is shared by default, through the machinery the team already runs. The unit of memory is the repo, and the team already shares the repo.
How one person's convention becomes the default
Here's the part that surprised us in our own use.
When several people's agents draw from the same why-layer, the sharper note wins on its merits. Someone writes down why a retry backs off for exactly that interval, with the incident it traces back to. That note is now the answer every agent gets when it asks. Not because anyone circulated it, not because it went in a wiki nobody opens, but because it's the most specific thing anchored to that commit, and the next query surfaces it.
The good convention spreads by being queried, not by being announced. One engineer who writes careful decisions raises the floor for everyone's agents, including the agents of people who never read the original note. The memory does the distribution. You get the effect of a well-kept team handbook without anyone having to keep a handbook.
The reverse is true too, and it's why this only works with the rule from an earlier post. When a convention changes, the new decision supersedes the old one rather than overwriting it. Across a team that matters more, not less. Two people can hold two versions of the same convention in their heads, and the memory won't quietly pick one. The current answer is the current answer, and the superseded one is still there with its provenance, so "we used to do it the other way, here's what changed" stays answerable for the colleague who wasn't in the room.
Provenance is what makes shared memory trustworthy
Shared memory is only useful if you can trust what comes back. On a team, the obvious worry is: whose decision is this, and is it still the one we follow?
That's what the provenance is for. Every entry carries the commit it's anchored to, so a decision isn't a free-floating assertion. It's tied to a point in the code's history, with a past tense that survives. When your agent answers "why is it this way," it's answering from something a teammate committed against a specific change, not from a guess and not from a note that drifted loose years ago.
So a contradiction between two team members surfaces as a contradiction, at the moment you query, instead of being silently resolved in favour of whoever wrote last. You find out the team disagrees with itself when you ask, not three weeks into a refactor that assumed everyone agreed. That's the same surfacing behaviour a single user gets, except now it's catching the seams between people, which is exactly where shared understanding tends to tear.
Whose store is it, anyway
There's a contrast worth drawing here, and it's the through-line of the whole series.
A team's shared memory has to live somewhere. The common answer, even from the largest vendors with the most credible anti-lock-in story, is some version of "your context lands in our store, and we promise to let you get it out." That can be an honest offer. But the shared memory still belongs to a place that isn't yours, reachable through a surface that isn't yours, trusted as a box you can't fully see into.
Our answer is different in kind, not degree. The team's shared memory lands in the team's own repo. It travels with a clone, works with no account and no network, and the core is open source under a permissive licence. There's a hosted layer for teams who want two-way sync across machines, but the base case is the team's memory on the team's disk, in a format the team already trusts. Shared memory that belongs to the team's repo, not a vendor's store, is the version you don't have to take on faith.
git tracks what changed. Spelunk remembers why. On a team, the why is the part that usually lives in the heads of whoever happened to be there. Putting it in the repo means it belongs to the team the same way the code does, and it stays when people come and go.
Where the series lands
That's the whole arc. We noticed a narrow gap: agents are fluent about what and silent about why. We found where the why could survive, inside git notes with provenance and a supersede rule. We deleted a lot to get the tool to start in the first minute. We refused to let the memory belong to any one agent vendor. And the payoff, the part that made it feel like infrastructure rather than a feature, is this one: when a team's agents all draw from the same memory, the team's best thinking compounds instead of evaporating.
None of it requires predicting which agent wins, or trusting a store you can't see. The memory stays put, in the repo you already share, while the tools and the people come and go.
Spelunk is open source and code-aware, callable from whatever agent you already use. Repo and docs: spelunk.cloud.