How to Use GitHub as Long-Term Memory for Coding Agents

Petar Djukic,PhD

SubscribeSign in

How to Use GitHub as Long-Term Memory for Coding Agents<br>Claude Code and every other coding agent forget everything between sessions. Long-term memory management, choosing what the next session reads, and the GitHub artifacts that hold it.

Petar Djukic,PhD<br>Aug 09, 2026

Share

When you begin a fresh coding session, it knows nothing of what you did before. The model stores no trace of the project, of prior choices, or of work done yesterday. Whatever linked the previous effort together must be reconstructed. Achieving that demands an agentic coding skill using an issue tracking system, like GitHub or Beads.<br>The skill here is long-term memory management. Deciding what the model’s next session reads, what stays stored until it starts and what you’ll have to provide in the conversation then.

I write Mesh Intelligence with care, sharing what I have learned so you have a leg up. Subscriptions are free, and they stay that way.

Subscribe

Here I demonstrate the practical side. I explain what must be stored in a saved memory so that a history-free session can run it, which choices belong in the repository, and how the work indicates completion. Once you master the technique you can launch a session that resumes exactly where the previous one left off, deploy multiple agents on a single repository without interference, and keep a loop alive while the work stays intact.<br>My code-generation pipeline for go-unix-utils runs in discrete rounds, each round launching a fresh session that reads the project state from a file. One time, mid-execution the planner suggested building a package the same run had already finished two hours earlier. No error was raised. A lingering entry kept the package marked as pending, and for a session without any memory, pending is the only reality. In an interactive chat I would have caught it with a single line, “we already did that,” and I would have skipped over the fact that my correction was the system’s sole recollection of what was previously done.<br>That one-line correction is one of four jobs you perform without noticing whenever you work through chat. You serve as memory, coordinator between code generation tasks, shared context, and stop condition. You act as a stateful wrapper around a stateless engine. I didn’t fully realize this when I built a specification-driven development pipeline. I had assumed the model performed the work while I guided it. When I stepped back, executed the pipeline 46 times, and observed all four jobs disappear, I realized those functions had been mine.<br>Industry calls the step of removing yourself “loop engineering.” Boris Cherny, creator of Claude Code, now says he stops prompting the model, “my job is to write loops” [7]. Addy Osmani describes the practice as “replacing yourself as the person who prompts the agent” [7]. Both point to the human as the bottleneck, yet neither explain what that bottleneck did all day. It spent its day on the four jobs. For loop engineering to work, that work has to be transferred somewhere else.<br>What I describe is akin to the blackboard systems of the 1980s, where independent specialists read from and write to a shared structure while a control component selects the next worker [10] [11]. Here the agents are the specialists and GitHub functions as the blackboard. The control component is you.

Figure 1. The blackboard. Every agent session reads and writes one shared structure and none of them talk to each other. The state lives in the issues, the specs and contracts live in the repository, and the control component deciding who works next is you.<br>The memory loss between sessions is only half the problem. LLMs also act non-deterministically. The same prompt with the same parameters can produce different results, and hidden serving conditions push them further apart [1] [2]. When a conversation lengthens, the drift builds; the model’s replies retain the same confident façade, giving no hint that it has strayed. Only you, in the dialogue, notice and pull it back.<br>The textual records I present here constitute a stable record of what the model is meant to be working on.<br>What a saved issue looks like

Each ticket in my repositories is produced by a model, then I sign it off before it reaches the tracker. The machine records its own memory. What stays human is the format, the decision about what the next session must load, what must survive in writing, and what may die with the conversation. Below is a working issue from the go-unix-utils tracker, condensed.<br>required_reading:<br>- docs/specs/software-requirements/srd003-format.yaml<br>- pkg/format/humansize.go (contract stub from a prior task)

files:<br>- path: pkg/format/humansize.go<br>action: modify<br>note: implement HumanSize with binary and SI unit conversion

requirements:<br>- id: R1<br>text: convert int64 bytes to a human-readable string with K/M/G/T<br>suffixes; 1024-based units when Binary is true,...