GitHub is the memory my AI keeps forgetting to use

I asked Codex a simple question: what was the link that stops Vercel Analytics tracking my visits to my website?

It checked the website files and told me there was no link. Instead, it gave me a line of code to paste into the browser console.

I knew that was wrong.

“No,” I replied. “You definitely created a link for me that I can click on.”

This time I pointed it towards GitHub.

The answer appeared almost immediately:

https://www.editorialintelligence.co/?noanalytics=1

There was a commit called Exclude owner visits from Vercel Analytics. It contained the exact mechanism. Visiting the link stores an opt-out preference in that browser and removes the identifying parameter from the visible address afterwards.

The link existed. The AI had helped create it. GitHub had preserved the decision and the implementation.

But the AI still told me it did not exist.

The wrong memory

The first answer was not invented from nothing.

Codex had searched the website files available in its local workspace. Those files contained an earlier version of the opt-out mechanism, where I had to open the browser console and set the preference manually.

That was real. It just was not current.

A later change had added the clickable link, but the local copy Codex inspected had not been updated with that commit. It searched one version of the evidence, found a plausible answer and stopped.

When I explicitly gave it access to GitHub, it searched the remote history and found the later change.

That makes the failure more interesting than “AI forgets things”.

The information had not disappeared. It existed in a durable, searchable record. The problem was that the AI treated the first available source as authoritative without checking whether a more current one existed.

It did not need a better conversational memory. It needed to consult the right system of record. That’s the same distinction Portable Intelligence is built around: the model is replaceable, the repository is what has to survive.

The fix still depended on me noticing

I should be honest about the part of this that isn’t solved yet, because the story above makes it sound cleaner than it was.

Codex didn’t decide, on its own, that the repository might hold a better answer than its local files. I decided that. I already believed I had built a clickable link, so a confident answer saying otherwise read as wrong rather than as new information. That’s what made me say “no” instead of accepting it.

If I hadn’t remembered building the link — if this had been someone else’s project, or something I’d built and genuinely forgotten — the first answer would have stood. Wrong, but uncontested, and stated with exactly the same fluency as the correct one.

So the actual system right now isn’t “the AI checks GitHub before answering.” It’s “the AI checks its local files, states the result as fact, and I have to already know enough to doubt it before GitHub enters the conversation at all.” That’s a real gap, not a solved problem, and it puts the weight back on the same human memory this whole piece is arguing you can’t rely on.

A project is not one continuous conversation

There is another kind of forgetting that happens before anything reaches the repository.

I use separate AI chats for different pieces of work. They may all sit inside the same project, concern the same website and draw on the same general context. From my perspective, they are parts of one body of work.

The AI does not necessarily experience them that way.

Something developed in one chat is not reliably available in another. Even when both conversations belong to the same project, the assistant can struggle to connect them. I can begin with a new thought, realise halfway through that it relates to something I explored weeks earlier, and then discover that the AI cannot find the earlier reasoning.

This is especially irritating because making connections is often where the value lies.

The new thought may not be important on its own. Its importance comes from how it changes an older argument, contradicts a previous assumption or adds evidence to an unfinished idea. If the earlier conversation cannot be recovered, the connection has to be reconstructed from memory.

Sometimes I remember enough to find it. Sometimes I remember only that something relevant existed.

And sometimes work done with AI exists only inside the conversation where it happened. If that conversation is lost, buried or unavailable to another chat, the work is effectively lost too.

The output may once have been excellent. It may have contained a useful distinction, a decision or the beginning of an argument. But if it was never moved into a durable system, it has almost no ability to influence later work.

A project label creates useful organisation. It does not automatically create shared memory. I’ve made the wider version of this argument before, about why every company needs a GitHub for knowledge, not just code — this is what the gap looks like from inside a single person’s workflow rather than an organisation’s.

Chat is a working surface, not a knowledge system

AI conversations are good places to develop thinking.

They are fast, responsive and provisional. You can test a weak idea without formalising it, change direction halfway through and ask the model to challenge what you have just said.

That flexibility is part of their value.

It also makes them a poor final home for anything you want to use again.

Important reasoning becomes mixed with abandoned directions, repeated prompts, corrections and small operational exchanges. The title of the conversation may describe how it began rather than what it eventually produced. A useful insight can sit hundreds of messages inside a chat whose name you no longer recognise.

The transcript preserves the words, but preservation is not the same as retrieval.

This creates an awkward gap in AI-assisted knowledge work. The conversation can help produce something worth remembering without ensuring that the system will remember it.

If an idea matters beyond the current exchange, it has to be promoted out of the chat.

It might become an article draft, a framework note, a documented decision, an issue, a commit or a backlog entry. The format matters less than the transition from temporary conversational context into an authoritative, searchable record.

Chat is where the thought is developed.

The knowledge system is where it becomes available to the next thought.

This has happened before

The uncomfortable part is that the analytics link was not the first time a stale copy of the repository had produced a confident but false conclusion.

I previously published a piece called What the repository doesn’t record. It argued that two AI sessions had independently produced overlapping work because neither could see what the other was doing.

