Long-Running Human-AI Engineering: Don’t Preserve Conversations. Preserve State.

A new chat begins. A context window reaches its limit. Engineering work resumes a few days later. Somehow, continuity is gone.

The obvious explanation seemed impossible to argue against. I treated it as a memory problem. Over time, however, the investigation led me to a different conclusion: continuity is not fundamentally about preserving conversations—it is about preserving the state from which engineering can continue.

The Memory Illusion

Long-running software projects rarely fail because engineers forget how the software works. The repository remembers. Source code remains available. Documentation accumulates. Sprint reviews record completed milestones. The project itself gradually becomes better documented as it grows.

Yet every time I opened a new conversation with my AI assistant (ChatGPT or Gemini for conceptual work), the collaboration resumed only partially. Some context remained. Some context had to be reconstructed. It was unreliable. At first, the gaps seemed like an unavoidable limitation of current language models. Context windows eventually filled. Conversations became too long. Starting a fresh chat simply meant re-establishing enough context to continue working. At first, I accepted it as part of the workflow. But after reconstructing the same context again and again, it became increasingly clear that this couldn’t be the way forward.

The Chat Is a Terrible Knowledge Store for Engineering

The Reconstruction Rituals

Reconstructing the Technical Context

The most obvious problem was technical. Some knowledge about the repository carried over, but never enough to work with confidence. Every new conversation required reconstructing the missing pieces. Which modules already existed? How was the repository structured? Which responsibilities belonged to which components? What had changed since yesterday?

Initially, I copied individual file snippets. Then files. Soon I copied multiple files. Then repository tree structures files. Eventually I generated complete project exports so a new conversation could rebuild its understanding of the current codebase before any engineering discussion even began.

Each iteration reduced friction, but none eliminated it. My first assumption remained straightforward: I needed to provide better technical context.

Reconstructing the Engineering Process

Eventually those repository exports became surprisingly comprehensive. The assistant understood the software. Yet productive engineering still did not resume immediately. A different reconstruction now began. Which sprint are we currently in? What did we finish last week? What architectural question are we trying to answer? Which alternatives have already been rejected? What is the next engineering objective?

None of these questions were answered by the repository itself. The software described what existed; it did not describe where the engineering process currently stood.

So I created more artifacts: sprint documentation, engineering journals, architecture analyses, solution documents, and project exports. Again, every improvement reduced the amount of repeated explanation. Again, every new conversation still required reconstruction. Though, at this point I still believed I had a documentation problem.

Reconstructing the Collaboration

Then I noticed something even stranger. Even after reconstructing both the repository and the engineering process, the collaboration itself no longer behaved the same way. The assistant had partially forgotten how we worked together. Every fresh conversation required another round of calibration. Work in small incremental steps. Don’t overengineer. Don’t overexplain. Challenge assumptions instead of accepting them. Keep the current sprint objective in focus.

These weren’t project requirements, and they weren’t software artifacts. They were working principles our collaboration had accumulated over weeks of engineering together — and most of them disappeared every time the conversation ended.

Three Problems, One Pattern

At first glance, these three problems appeared unrelated. The repository, the engineering process, and the collaboration seemed to belong to completely different domains. We treated them as separate continuity problems until one simple observation connected them all.

The breakthrough did not arrive as a new architectural idea. It arrived as an uncomfortable question: Why did every new conversation begin with exactly the same reconstruction process?

I believed I was restoring different kinds of information — first the repository, then the engineering process, then the collaboration. But looked at more carefully, none of these reconstruction steps were actually about history.

When I explained the repository, I never replayed every commit that had produced it. When I explained the current sprint, I never revisited every design discussion that had led to the current objective. When I recalibrated our collaboration, I never reconstructed every previous conversation to justify why I preferred one working style over another. I always described only one thing: where we currently were.

That observation was subtle enough to overlook, yet once I noticed it, it became obvious.

Conversations are Evidence

For quite some time, I believed the problem was simple. Large engineering conversations eventually exceeded the available context window, and everything outside it was effectively forgotten. If continuity was disappearing, the obvious solution seemed to be preserving more of the conversation.

I explored exactly that direction: exporting complete chats, generating conversation summaries, extracting knowledge, and carrying increasingly large context packages into new sessions. It was a perfectly reasonable assumption. If the knowledge lived inside the conversation, preserving more of the conversation should preserve continuity.

Yet something never quite fit. Whenever I started a new engineering session, I never replayed the entire conversation. Instead, I described where the project currently stood. That raised another possibility. The conversation certainly contained the knowledge. But perhaps preserving the conversation wasn’t the best way to preserve that knowledge.

Perhaps conversations weren’t what we should be preserving at all.

Reframing the Challenge

Once that possibility appeared, the investigation changed direction almost immediately. Instead of asking:

How can I preserve previous conversations?

I began asking something much simpler:

What information do I actually need before engineering can continue?

The difference between those questions seems almost insignificant, but in practice, it changed the entire investigation. The first question treats conversations as the artifact; the second treats conversations as evidence. That distinction would eventually lead me toward an idea that computer science has relied on for decades.

