Your AI work needs a save point

Aaron Harris recently asked which LLM habit people had developed in the past year that they could no longer work without.

His own answer was to give the model more context than it appeared to need, then make it wait until they were aligned before allowing it to start. Both habits improve the quality of the current interaction: the model sees more of the picture and is less likely to rush towards a plausible answer before it understands the real problem.

My answer in the comments was shared memory.

I had started using GitHub as a persistent context layer for my AI work. Ideas, decisions and unfinished thinking were saved rather than disappearing into individual chats. I could return to an argument months later, challenge it with something new and still have a known point to return to.

It sounded like a useful workflow habit. It actually began as a loss of confidence.

Editorial Intelligence had become split across Claude and ChatGPT. Each contained useful conversations, instructions and fragments of the work. Neither had the whole system. Both forgot things I thought we had established, but the more difficult problem was that I could not see precisely what either one remembered.

When a model produced an answer, I had to ask a second question in my own head: is this judgement based on the full Editorial Intelligence context, or only the part that happened to survive in this conversation?

That uncertainty matters. A fluent answer can look exactly the same whether the model has recovered the relevant decisions or silently lost them. Once I stopped being confident about the context behind an answer, I also became less confident about the answer itself.

There was a second concern. The more context I accumulated inside one provider, the more useful that provider became, but the harder it became to leave. If an account stopped working, a product changed its memory behaviour or another model became better for the job, I did not want years of Editorial Intelligence thinking to be trapped inside an interface I did not control.

I did not need one AI with perfect memory. I needed different AIs to work from the same inspectable memory.

What I needed was a save point.

The repository was doing two jobs

In Judgement as infrastructure, part one, I wrote about Sandhya Simhan, who runs content marketing at OpenAI, and her team’s content marketing repository. They were turning recurring feedback, strong examples and format standards into reusable editorial agents and skills. The important move was to stop treating editorial comments as disposable and allow previous judgement to improve the next piece of work.

I recognised the principle because I had been doing something similar with Editorial Intelligence OS. GitHub was no longer only storing a website. It was preserving developing frameworks, published arguments, evidence, working decisions and the relationships between them. Claude and ChatGPT could both work across that accumulated context.

That article was about accumulation: yesterday’s editorial judgement becoming useful infrastructure for today’s work.

The repository was also solving a more basic problem that I had not properly named. It allowed the work to survive the conversation in which it happened.

I saw the distinction clearly when an Editorial Intelligence workflow stopped at the beginning of a challenge stage. The process was supposed to test a brief before the idea moved into drafting. It looked for the brief in the repository and could not find it.

We had discussed the idea. Quite a lot of thinking had happened. But the authoritative file the next stage needed did not exist.

The AI had not forgotten a saved piece of work. We had mistaken a conversation about the work for a durable state of the work.

The workflow stopping was useful. It exposed the missing handover rather than improvising from whatever context happened to remain. The repository was not only becoming knowledge infrastructure. It was becoming recovery infrastructure.

Why a conversation feels more durable than it is

The word “memory” hides several different systems.

There is the knowledge learned during model training. There is the current context window: the instructions, messages, files and tool results available for this response. There may be a summary of an older conversation, a product memory system retrieving selected facts or a project containing shared files. Then there are external systems such as repositories and document stores that the model can search when it needs them.

Together, these layers can create a persuasive feeling of continuity. They do not provide the same guarantees.

At the model interface, a conversation is not an endlessly accumulating mind. OpenAI’s documentation describes text-generation requests as independent and stateless; continuity has to be created by supplying previous messages, stored state or retrieved information again. Consumer products handle much of this invisibly, but the underlying constraint remains: a model can only work with the context made available to it at that moment.

A larger context window helps, but it does not turn a transcript into reliable long-term memory. As conversations grow, earlier material may be compressed, summarised or omitted. Even when information technically fits, it may not receive equal attention. Anthropic describes this degradation as “context rot”: more tokens can provide more information while also creating more competition for the model’s attention.

Compaction is a practical response. A long conversation is summarised and a new context begins from that summary. But summarisation is editorial selection. Something decides which details are important enough to survive. A distinction that looked minor during compression may become essential two stages later.

