DEV Community: lweiss01

The Agent-to-Agent Continuity Gap Nobody Is Talking About

lweiss01 — Wed, 27 May 2026 13:55:44 +0000

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.

Checkpoints, Not Transcripts: Rethinking AI Coding Agent Memory

lweiss01 — Sun, 24 May 2026 18:40:21 +0000

TL;DR: AI coding agent memory should live in the repository, not the chat window. Bigger context windows and vector databases are solving the wrong problem. Here is the case for treating the repo itself as the durable cognitive surface.

Everyone is trying to solve AI agent memory right now.

Longer context windows.
Vector databases.
Conversation replay.
Semantic retrieval.
Infinite transcripts.

But after spending months building workflows across Claude, Codex, Gemini, Cursor, and other coding agents, I've started to think we may be treating the wrong thing as the source of truth.

The problem is not:

"How do we make the model remember everything forever?"

The problem is:

"How does a software project remain cognitively coherent across sessions, compaction, agent switches, and time?"

Those are very different problems.

The Context Window Is Not Durable Infrastructure

Modern AI coding workflows are surprisingly fragile.

An agent works for hours. The context window fills up. Compaction happens. Then suddenly:

architectural reasoning disappears
unresolved work gets forgotten
regressions come back
agents undo each other
humans re-explain the same context repeatedly

The industry response so far has mostly been: store more. Bigger context windows, vector databases, hosted memory services, semantic retrieval over giant transcripts.

But transcripts are not understanding.

And replaying giant chat histories is not the same thing as preserving operational continuity.

In practice, most coding workflows do not fail because information disappeared entirely. They fail because the important state was never extracted from the conversation in the first place.

Checkpoints, Not Transcripts

The idea I have been exploring is pretty simple:

Instead of preserving entire conversations forever, preserve structured checkpoints at meaningful moments.

Not:

every token
every thought
every conversational detour

But the things that actually matter:

current state
architectural decisions
unresolved threads
regression risks
next recommended actions
implementation reasoning
handoff context

The checkpoint becomes the durable source of truth.

The live context window becomes disposable working memory.

That distinction changes a lot.

The Repo Should Remember

One realization that kept hitting me while working across multiple coding agents:

The repository itself is the only thing that actually persists.

Agents change.
Models change.
Sessions end.
Windows compact.

But the repo stays.

So instead of treating continuity as something trapped inside a chat session, I started treating continuity as a repo-native concern.

That means:

continuity artifacts live in the repo
handoffs live in the repo
operational state lives in the repo
regression memory lives in the repo
checkpoints live in the repo

The repo remembers, not the window.

Multi-Agent Development Is Already Here

A lot of tooling still assumes:

one human, one agent, one session.

That is not how many people are actually working anymore.

Real workflows increasingly look like:

Claude for architecture
Codex for implementation
Cursor for iteration
Gemini for exploration
a human reviewing all of it
another session tomorrow continuing the work

Continuity is no longer just memory. It is coordination across interchangeable execution surfaces. And once you frame it that way, the chat window stops looking like the right place to store anything important.

AI Agents Are Temporary. Repositories Persist.

I think we are entering a phase where software repositories themselves become cognitive systems:

accumulating decisions
preserving continuity
coordinating work
surviving agent turnover
carrying operational memory forward over time

Not because the models became infinitely smart.

But because the continuity stopped depending entirely on the model session.

That is the direction I have been exploring with Holistic, an open-source CLI for repo-native continuity across agents: https://github.com/lweiss01/holistic

Still early. Still evolving quickly. If you are working across multiple coding agents and running into the continuity problem, I would genuinely love feedback, critiques, or just a conversation about how you are solving it.

The repo remembers, not the window.