You are halfway through a coding project.
Your AI coding agent has been working with you for hours, maybe days. It knows why the code looks the way it does. It knows what you tried yesterday, what failed, which ugly workaround is intentional, and what you were planning to do next.
Then you hit the usage limit.
You still have another agent available. Maybe it runs through OpenRouter. Maybe it is local. Maybe you have credits somewhere else. Maybe you simply want to switch models.
The problem is not finding another AI.
The problem is that the new AI just arrived.
Your repository contains the code, but not necessarily the story behind the code.
So before the next agent can continue the work, we need to move that story somewhere both agents can reach.
This is the workflow I use.
The short version
There are only four steps.
I: Create a Room
Create an empty Living Memory Room for the project.
At first, it knows nothing. That is intentional.
Think of it as a shared workspace that different agents can enter.
II: Move the current work context into the Room
Before your current agent disappears, ask it to leave behind what the next agent needs:
- what you are building
- the current state
- important decisions
- what it already tried
- what failed
- what is unfinished
- what should happen next
- Then have it leave a handoff.
III: Connect another agent
Connect whichever agent you want to use next to the same Room.
Tell it to read the handoff first, then inspect the actual repository.
Now it has two things: the Room tells it what happened; the repository tells it what exists.
Then it can continue the work.
IV: Before that agent leaves, update the Room again
When it finishes its turn—or starts running low on tokens—have it update the important state and leave another handoff.
The next agent does the same thing.
That is the whole loop.
Wait. I just created a Room. Why is it empty?
Because it is new.
This part is important.
Creating a Room does not magically recover your previous Claude Code, Codex, ChatGPT, or other agent sessions.
If you have already been working on a project for three days and create a Room today, those three days do not suddenly appear inside it.
You have to migrate the useful context once.
Fortunately, you probably already have something that knows most of it.
Migrating an existing project
There are two common situations.
Your original coding agent is still available
This is the easiest case.
Connect the agent that has been working on the project to the new Room. Ask it to inspect the project and record the durable things the next agent should know.
For example:
We may need to continue this project with another agent later.
Review our current work and the repository. Save the important durable context to this Room: the goal, architecture or constraints that matter, decisions we made and why, important failed attempts, current state, and anything a future agent should know.
Then leave a handoff describing exactly where the work is now and what should happen next.
You do not need the complete transcript. In fact, you usually do not want it.
You want the parts of the past that still matter to the future.
Your original agent is already unavailable
This is the annoying case.
Maybe you already hit the limit.
Maybe the session disappeared.
Maybe that particular model is unavailable.
You can still bootstrap the Room.
Use an AI that already knows the project well.
For example:
I often discuss my work with ChatGPT separately from the coding agent actually editing the repository. That conversation may already contain the goals, decisions, problems, and current direction of the project._
I can ask it to reconstruct the useful context and put that into the Room first.
If necessary, I fill in the missing pieces myself.
It does not have to be perfect.
The goal is not to recreate every conversation that ever happened.
The goal is to give the next worker enough history to understand the present.
Now bring in the new agent
This is the fun part.
Connect the replacement agent to the same Room.
It might be another hosted coding agent. It might use a different model provider. It might run locally. The Room does not need to decide which model you should use.
Once connected, I would give the new agent an instruction roughly like this:
You are continuing an existing project.
Read the latest handoff and relevant project memories in the Room first.
Then inspect the repository yourself and reconcile what the Room says with the current code.
Do not assume the handoff is perfectly current if the repository shows otherwise.
Once you understand the current state, continue the unfinished work.
That distinction matters.
The Room is not a replacement for your repository.
And your repository is not a replacement for the Room.
The repository can tell a new agent:
Here is the code that exists.
The Room can tell it:
Here is why we ended up here.
Those are different kinds of information.
Why not just give the new agent the repository?
Sometimes that is enough.
For a small task, it may be all you need.
But consider a project that has been evolving for several days.
The code might show that you chose implementation A.
It may not show that you already tested B and C, discovered a subtle problem with both, discussed the tradeoff, and deliberately returned to A.
A fresh agent can inspect the repository and reasonably suggest B again.
🎊 Congratulations.
You have invented yesterday.
This is the kind of information worth carrying forward.
Not every token from the previous conversation.
Not every command.
Not every thought.
Just the state that prevents the next worker from unnecessarily rediscovering the past.
css
🪺 A tiny distributed-systems idea hiding underneath this */
There is a useful idea from distributed systems that maps surprisingly well onto this problem:
Do not let important state live only inside one worker.
A worker can disappear.
A process can crash.
A machine can go away.
The durable state of the system should not necessarily disappear with it.
AI coding agents are beginning to create a strangely similar problem.
An agent may become unavailable because its usage limit resets later. A session may end. You may switch providers. You may discover that another model is better for the next task.
So, as a useful mental model:
The agent is a temporary worker.
The repository holds the actual code.
The Room holds durable shared work context.
A handoff is a checkpoint for whoever comes next.
This is an analogy, not a claim that an AI-agent workflow and a distributed system are literally the same architecture.
But it changes how I think about agent continuity.
Instead of asking:
How do I make this agent remember everything forever?
I can ask:
What state should survive this agent?
That is a much more useful question.
After the first migration, you stop migrating
This is the nice part.
The annoying migration only happens because your project already existed before the shared Room did.
The first time looks something like:
Old Agent → Room → New Agent
But once the Room becomes part of the workflow, there is no special migration every time you switch.
// Random situation...
// Agent A works.
Before leaving, Agent A updates the Room and leaves a handoff.
// Agent B arrives.
Agent B reads the Room, checks the repository, and continues.
// Later, Agent B leaves its own update.
Agent C can arrive tomorrow.
The agents can change.
The model providers can change.
The sessions can change.
The shared work context stays in one place.
You do not have to switch agents
There is another useful consequence.
Nothing says Agent A has to disappear.
Maybe your preferred coding agent gets its quota back tonight.
Great.
Bring it back.
It can enter the same Room, read what happened while it was away, inspect the changes made to the repository, and continue again.
So this does not have to be:
Agent A → Agent B forever. 😭
It can be:
Agent A → Agent B → Agent A → Agent C → Agent B 👍🏼
Use whatever is available and appropriate for the work.
The Room is simply the common place they return to.
What should actually go into the Room?
Less than you might think.
I would start with:
- the purpose of the project
- important constraints
- architectural decisions that are expensive to rediscover
- decisions that look strange without their reasoning
- failed approaches worth avoiding
- current work state
- unresolved questions
- immediate next steps
Then use handoffs for the highly temporary part:
- Here is where I stopped.
- Here is what I changed.
- Here is what still needs to happen next.
The distinction is useful.
Some information should survive for weeks.
Some information only needs to survive until the next agent arrives.
You do not need to predict this perfectly on day one.
The Room can evolve with the project.
Why I started using this
I built Living Memory around the idea of persistent environments that people and different AI agents can share.
But while building it, I repeatedly ran into a much less philosophical problem:
my agents kept running out of gas.
- Sometimes one agent had unfinished work when its usage limit arrived.
- Sometimes I wanted to move the work to another harness or model.
- Sometimes another agent was simply available sooner.
The repository could travel easily.
The working relationship with the project could not.
That became one of the most practical uses of the system for me.
Instead of treating an agent session as the home of the project, I started treating the agent as someone temporarily working inside the project’s environment.
That small reversal makes switching agents much less scary.
Try it with one unfinished project
You do not need to redesign your entire AI workflow.
Pick one project that is already in progress.
Create one Room.
Move enough context into it that another agent could understand what is happening.
Leave one handoff.
Then connect a different agent and ask it to read what its predecessor left behind before inspecting the repository.
See whether it can continue.
If it cannot, that is useful too.
You will discover which pieces of context were missing, add them, and make the next handoff better.
The workflow improves by actually using it.
And once the second agent has done some work, ask it to leave something behind for the third.
At that point, you are no longer testing memory.
You are testing whether the work can outlive the worker.
Want to try the workflow? Open a free Room
Want to understand what a Room feels like first? Enter as a human and just talk
Your Previous Agent Ran Out of Tokens.
The Project Didn’t.
Top comments (2)
In multi-agent setups, handoff failure usually traces back to state schemas diverging rather than the prompt losing track. If the first agent mutates an intermediate data structure without logging the structural change in a shared manifest, the second model ends up hallucinating field names to reconcile the drift.
Small builder note: this handoff has actually been possible since the earlier lme-mcp version works fine in local 😅
NPM Package
The interesting part turned out not to be “can one agent hand work to another?” but what context actually needs to survive for the next agent to continue well.
That’s really what this post is about. If you try the workflow with another pair of agents, I’d love to know what survives the move and what doesn’t.