I think I've been looking at AI projects backwards.
For months, agents were the center of everything I thought about. Agent memory, agent orchestration, agent frameworks, agent autonomy. Like most people working in this space, I put the agent at the center of the picture because the agent was the thing doing the work. Optimizing it seemed obvious.
Then I noticed something I haven't been able to stop thinking about since: every time I looked at a real project, the agent kept changing. Claude would spend a while on a feature. Later, Codex would pick it up. Cursor would get involved. Sometimes I'd step in myself, and then another model would take over. The work kept moving forward, but the participants kept rotating in and out.
At first I read this as a memory problem. Context seemed to disappear between sessions. Decisions had to be rediscovered, failed approaches retraced, the same explanations given over and over. The obvious conclusion was that agents were forgetting.
But the more I watched these transitions, the less convincing that explanation became. Nothing had actually been forgotten. Claude hadn't forgotten anything. Neither had Codex. The next participant simply hadn't been there when the previous decisions were made. What I was seeing wasn't memory loss. It was the friction that appears whenever work has to survive a participant change.
That distinction sent me down a very different path.
We've become accustomed to putting the wrong thing at the center of the diagram. We talk about agents the way a factory might talk about workers. We measure their capabilities, compare their strengths and weaknesses, and pour enormous energy into making them more effective. Those are useful conversations, but they left me wondering whether we were focusing on the participant instead of the thing being produced.
A factory doesn't exist for its workers. It exists so cars can roll off the line.
That sounds almost too obvious to say out loud, but it's worth sitting with for a moment. When you walk through a factory, nobody mistakes the worker for the product. The workers matter. They contribute. Some are more skilled than others, some faster. But none of them are the thing moving through the system. The car is. The entire factory is organized around helping that car move from one stage of production to the next. Workers participate in the process, but the car is what persists. It survives shift changes, vacations, retirements, the constant replacement of individual participants.
Factories have spent decades learning how to handle that reality: they don't build continuity systems because workers are forgetful. They build continuity systems because workers leave. The day shift goes home, the night shift arrives, and the work continues.
Once I saw that, I couldn't stop seeing the same pattern in AI development. Projects outlive agents. Projects outlive sessions. Projects outlive models. The project I'm working on today will almost certainly be touched by systems that don't exist yet. Models will improve, frameworks will come and go, entire categories of tooling will appear and disappear. The project remains.
That's what finally made the idea click.
I had been centering the wrong object. I was treating the agent as the thing moving through the system and the project as a container for the work. But the longer I looked at real projects, the more backwards that seemed. Everything else rotated. The project was the only thing that stayed.
Claude isn't the thing. Codex isn't the thing. Cursor isn't the thing. I'm not even the thing. We're all participants acting on the thing.
The project is the thing.
I want to sit with that for a second, because it's easy to nod along and miss what it actually implies.
It implies that the agent I'm using today is a shift worker. A skilled one, maybe my favorite one, but a shift worker. When the session ends, the shift ends. Whatever that agent understood about the work either made it into the project or it didn't. If it didn't, it's gone, and no amount of model improvement fixes that, because the next participant wasn't there.
It also implies that I'm a shift worker, which was the part that took longest to accept. I close the laptop at night, and tomorrow a version of me shows up with most of the context evaporated, asking the same questions a fresh agent would ask. The gap between me and Claude at the start of a session is smaller than I'd like to admit.
And strangely, the demotion is freeing. If the project is the thing, I can stop asking which agent is smartest and start asking what each participant leaves behind in the project when their shift ends. That's a different question with different answers. The smartest agent that leaves nothing behind is worth less to the project than an average one that writes everything down.
That realization changed how I think about continuity. A checkpoint is not memory for an agent. A checkpoint is continuity for a project. A handoff isn't helping an agent remember what happened, it's helping the work survive a shift change. The purpose of continuity was never to preserve the participant. It's to preserve the work.
Which is why I've become less interested in perfect memory and more interested in continuity. Perfect memory helps a participant. Continuity helps a project. And projects are the things that actually have to survive.
The funny thing is that the title of this post isn't really the conclusion. It's just the observation that got me here. AI agents don't work. They take shifts. The real conclusion is something else entirely:
The project is the unit of continuity. The agent is the unit of execution.
Once I started looking at AI systems through that lens, a lot of ideas that had previously felt separate (checkpoints, handoffs, project memory, supervision, even Andon) started looking like different parts of the same system. They're all answering the same question.
How does the work survive the shift change?
Top comments (0)