Back to Computer Science First Principles

The answer appeared only after we started looking at the engineering process through the lens of computer science. The idea wasn’t new. Long before modern AI systems, computer science had already learned that execution resumes from state, not from history. Operating systems, compilers, databases, and distributed systems all rely on the same principle. Again and again, the same pattern appeared: systems continue from state, not from history.

History explains how the current situation emerged. State enables execution to continue. The distinction had always been there — we had simply never applied it to Human–AI engineering.

History Explains, State Enables

The breakthrough was not the word state itself—every software engineer already understands the concept. The breakthrough was recognizing that software engineering behaves exactly like every other stateful system. Engineering does not continue from everything that happened. It continues from the condition that currently exists.

That single observation immediately explained every reconstruction ritual I had performed. When I restored the repository, I was restoring the current state of the software. When I restored the sprint, I was restoring the current state of the engineering investigation. When I recalibrated our collaboration, I was restoring the current state of how we worked together. These were never three independent problems. They were three different manifestations of exactly the same phenomenon. I wasn’t trying to recover conversations; I was trying to recover the state from which engineering could continue.

Everything suddenly aligned. What had started as a practical frustration about restarting conversations ultimately became a question about state. And once I accepted that change in perspective, the next question became unavoidable:

If engineering resumes from state, what exactly is that state?

The Three States We Kept Reconstructing

That question turned out to be far more practical than theoretical. Rather than starting with a definition of Engineering State, I observed what repeatedly happened every time productive work was interrupted.

Every new conversation became an experiment, revealing which information we immediately felt compelled to reconstruct before engineering could continue. Over time, a surprisingly stable pattern emerged. The information always fell into three distinct categories.

1. The Current Technical State

The first category described the current technical state of the project. The repository and the accompanying project documentation captured what had already been built and which architectural decisions defined the system as it existed today. They described the current state of the system—not the history that had produced it. All of this information certainly evolved over time, but it evolved independently of individual conversations. It remained true whether we continued the project tomorrow or six months later.

Eventually, I stopped thinking of these artifacts as context. They represented something much more fundamental: the durable engineering truth of the project. The continuity problem had never started there.

2. The Current Engineering Process State

The second category looked completely different. Whenever engineering resumed, the first questions were almost never about the software itself. Instead, they sounded like this:

• What exactly are we trying to understand?
• Which architectural question is still unresolved?
• Which assumptions are we currently operating under?
• Which alternatives have already been rejected?
• What convinced us yesterday?
• What should we do next?

None of these questions belonged in the repository or in architecture documentation. They described the engineering progress while it was still under development. For example, within a few pages, a typical engineering conversation might contain architectural decisions that remain valid for years, brainstorming sessions abandoned ten minutes later, temporary misunderstandings, rejected alternatives, debugging detours, implementation experiments, and explanations that become obsolete almost immediately. A typical sequence looks something like this:

> Let’s try approach A.

> Actually, maybe B.

> Wait, we found the real problem.

> Forget both.

> Let’s do C.

The conversation preserves every step equally well. The project, however, only preserves C.

Unlike Engineering Truth, this information changes constantly—sometimes several times during a single day. It represented the operational state of the engineering effort itself: the Current Engineering State (CES).

Following this approach, I could clearly separate what the project was from where the engineering process currently stood. That distinction alone eliminated a surprising amount of unnecessary reconstruction.

3. The Assistant Collaboration State

There was still one category that did not fit either of the first two. It had nothing to do with the software, and nothing to do with the current engineering objective. It described the collaboration itself.

Over weeks of working together, we had gradually developed our own way of engineering—not through explicit planning, but through continuous course correction. Work in small incremental steps. Explain architectural reasoning before implementation. Challenge assumptions. Avoid unnecessary abstraction.

There was one situation, when I interrupted an implementation with a deceptively simple question, because it didn’t seem like good architecture to me:

Me: „Why are we actually doing this?“

Occasionally, the answer was unexpectedly honest:

ChatGPT: „Actually, I don’t know anymore.“

Those moments were never failures. They were often the most valuable engineering reviews of the project, forcing both of us to distinguish genuine architectural reasoning from habits we had simply carried forward without questioning them.

None of this belonged in the repository or in the Current Engineering State. It captured the accumulated knowledge of how we collaborated: the Assistant Collaboration State (ACS). It captured neither what we were building nor where the engineering currently stood—it captured how we had learned to build it together.

Continuity in Human-AI Engineering

Looking back, the separation felt almost inevitable.

Engineering Truth answered: What is true about the software?

Current Engineering State answered: *Where does the engineering currently stand?

Assistant Collaboration State answered: How do we collaborate most effectively?

Each represented a different kind of continuity. Each evolved independently, and each required its own representation. For some time, however, I had tried to preserve all three inside conversations. That explained why conversations were simultaneously so valuable—and so difficult to use.

