TL;DR: Most AI agent memory discussions still assume one agent talking to itself across sessions. But real coding workflows already involve Claude, Codex, Cursor, and Gemini touching the same repo in the same week. The hard problem is not "how does an agent remember." It is "how do multiple agents stay coordinated on the same project without stepping on each other." That problem does not live inside any one agent. It lives in the repo.

---

I wrote a post last week arguing that AI coding agent memory belongs in the repository, not the chat window. Checkpoints, not transcripts.

Sitting with that argument for a few days, I realized it is actually downstream of a bigger one I had not made explicitly yet. The checkpoint primitive only matters because of a problem the current agent stack does not have a name for.

So here it is.

The Industry Map Has A Blind Spot

There is a really good 2026 agent stack map going around right now from Paolo Perrone. Six layers. Models, protocols, memory, frameworks, eval, guardrails. It is a useful map.

But read the memory layer carefully and you notice something.

Every memory tier on that map assumes one agent.

• In-context state lives inside one agent's context window
• Vector retrieval lives inside one agent's RAG pipeline
• Persistent memory services like Letta, Zep, and Mem0 are designed for one agent learning across sessions

That is a real problem and worth solving. But it is not the problem most coding workflows actually have.

Most Coding Workflows Already Use Multiple Agents

Look at how anyone serious is shipping code right now.

Claude for architecture and review.
Codex for implementation.
Cursor for inline iteration.
Gemini for exploration.
A human approving and editing all of it.

That is not a future scenario. That is a Tuesday.

And every single one of those agents has its own context window, its own session, its own memory, its own opinions about the codebase. None of them know what the other ones did an hour ago.

The continuity problem is not "Claude forgot what we discussed yesterday."

The continuity problem is "Claude does not know what Codex implemented this morning, Cursor reverted half of it at lunch, and the human merged something different from a different branch."

That is a coordination problem dressed up as a memory problem.

Agent-to-Agent Memory Does Not Exist Yet

Perrone's map notes this honestly. MCP standardized how agents call tools. It says nothing about how agents talk to each other. IBM has ACP. Google has A2A. Neither is a standard. Neither is widely adopted. Neither solves the coding workflow case.

So in practice, every team running a multi-agent coding workflow is solving this themselves. Usually badly. Usually by re-explaining context to every new session by hand.

The dedicated memory vendors do not solve this either, because they are designed to give one agent a longer memory. Plugging Cursor and Claude Code into the same Mem0 instance and hoping they coordinate is not a thing that works today.

Memory infrastructure is single-agent infrastructure. The multi-agent coordination layer is missing.

The Repo Is The Only Shared Surface

Here is the thing that kept hitting me.

When Claude, Codex, Cursor, and Gemini are all working on the same project, there is exactly one piece of infrastructure all of them already see.

The repository.

They all read it. They all write to it. They all already have file system access through MCP or equivalent. Git already tracks who changed what and when.

The repo is the shared substrate. It is the only shared substrate. Everything else is per-agent.

So if you want continuity across agents, the continuity artifacts have to live in the repo. Not in a vector database that one agent is plugged into. Not in a hosted memory service that another agent does not know about. In the repo. In files. Versioned. Auditable. Diffable. Visible to every agent that can read the file system.

That is what makes checkpoints the right primitive. Not because vector search is bad. Vector search is great for what it does. But you cannot retrieve from a vector store that the next agent has never heard of.

The Reframe

When you stop framing the problem as "agent memory" and start framing it as "multi-agent coordination on a shared artifact," a lot of the tooling debates collapse.

• Bigger context windows do not help. The next agent has a different context window.
• Better RAG does not help. The next agent has a different RAG pipeline, or no RAG at all.
• Hosted memory services do not help unless every agent in your workflow is plugged into the same one, which they are not.
• Transcripts do not help, because they are noise and the next agent does not have your transcript.

What does help is a small, structured, versioned record of what was decided, what is in progress, what is at risk, and what the next agent should pick up. Sitting in the repo. Where everyone can see it.

That is the continuity primitive the current stack map does not have a slot for.

What I Am Building

Holistic is an open source CLI exploring this idea. Repo-native checkpoints. Agent-agnostic. No vendor account, no hosted service, no per-agent SDK. Just files in your repo that any agent can read and any agent can update.

It is still early. The thesis is what I am most interested in pressure testing right now.

If you are running a multi-agent coding workflow and you have your own answer to the coordination problem, I want to hear it. If you think I am wrong about the repo being the right substrate, I really want to hear that.

Repo: https://github.com/lweiss01/holistic

The repo remembers, not the window. And no single agent remembers for the others.