The repository is becoming the memory layer for AI work

The interesting thing is not that developers are putting Kanban boards in Git. It is that several different systems are trying to solve the same problem: move the state of the work somewhere durable, so the human does not have to keep rebuilding it for the AI.

I saw a line on LinkedIn this week that stayed with me: someone described themselves as the API between all their AI tools. That is funny because it is accurate. You do some research in one place, draft in another, ask a second model to challenge it, save something in a document, change direction after a meeting, then come back three days later and discover that the expensive part is not doing the work. It is remembering what the work now is.

You have to reconstruct the same questions over and over. What did we decide, why did we decide it, which version is current, what changed afterwards, what am I waiting for, and which parts still need judgement? For a while I treated that as a personal organisation problem. Increasingly I think it is an AI systems problem.

I accidentally built around the same problem

A few days ago I wrote about how I did not get better at to-do lists. I made the work recoverable. GitHub has gradually become a persistence layer behind a lot of my work, not because I particularly wanted to manage my life like a software project, but because conversations kept being too temporary.

If a useful decision existed only inside one ChatGPT thread, it was easy to lose. If Claude rewrote something from a different context, I needed to explain what mattered again. If I stopped a project for a week, I had to reconstruct its history before I could decide what to do next. So I started leaving a better trace behind: decisions, current state, useful evidence, open questions, what changed, what is blocked, which files matter and what the next plausible move looks like.

The important part is that I do not need to preserve a perfect list of actions. I need to preserve enough of the underlying state that the next actions can be reconstructed when I return, and that distinction has become much more useful to me than any particular productivity app.

This is how I am using it when work gets messy

The value becomes clearest when I am context switching, because a fairly normal workday for me can move across several completely different kinds of problem. I might start by preparing questions for an event interview, move into a web project that needs copy and asset decisions, look at a set of customer stories that need QA, get pulled into campaign planning, then come back to the event work because somebody has replied with a detail that changes what I need to ask.

None of those jobs is individually impossible to hold in my head. The problem is the switching cost between them, and a conventional task such as Finish interview pack is not much help if what actually matters is that the questions have already been agreed, one evidence gap still needs filling, the interview format changed yesterday and the next move depends on a reply from somebody else.

The task is not the state. So when I finish a burst of work, I try to leave behind enough context that I can later ask an AI what changed most recently, what is genuinely unresolved, what I am waiting for and which thing deserves attention now. That means I can leave one thread, work on something unrelated and return without paying the full reconstruction cost every time.

I still make mistakes, the repository can still become stale, and confidential company material stays where it belongs rather than being copied into a personal system. But the working habit is useful: leave enough state behind that the work can be resumed without retelling the whole story.

I am trying the same idea with customer intelligence

There is another version of this that interests me more because it moves beyond personal productivity. I have been testing an idea around customer stories, where the normal process is to research, interview, write, approve and publish. Then a surprising amount of the useful intelligence disappears into the finished asset.

A story may contain a strong proof point, a useful quote, a recurring operational problem, an unanswered question, a detail that would improve the next interview or a theme that appears across several customers rather than one. Once the article is finished, though, the next project often starts again from something close to zero.

So I have been exploring a simple intelligence layer after the story is complete: capture the story spine, the strongest proof, useful quotes, evidence gaps, follow-up questions, themes, editorial lessons, what could be reused and what still needs verification. The point is not to create another giant database for its own sake. It is to make the accumulated work queryable later, so if I interview ten companies I should not only end up with ten published stories; I should know more before I interview company eleven.

That is the same architectural idea at a different scale. Do not just save the output. Preserve enough of the state and evidence that future work can begin from what the organisation already learned. This is where the distinction between task management and work memory starts to matter.

Then I found Kanbus

That is why Kanbus caught my attention. Its proposition is much more developer-specific than what I am doing: it embeds project management directly into a repository, tasks live alongside the code, Git records the history, and humans and AI agents can work against the same durable project state.

The Kanban board is almost the least interesting part to me. The interesting idea is that the repository becomes the message bus. Instead of an AI agent depending on whatever happens to fit inside the current conversation, the work has somewhere else to live.

Kanbus is not an isolated example either. TASKS.md uses a Markdown file inside the repository as an agent-readable task queue, while Beads describes itself as persistent, structured memory for coding agents. These are different products and different levels of complexity, but they are responding to the same underlying weakness: the model can be very capable while the surrounding work has terrible memory.

The task is only part of the state

There is one place where I think my own use is slightly different from a lot of the developer tools I have been looking at. They understandably start from tasks, issues and dependencies, whereas I increasingly care about a wider definition of state because an editorial project is not just what needs doing next.

It also contains the argument that survived an earlier challenge, the evidence that supports it, the claim that turned out to be too strong, the interview question that worked, the customer detail that changed the story, the stakeholder decision that closed one route and opened another, and the thing we learned after publication.

If I preserve only the task, I can know what somebody intended to do. If I preserve enough of the surrounding state, I have a chance of knowing why that task still makes sense now. That is why I keep coming back to the idea of recoverability: a list preserves actions, while a useful work-memory system preserves enough context that actions can be regenerated against current reality.

This also changes how I think about model choice

The other consequence is that the AI itself becomes less important as the storage layer improves. I have been writing for a while about prompting becoming routing, and the connection is simple: if everything useful lives inside one chatbot, switching models is expensive because you are switching away from accumulated context as well as capability.

If the important evidence, decisions and current state live somewhere durable, though, the models become more replaceable. One model can develop an argument, another can challenge it, a coding tool can build something and a cheaper model can deal with routine transformation, without the human acting as the only carrier of memory between them.

The architecture starts looking more like durable state → retrieve the relevant context → route to the appropriate intelligence → update the state, rather than open chatbot → explain project → do work → lose context → repeat. That feels like a much more important change than another improvement in prompting technique.

Git is probably not the point

There is an obvious objection to all of this: most knowledge workers are not going to start managing their work in GitHub, and I would not recommend my exact setup to most marketers, editors or communications teams. The command line is not secretly the future of HR, and a Git-native Kanban board is probably not what an exhausted campaign manager is asking for.

But Git may be showing the architecture early because software development already has a mature way to version files, record history, work across branches and let machines interact with structured state. The broader principle does not require Git; it could eventually sit in SharePoint, Notion, a project workspace, a knowledge graph or something that does not yet look like any of those things.

The useful test is simpler. When a person or AI returns to meaningful work, can it recover what is true now without somebody manually reconstructing the whole project? If yes, the system has memory. If no, the human is still the API.

The productivity layer may be moving underneath the chatbot

I originally thought my GitHub workflow was a slightly eccentric personal response to the way my brain works. I am less sure now, because seeing developers build Kanbus, TASKS.md and Beads around persistent project state makes me think there is a wider design pattern emerging.

The next generation of AI productivity software may not primarily be about giving us a better chat window. It may be about giving the work somewhere durable to live between chats, and that matters for developers managing agent tasks, for me jumping between projects at work, and for something as ordinary as a customer story.

If the organisation finishes a piece of work but loses the evidence, decisions and learning that produced it, the output survived and the intelligence did not. That is the part I increasingly want to fix.

The model does not need to remember everything. The work does.