The Reality of Long-Running AI Development: The Context Wall and Running a Memory
Contents
Develop with an AI for long enough and you always hit the same wall: it starts forgetting the beginning.
As a conversation grows, the AI summarizes and compresses what came before. Carrying the full history is not possible, so the mechanism is sound — but summarizing, useful as it is, drops the details.
What summarizing drops is the detail that matters later
The precise numbers in a spec, the reasoning behind a decision, the pitfall you hit once and agreed to avoid. None of them are the main thread, which is exactly why they thin out first.
Figure 1: What summarizing drops is the detail, not the thread
Deep dive: the mechanism itself is sound
Carrying the whole history forever is not an option, so summarizing is the right design. The problem is that what survives and what is dropped is not something you get to choose.
The trouble is drifting from the spec while trusting the summary
The AI proceeds plausibly from whatever summarized context it still holds. It works convincingly in isolation, and disagrees with what was actually specified.
Figure 2: Where the most common rework in long sessions comes from
Deep dive: "I checked that earlier" also rides on the summary
The feeling that it was checked and is therefore fine may itself be resting on a thinned-out memory. So rather than trusting the feeling, go and look at what the files say.
Truth is the spec and the plan, not the conversation
The spec decides what to build, the plan decides in what order. The plan states what "done" means at each stage, up front, in a form a machine can judge.
Figure 3: Two documents to treat as truth, and one place for the values
Deep dive: why the values go in one appendix
Contract values are not scattered through the body; they are collected in an appendix at the end of the spec. They are not written from memory either: each is recorded as the result of checking the real thing, with what was checked and when. Neither the body nor the plan restates the values — they reference the appendix.
Write the same fact twice and one copy eventually goes stale and disagrees with the other. With one place, a thinned-out memory can always be walked back to primary information. Especially when it feels like "I know this, it's in memory," stop and re-fetch the real thing.
Clear the context yourself before automatic summarizing kicks in
Summarizing happens automatically, and you do not get to pick what it keeps. The bigger the context, the more attention scatters, so cut at a clean point yourself.
Figure 4: Leave it to the mechanism, or cut it yourself
Deep dive: wasteful-looking, and easier to handle
Clearing resets the context completely, and the model works unencumbered. Stacking short, cleanly separated sessions gives more control and holds quality better than dragging one long, vaguely summarized session along. A bloated context is like thinking at a cluttered desk.
Hand off into files, and put them in git
Before clearing, leave a handoff for the next session. In git, another machine and another office are the same thing: pull, and the lessons are there.
Figure 5: A short-term working log, and a store for durable facts
Deep dive: conversations don't travel, files do
What gets kept is the project's standards, the state of work in progress, and above all past failures with their lessons. Write "done this way, it breaks here" or "that assumption was wrong" once, and the AI in the next session avoids the same trap no matter where it resumes. Conversational context cannot be carried between machines; facts moved into files can be picked up from anywhere.
Delegate the work; don't delegate holding the facts
The context wall does not go away. So it is never used on the assumption that it remembers everything indefinitely.
Figure 6: Assume forgetting, and put what you can't afford to lose outside
Deep dive: this concession is what lets it keep running
Facts that must be remembered live outside the AI's memory. What the AI is given is the work built on those facts. Unglamorous, and the most practical working habit we found for long-running AI development.
- How a Micro-SaaS Tech Stack Changed in a Single Year
- Two-track review with Claude and Codex: surfacing blind spots with a different AI lineage
- What MCP changed: giving AI hands
- Posts on our development work (dev category)
Built out of habits like these is PentaTrail / CTEM. The same idea — watching continuously with AI — applies just as well to your company's attack surface.
Appendix: the documents, and what gets kept
Table 1: documents treated as truth
| Document | What it decides |
|---|---|
| Spec | What to build: design intent, and the contracts to hold (the shape passed between screen and server, column definitions, function inputs and outputs) |
| Plan | In what order to build it, with completion at each stage stated up front in numbers and commands |
| Appendix | Contract values, collected in exactly one place, with when the real thing was checked |
Table 2: what a handoff keeps
| Type | Detail |
|---|---|
| Working log | A short-term record for quickly recovering how far things got |
| Standards | The project's own coding conventions |
| State in progress | What has advanced to where |
| Failures and lessons | Which way of writing breaks, which assumption was wrong |
Table 3: delegated, and not
| Treatment | Scope |
|---|---|
| Delegated | Hands-on work built on the facts |
| Not delegated | Holding the facts themselves (kept in spec, plan and memory) |
Visualize your attack surface with PentaTrail CTEM/ASM
From discovery to vulnerability validation and remediation — all powered by the CTEM framework.
Get Started