State	Primary Question	Purpose	Character
Engineering Truth (ET)	What is true about the project?	Stores the project’s long-term engineering knowledge and serves as the authoritative reference.	Reference
Current Engineering State (CES)	Where are we in the project?	Captures the current operational snapshot required to resume engineering work efficiently.	Snapshot
Assistant Collaboration State (ACS)	How do we work together?	Preserves the established collaboration model, working principles, and interaction patterns between human and AI.	Constitution

A conversation mixes durable architectural knowledge with temporary hypotheses, active investigations, abandoned ideas, implementation details, collaboration habits, moments of confusion, and spontaneous insights. Every new engineering session therefore began with the same hidden task: separating what still described the current situation from what merely described how we had arrived there.

Though, the conversation had never been the structure; it merely contained fragments of it. That realization changed the role of conversations completely. Initially, conversations had been the artifact I wanted to preserve. Now they became something else: evidence.

Conversations were still invaluable, but their role had simply changed. Evidence explains why the current state exists; the current state explains how engineering continues. A laboratory notebook is not the experiment. A Git history is not the current repository. Likewise, a conversation is not the engineering state—it is one source from which that state can be reconstructed.

Once I adopted that perspective, an architectural consequence appeared almost immediately: if conversations are evidence, then preserving them cannot be the primary responsibility of the continuity system. Something else has to become the authoritative artifact.

State as the Canonical Artifact

That „something else“ was the operational state itself—not a prompt, not a conversation, and not a summary, but a canonical engineering artifact composed of Engineering Truth, Current Engineering State, and Assistant Collaboration State. Those representations should exist independently of any particular language model, prompt, or interaction mechanism. Prompts should not be the engineering state; they should simply be one possible representation of it.

That observation quietly removed another assumption I had carried for months: I wasn’t designing a better prompt, but rather an engineering artifact that could outlive any particular prompt.

The Architecture Almost Designed Itself

Once the canonical representation became the center of the system, the remaining architecture required remarkably few design decisions.

The first responsibility was analytical: take conversations, project artifacts, engineering documents, and every other available source of evidence to reconstruct the Engineering Truth, Current Engineering State, and Assistant Collaboration State, discarding everything that no longer contributes to the current operational state.

The second responsibility was transformational: take those canonical representations and generate whatever a particular execution environment requires. Today, that might be an initialization prompt for a language model; tomorrow, it might be a completely different interface.

The important observation was that neither transformation changed the engineering state itself. One reconstructed it; the other compiled it into an execution-specific representation. Only much later did I give these responsibilities names: Analyst and Compiler. By then, they no longer felt like architectural inventions. They were simply the natural consequences of one decision:

If continuity depends on state, every component should either reconstruct state, preserve state, or transform state—and nothing else.

Reframing Core Paradigms

A Better Way to Think About Prompts

Earlier in the project, prompts had quietly become my continuity mechanism. Every new conversation began with an increasingly sophisticated initialization prompt covering repository overviews, current sprints, architecture principles, working agreements, and collaboration preferences. Each revision made the next conversation noticeably better, so I invested considerable effort into refining those prompts.

Looking back, I had unknowingly optimized the wrong artifact.

Once operational state became explicit, that relationship reversed. The prompt was no longer something we carefully preserved; it became something I could generate. Prompt engineering remained valuable, but it simply moved to the edge of the architecture. The prompt was no longer the source of continuity—it became one possible execution format for the engineering state.

A Better Way to Think About LLM Memory

The same shift fundamentally changed how I thought about LLM memory. Most discussions around LLM memory begin with a familiar objective: How can the model remember more? Longer context windows, persistent memory, conversation retrieval, and archived chat histories all improve access to previous information.

My investigation suggests a different objective: perhaps memory should not primarily remember conversations, but rather maintain the current state of an ongoing engineering process.

Those are fundamentally different responsibilities. One accumulates history; the other maintains operational readiness. History continues to exist, but it simply stops being the primary continuity artifact. Memory is no longer responsible for preserving everything that happened; its responsibility is to preserve the state from which engineering can continue.

Continuity is preserved not by maximizing context, but by preserving only the state required to continue the work.

Continuous Engineering with AI LLM Assistants

Looking back, it is tempting to describe Engineering Truth, the Current Engineering State, the Assistant Collaboration State, the Analyst, or the Compiler as the contribution of this work. They are not. All of them are consequences.

The actual discovery happened much earlier, the moment I realized that every interruption triggered exactly the same behavior. I never asked „What did we talk about when?“—I asked „What’s next?“

Every engineering investigation leaves behind more than software; the most valuable ones leave behind a better way of thinking. For me, this project fundamentally changed what continuity means. I no longer think of continuity as successfully remembering the past, but as accurately preserving the present.

History still matters. It explains, teaches, and justifies. But engineering never resumes from history—it resumes from the state that exists now.

That distinction seems almost trivial once it has been seen. For months, however, it remained invisible. What started as a practical frustration about restarting conversations ultimately became a different way of thinking about long-running Human–AI engineering:

Don’t preserve conversations. Preserve state.