Product memory introduces another selection layer. It can be useful for preferences, recurring goals and broad continuity. It is not the same as restoring an exact project state. OpenAI’s own guidance says to treat memory as a helpful recall layer, rather than the only place for instructions that must always apply. “Asavin prefers sentence case” is useful memory. “This is the current version of the argument, these claims still need evidence, and this is why we rejected the previous direction” is working state.

The distinction becomes more important because the missing context is not always visible. A model can explain what it believes, but the user does not receive a complete inventory of everything that was retrieved, compressed, excluded or given too little weight. It can continue confidently after losing the rationale behind an earlier decision.

This is not only a theoretical limitation. It also depends on the product surrounding the model. In April 2026, Anthropic disclosed a Claude Code bug that repeatedly removed older reasoning after an idle session. Claude continued to work but increasingly lacked the rationale behind earlier edits and tool calls. To users, this appeared as forgetfulness, repetition and strange choices. The bug was fixed, but the incident made the dependency visible: continuity can change because of a caching decision, a summarisation rule, a product update or a fault, even when the underlying model has not changed.

“Carry on where we stopped” is therefore a much harder request than it sounds. The system has to recover the correct project, current version, objective, decisions, evidence, constraints, unresolved questions and intended next action. Remembering the user is not the same as restoring the work.

A save point is a handover, not an archive

The metaphor comes from games, but it describes the requirement better than memory. I used a smaller version of the same idea describing my own GitHub habit while writing about RimWorld — putting an idea somewhere it can live means I don’t have to keep carrying it around in my head. It has a save point. I can leave the world. This piece is that observation taken seriously as infrastructure rather than left as an aside.

A save point does not preserve every movement the player made. It records the state required to continue: where they are, what has changed, what they have acquired and what remains unresolved.

AI-assisted knowledge work increasingly needs the same thing.

Saving every conversation is not enough. A transcript is an event log. It contains useful decisions alongside false starts, repeated explanations, tool output, misunderstandings and ideas that were tested and discarded. Asking a new model to reconstruct the project from the entire conversation repeats the original work of deciding what mattered.

A useful save point is smaller and more deliberate. It should make clear:

• what the work is trying to achieve;
• which artifact is currently authoritative;
• what has been decided and why;
• which evidence supports or challenges it;
• which constraints still apply;
• what remains unresolved;
• what should happen next;
• when this state was recorded and what changed.

Creating that handover is not clerical work. It is editorial judgement applied to continuity. It decides which parts of the conversation should become part of the project and which should be allowed to disappear.

Not every exchange needs a formal checkpoint. The useful moments are when a decision changes the direction of the work, an artifact becomes authoritative, a stage is completed or the session is about to stop. The save point marks a state another human or model can actually resume.

I have argued elsewhere that context is capital. But context only compounds if it is maintained, retrievable and able to influence the next decision. A save point is where useful context is promoted out of a temporary interaction and into that durable layer.

Why GitHub makes shared memory practical

GitHub is useful here for reasons that have little to do with writing code.

A commit creates an inspectable checkpoint. A diff shows exactly what changed. A branch lets me test a different direction without replacing the current one. A fork can create a separate repository that remains connected to its source. GitHub’s documentation distinguishes branches as contained spaces for experimentation from forks as separate connected repositories. Both make it possible to explore without losing the last known state.

The formats matter just as much. Markdown, plain text, CSV and JSON are not tied to one AI interface. Claude can work with the repository. ChatGPT or Codex can work with it. A future model can work with it. They will not interpret everything identically, but they can inspect the same current state and history rather than relying on what survives inside their separate conversations.

That creates something closer to shared memory across models. The repository holds the durable version of the thinking. The model becomes a temporary way of reading, challenging and changing it.

The practical benefit is not that GitHub remembers everything. It is that I can inspect what has been preserved. I can see whether the brief exists, which file is current, why a decision changed and what the model added. If Claude and ChatGPT reach different conclusions, I can ask both to work from the same evidence rather than wondering whether the disagreement began with different hidden context.

GitHub does not automatically create a good knowledge system. A badly structured repository is another neglected archive. Files still need clear names. Current material has to be distinguishable from abandoned experiments. Claims need sources. Decisions need enough rationale to remain legible. Outdated assumptions need dates. An agent can still retrieve the wrong file or miss a connection.