It sounded plausible. It fitted a concern I already had about multiple agents working concurrently. There was even apparently supporting evidence.

Then the repository history was examined properly.

One article had been passed from one system to the other as a draft. The apparent similarity was not independent convergence; both versions came from the same source.

The second example of duplication was caused by a local copy of the repository that had not fetched the other session’s commits.

The mechanism at the centre of the article was false, so I removed it. The correction is still recorded in GitHub.

That history now contains something more useful than the original article. It records the claim, the investigation that contradicted it and the decision to withdraw it.

A conversation would probably have lost that sequence. GitHub did not.

Repositories do not remember automatically

None of this means that putting something in GitHub makes it permanently correct.

Repositories can contain outdated instructions. Different files can repeat the same fact and drift apart. A local copy can fall behind the remote version. A commit can preserve a decision that was later reversed.

GitHub does not solve these problems by possessing a superior form of memory. Its value is that the record can be inspected. That’s the same conclusion the research behind context is capital keeps landing on from a different direction: storage isn’t memory, and memory isn’t useful just because it’s large. What makes either one useful is whether it can be checked.

You can see what changed, when it changed and why. You can compare an earlier implementation with the one that replaced it. You can discover that a confident claim was based on an old version. You can recover decisions long after the conversation that produced them has disappeared.

That distinction matters when working with AI.

The model’s answer feels like memory because it can refer fluently to earlier work. But fluency is not provenance. An answer can sound continuous with the project while being assembled from incomplete context, an outdated file or the most accessible version of events.

The repository gives the model somewhere to verify that continuity.

Only if it looks.

Do not make the system depend on remembering

Another example appeared in my Fantasy Premier League experiment.

The series landing page displayed a score between Fantasy Football and Editorial Intelligence. After the first result, the score recorded in the article changed to 0–1, but the landing page still displayed 0–0.

The same fact existed in two places. Updating it depended on somebody remembering both.

The eventual fix was not a better instruction telling the AI to be more careful. The site was changed so the landing page derives the score from the latest episode.

There is now one authoritative value. The other page reads it.

That is a better form of memory because it reduces the amount that any person or model has to remember. It’s also the same fix, one level down, as the workflow should outlive the model: don’t make correctness depend on anyone — human or AI — remembering to update the second copy.

The same principle applies beyond software:

• Keep a decision in one authoritative place.
• Record why it was made, not only the final answer.
• Move valuable thinking out of chats before it disappears inside them.
• Link later work back to the underlying evidence.
• Make repeated values derive from the source where possible.
• Check the current record before relying on conversational recall.

The goal is not to create an AI that never forgets. It is to create a system in which forgetting is recoverable.

The repository can also stop repetition

Memory is not only about retrieving a small technical detail.

A proposed article on brand content was recently checked against the existing Editorial Intelligence material. The comparison found that its central argument substantially duplicated an existing framework and two published essays.

Without that accumulated record, the new piece might have been published as if it were a new thought.

Instead, the genuinely new evidence was added to the existing work. The proposed duplicate was abandoned. The reasoning behind that decision remains visible.

This is what it means for knowledge to compound.

The repository does not merely store finished outputs. It makes earlier judgement available to challenge the next piece of work.

It can show that an idea already exists, that a number has changed, that an instruction contradicts the working system or that a story about what happened is not supported by the history.

It can also help reveal the connection I half-remembered from another chat — provided the earlier thought was important enough to put there.

But the repository can only perform that role when the workflow treats retrieval as part of the work, and right now that still means a person deciding to check, not the system deciding for itself. Turning recurring judgement like this into something closer to infrastructure — checked by default rather than by memory — is the actual work behind Editorial Intelligence’s editorial judgement system audit, not a solved feature of using a repository at all.

The important instruction is where to look

A lot of discussion about AI memory focuses on how much context a model can retain.

That matters, but it is not the whole problem.

More context can still contain the wrong version. A long conversation can preserve an early decision after the implementation has changed. Several chats inside the same project can each hold one part of an argument without any of them containing the whole. A detailed local workspace can be internally consistent and still be weeks behind the remote repository.

The more important question is not only:

What does the AI remember?

It is:

Where does the AI go when its memory needs to be checked?

For this website, GitHub is part of the answer. Not because GitHub is infallible, and not because every passing thought belongs in a repository. It matters because it provides a durable history that can be inspected, challenged and corrected.

Today, the AI had an answer. GitHub had the evidence.

I needed the evidence.

The lesson is not that AI cannot be trusted and repositories can. The repository contained both the original implementation and the later one. It also contains records of ideas I published and then withdrew.

The difference is that the repository makes disagreement with the past possible.

That is the kind of memory I need: not a system that always produces an answer, but one that lets me establish whether the answer is true.

AI will forget. People will forget. Chats will remain disconnected. Local files will fall behind. Documentation will become stale. Valuable thoughts will disappear inside conversations if nothing carries them forward.

The system should make those failures visible and recoverable. Right now it still needs a person who thinks to ask.

Judgement only compounds when it survives the conversation in which it was produced. Today, GitHub knew more about my work than the AI assistant working on it.

The assistant did not need to remember everything.

It needed to know where to look. It also needed telling to.