Context is not memory

Before getting into the problem, it is probably worth explaining what HART and AURIC are in this context.

They are long-running autonomous agents with persistent roles and distinct personalities. HART is responsible for carrying out work across extended engineering tasks. AURIC is responsible for judgement, challenge and deciding whether the evidence is sufficient to continue.

They are not intended to behave like disposable prompts.

They are designed to retain identity, operating principles and responsibilities across work that can last for hours and move through multiple stages. In practice, that means they are much more exposed to the limits of context than a conventional question-and-answer interaction.

That is what made the problem in this paper visible.

We were asking the agents to behave persistently while the underlying model context remained temporary.

I have been spending a lot of time recently working with models on tasks that do not fit neatly into a single prompt.

Not writing a function or summarising a document, but work that carries on for hours. Investigating failures, comparing evidence, changing code, checking outputs, going back to decisions made earlier and continuing until the problem is either resolved or understood well enough to make the next decision.

When you work this way, the conversation gives you a strong sense of continuity. The thread is still there. The model appears to remember what happened earlier. It can refer back to previous decisions and usually carry enough of the shape of the problem forward to continue.

The problem starts when the context becomes too large.

At that point, older parts of the conversation have to be summarised, compacted or retrieved selectively. Most of the time this works well enough that you barely notice it. The model still understands what you are trying to do and can often continue without obvious failure.

What becomes much harder to know is whether the detail that mattered earlier is still there in the same form.

I ran into this again recently during a long investigation. The work depended on comparing several exact outputs from earlier in the thread, together with their instructions, references and some fairly small implementation details. None of these things looked particularly important in isolation, but the conclusion depended on them being compared exactly.

By the time we returned to that part of the work, the context had already been compacted.

The model had not suddenly become incapable. It still understood the problem. Most of the surrounding reasoning was still correct. What had changed was that I could no longer assume that the complete state of the investigation was present in the context in exactly the form in which it had originally been established.

For long-running engineering work, I think this is a much more important problem than it first appears.

It is also one we have been trying to solve while building Harten.

A lot of the work I have been doing with HART and AURIC happens over extended periods. We may investigate a failure, inspect a repository, generate evidence, make a decision, change something, discover a new constraint and then return to an earlier assumption several hours later.

Initially, the obvious answer was to preserve as much context as possible. Keep the conversation going. Maintain summaries. Carry forward the important decisions. Rehydrate the context when a new session starts.

That approach is useful and I still think there is a place for it, but it has an important weakness. A summary is already a judgement about what mattered at the point it was written. If the work later depends on something that looked insignificant at that point, the summary may not contain it. If that summary is then summarised again, the distance from the original evidence increases further.

The broad understanding can survive while the precision required for the next decision slowly degrades.

That has pushed us towards treating persistence as a systems problem rather than a prompting problem.

Instead of relying on the model to retain everything that matters, we have been moving consequential state outside the conversation.

Some of that is relatively straightforward. Repository state can be tied to exact commits. Evidence can be preserved independently of the conclusion drawn from it. Decisions can point back to the artefacts that informed them. A working hypothesis can remain a working hypothesis rather than quietly becoming accepted truth because it appeared repeatedly in the conversation.

Git-Hart is one of the places where we are trying to make this more explicit.

Git already gives software engineering a very strong model for persistence. A commit refers to an exact state of the repository. A ref gives that state something durable to point to. History can be inspected later without asking someone to remember what happened.

AI-assisted engineering creates a lot of additional state around that source code which is much easier to lose.

Why was a change proposed? Which evidence led to it? Which exact version of the application was being inspected? Which assumptions were still unresolved? What did a human actually approve? Which specification was the change being made against?

Today, a surprising amount of that can still live inside a conversation.

That is fine while the conversation is available and the relevant context is still active. It becomes less satisfactory once the work is expected to continue over longer periods, move between models or agents, survive context compaction, or be inspected by somebody who was not present when the decision was made.

This is partly what we are trying to address through proposals and refs in Git-Hart.

The intention is not to store conversations in Git. It is to identify the parts of the conversation that became consequential and give them a more durable representation.

A proposal should be something that can be inspected later. The evidence behind it should still be available. The state of the system it referred to should be exact rather than reconstructed from a summary. If the proposal was rejected, that should remain part of the history rather than disappearing because the conversation moved on.

The same principle applies more broadly to HART and AURIC.

HART can carry out work and AURIC can judge the evidence around it, but neither should require an uninterrupted conversation to understand what has already happened. If the system needs the human to explain the history again every time the context disappears, then the persistence is still sitting with the human.

Larger context windows help with this, but I do not think they remove the underlying problem.

They allow more of the working material to remain available at once and reduce how often compaction is required. That is useful. But they do not tell the system which information is current, which decision has been superseded, which statement is evidence rather than inference, or which unresolved question should still constrain the next action.

Those are properties of the system around the model.

I have started to think of the context window less as memory and more as the working surface the model needs for the decision it is making now.

The durable memory sits elsewhere.

That memory does not have to mean storing everything forever. In fact, doing that would probably create a different version of the same problem. The important part is deciding what has become durable enough that future work should not depend on somebody remembering it correctly.

For software engineering, exact repository state is clearly in that category. So are accepted decisions, evidence behind consequential changes, unresolved risks, specification versions and the history of what was proposed and rejected.

This is becoming increasingly important as models move from answering questions to participating in work that lasts longer and has real consequences.

A useful test is simply whether the current model can disappear.

If another model, another agent or another engineer can pick up the work and recover enough of the state to understand what happened and why, then the system has some persistence of its own.

If the answer still depends on the previous conversation being intact, then most of that persistence was temporary.

That is the problem we have been trying to reduce.

The context window remains extremely useful, but I no longer think it is a sensible place to keep the things a long-running engineering system cannot afford to lose.

---

The complete Harten papers archive is available at harten.io/papers.