The difference is that these failures become inspectable and correctable. Hidden product memory may or may not retrieve a fact. A repository lets me verify the state itself.

The lock-in is not only the model

People tend to compare AI providers by capability, price, speed and interface. As their memory systems improve, the more consequential switching cost may be the context accumulated around them.

If one provider holds the history of your projects, corrections, preferences, decisions and unfinished thinking, moving to a better model no longer means changing tools. It can mean leaving part of your working memory behind.

That is a powerful form of lock-in because it feels helpful while it develops. Better memory makes the product more useful. The more useful it becomes, the more expensive it becomes to leave.

Neither OpenAI nor Anthropic has to oppose portability for this tension to exist. Both can support GitHub, connectors and open protocols while still benefiting when more of a user’s working context accumulates inside their own product. Interoperability at the tool layer is not the same as portability at the memory layer.

A genuinely shared memory layer changes the commercial relationship. If the same durable context works across Claude and ChatGPT, I can choose between them for each task without paying the cost of teaching the replacement everything that came before. The model still matters, but accumulated history no longer protects one provider from comparison.

I do not expect either company to make that possibility the centre of its product story. “Your memory should work just as well with our competitor” would be useful infrastructure for the user, but it is a weak retention strategy for the provider. That does not prove deliberate obstruction. The incentives are enough to explain why shared memory is more likely to appear as a technical capability than a celebrated product principle.

This does not make provider memory inherently bad. Remembering preferences and recurring personal context can remove friction. The risk depends on what the memory is being asked to hold.

A preference can reasonably live in a personal memory layer. The canonical state of a long-running methodology should live somewhere the user can inspect and move. Client or organisational knowledge should sit inside a governed system with the right ownership and access controls, not in an individual’s private repository or AI account.

Exporting a chat history does not fully solve this. Portability is not possession of a raw archive. It is the ability for another human or model to understand the current state without reconstructing it from thousands of messages.

For durable work, I now treat provider memory as a useful cache and personalisation layer, not the system of record.

What better AI memory needs to become

AI memory will improve. Context windows will grow. Retrieval will become more accurate. Models will get better at deciding what to preserve and what to discard. Agents will maintain notes and project state with less human intervention.

But “the model remembers everything” is not the right destination.

Useful memory needs to be inspectable. I should be able to see what was remembered, where it came from, when it was recorded and why it is being applied now. It needs scope, so a personal preference is not confused with a client rule or an abandoned project decision. It needs conflict handling, because new evidence may contradict an old conclusion. It needs deliberate forgetting, because stale context can harden into automated inertia.

It also needs portability. A durable project state should be exportable in formats another model can understand, with its files, decisions, sources, open questions and version history intact. Ideally, an AI product should be able to work against a user-owned or organisation-owned knowledge layer rather than requiring the knowledge to migrate into the product’s private memory.

Most importantly, AI systems need to improve at resumability rather than only familiarity. A future assistant should not merely recognise me. It should be able to reopen a project at a named checkpoint, verify what has changed since, surface conflicting state and explain what it believes the next action to be before it continues.

Even if one provider eventually offers excellent memory, I am not convinced it should become the only custodian of the work. Convenience and control are different benefits. The strongest system may combine the provider’s fluid personal memory with an external, inspectable source of truth.

The fresh-model test

There is a simple test for whether an AI-assisted project has a real save point.

Open a fresh conversation with a different model. Give it access to the project, but not the old transcript. Can it identify the current objective, authoritative artifact, important decisions, relevant evidence, unresolved questions and next sensible action?

If it can, the project has continuity.

If it cannot, the work may still be trapped inside the conversation that produced it.

Editorial Intelligence now has something resembling shared memory across Claude and ChatGPT, but not because both products remember me in the same way. They can work from the same durable source, and each can leave the work in a state the other can inspect.

I still want the models to remember more. Better memory will make them more useful. I just do not want either model to be the only place where Editorial Intelligence can be recovered.

I now treat an AI session as unfinished until the decisions required to resume it have been written back to the repository.

That is the save point.