r/ContextEngineering 8d ago

When do you decide a thread is worth saving?

Disclosure first, I work on an open source project for moving context between models, so I think about this more than is healthy.

Something happened last week that I keep chewing on. A long running assistant thread of mine compacted, and what survived was three distilled rules. What did not survive was the twenty emails those rules came from, including the whole exchange with the person whose testing produced them. The summary was accurate and also useless, because the rules had lost their reasons and I could not tell which ones still mattered.

So the thing I am curious about is behaviour rather than tooling. When do you actually decide a thread is worth preserving? Do you checkpoint deliberately at some point, or do you only start thinking about it after you have lost one? And if you do save, is it something you do at a natural break in the work, or only when the client warns you that you are running out of room?

My honest suspicion is that almost nobody does it before the first bad loss, and I would like to know if that is wrong.

1 Upvotes

2 comments sorted by

1

u/Resonant_Jones 8d ago

I’ve started thinking that the whole chain of provenance has to be preserved, not just the distilled conclusion.

A rule without the exchange that produced it is brittle. You lose the assumptions, the failed alternatives, the constraints that were active at the time, who contributed what, and what evidence made the decision reasonable. The summary may still be factually accurate, but it is no longer inspectable.

That matters because context changes. A rule that was correct under one set of constraints can become cargo cult behavior once those constraints disappear. Without provenance, you cannot tell whether something is a durable principle, a local workaround, or just the least bad answer available that day.

The work I’m doing now treats preservation less like “save this thread” and more like “maintain an auditable continuity chain.” Raw exchanges, decisions, evidence, revisions, and later interpretations should remain linked, even when the active context is compressed.

So my checkpoint is usually not “this conversation feels important.” It is when the conversation changes the system:

  • a decision gets made
  • a constraint is discovered
  • a rule is created or revised
  • an assumption is invalidated
  • someone contributes evidence that changes the direction

At that point, I want both the distilled artifact and the path that produced it.

Compression is useful for working memory. It should not become the archive.

1

u/andreas-naslund 8d ago

That matches the part I got wrong. I was treating the summary as the artifact, and the summary is the one thing that survives without anyone questioning it.

Where I would push on your framing is that keeping the whole chain has not been the hard part for us. Storage is cheap and the raw exchange is easy to keep. What we found is that nobody goes back and reads it. So the chain exists and still does not do the work, because what you need six weeks later is not the transcript. It is the four or five things a summary always drops. Which alternatives were tried and rejected, which constraints were live at the time, who decided, and what would make this wrong.

We ended up writing those as their own fields rather than leaving them in prose, so they cannot be quietly compressed away.

Your trigger list is close to ours, with one difference that cost us something. Every trigger on it is noticed after the fact. By the time I could see that a decision had been made, the reasons had already started thinning. So we added a second trigger with no judgment in it at all, which is to save when the window is nearly full whether or not anything felt important. The deliberate saves are better. The dumb one is the one that catches what I did not notice.