When I started building Holistic, I thought I was working on a memory problem.
Like many people using AI coding agents, I kept running into the same frustration. A session would end, a new one would begin, and suddenly the project was paying a tax. Decisions had to be rediscovered. Prior attempts had to be reconstructed. The same explanations kept getting repeated because the next participant didn't seem to know what the previous one had already learned.
The obvious explanation was memory. The agent forgot. So I started building checkpoints. Not transcripts. Not giant chat histories. Not larger context windows. I wanted durable project state: a record of what had changed, what had been tried, what had been decided, and what still needed to happen.
That eventually became Holistic. At the time, I thought I was building an agent memory tool. Looking back, I think that description was wrong. Not completely wrong, but incomplete. The clue was a contradiction I couldn't explain.
The Contradiction
As I started using multiple agents more frequently, the memory explanation stopped fitting the evidence. Claude would work on a task, then Codex, then Cursor, and sometimes back to Claude again. Each transition seemed to produce the same failure mode. Context disappeared. Decisions became unclear. Progress slowed while the next participant figured out where things stood.
I kept calling this memory loss until I realized that wasn't actually what I was observing. Claude hadn't forgotten anything. Codex hadn't forgotten anything. Cursor hadn't forgotten anything either.
The next participant simply hadn't been there.
That sounds like a small distinction, but it completely changed how I thought about the problem. The information wasn't being forgotten. It was failing to survive the handoff. Memory and handoff are not the same thing. One is about preserving knowledge inside a participant. The other is about preserving progress across participants.
The more I looked, the more I found examples where memory wasn't the bottleneck at all. The issue appeared precisely when work crossed a boundary: from one agent to another, from one session to another, or from an agent back to a human. The failure wasn't forgetting. The failure was continuity. I just didn't have that word yet.
Following The Wrong Theory
Once the memory explanation started breaking down, I moved to the next obvious theory. Maybe the problem wasn't memory. Maybe it was coordination. Agents needed better ways to communicate. Better handoffs. Better shared artifacts.
That explanation got further because it described more of what I was seeing, but it still didn't explain everything. What caught my attention was that people kept arriving at remarkably similar solutions from completely different directions. Some were using shared files. Others relied on conversation logs. Some created structured handoff records. Others experimented with append-only histories. The technologies varied, but the pattern didn't.
Nobody was arguing about whether the problem existed. They were arguing about how to solve it. That was an important clue, because it suggested I wasn't looking at a personal annoyance or a workflow quirk. I was looking at a category of problem that was beginning to emerge wherever people used multiple agents over time.
Then Andon Happened
Around the same time, I started designing Andon. At first it felt unrelated. Holistic was about preserving state. Andon was about supervision. I wanted a way to answer operational questions:
- What is my agent doing?
- Is it healthy?
- Is it stuck?
- Is it drifting?
- Do I need to intervene?
The name came from Toyota's andon system, where workers can signal abnormal conditions before defects continue down the production line. I liked the metaphor immediately because it aligned with something I had spent years thinking about professionally: systems, quality, process improvement, and how work flows through organizations. But it wasn't until much later that I realized why the metaphor felt so natural.
The interesting part of Toyota's andon system isn't the board, the lights, or even the cord itself. The interesting part is the assumption underneath it all: the work continues even when the workers change. Factories operate across shifts. Hospitals operate across shifts. Airlines operate across shifts. Large software systems operate across shifts. Participants come and go, but the work remains.
Once I saw that, everything else started to click into place.
The Work Must Survive The Worker
That is the idea I had been circling all along. Not memory. Not coordination. Continuity. Every mature operational system eventually discovers the same requirement: work must survive participant replacement.
That's why organizations create runbooks, status boards, shift reports, architecture records, incident logs, and operating procedures. Their purpose is not simply to help someone remember. Their purpose is to help the work continue when somebody else takes over.
Seen through that lens, Holistic and Andon stopped looking like separate ideas. Holistic preserves continuity. Andon protects continuity. Same problem, different layer.
Holistic answers the question:
What happened before?
Andon answers the question:
What is happening now?
Both exist because the work cannot depend on any single participant, whether that participant is a human, Claude, Codex, Cursor, or whatever comes next. The project persists. The participants do not.
The Thesis Revealed Itself
For a long time I thought I was building tools. Only later did I realize the tools were pulling me toward a theory: the project persists, the participants do not. Once that becomes clear, the question changes. It is no longer "How do we make agents remember?" It becomes "How does the work continue when the worker changes?"
That's a different category of problem. It's not memory, it's continuity. And eventually the thesis condensed into two sentences:
Memory belongs to participants.
Continuity belongs to projects.
I didn't start with that idea. I backed into it through a series of observations that refused to fit my original explanation. Checkpoint by checkpoint, handoff by handoff, and tool by tool, the same pattern kept reappearing until it was impossible to ignore.
Looking Ahead
The future of AI development is probably not one agent with perfect recall. It's many agents, many sessions, many models, many handoffs. Claude this morning. Codex this afternoon. Cursor tonight. A human reviewer tomorrow. A completely different model six months from now.
When I started building Holistic, I thought I was building an agent memory tool. When I started building Andon, I thought I was building a supervision system. Looking back, both were pointing at the same thing. The tools came first. The thesis took longer to reveal itself. But I think I've finally found the idea I was actually building toward:
The work must survive the worker.
Holistic is open source if you want to see how the handoff layer works in practice: github.com/lweiss01/holistic
Top comments (2)
I run a few AI tools locally and the handoff problem is real. Each session starts fresh with no idea what the last one did. Never framed it as a handoff issue rather than a memory issue — that distinction actually makes a lot of sense.
@lingdas1 That reframe was the thing that unlocked everything for me too. Once I stopped asking 'why does it forget?' and started asking 'why doesn't it survive the handoff?' the whole problem looked different.
What local tools are you running? Curious whether the handoff friction shows up the same way across different setups.