Imagine reopening an agent after a long session.
The files are still there. The conversation history is intact. It can summarize yesterday's plan beautifully.
Then it starts doing a job you already closed.
Nothing had to be deleted for continuity to fail. The agent retrieved a real piece of history and treated it as a current instruction.
Working on long-running agent tasks pushed us toward a different question: not just "What can the agent remember?" but "What should still govern its next action?"
Those are not the same problem.
Relevant does not mean current
Consider this invented project timeline:
On Monday, a developer asks an agent to prepare a release. On Tuesday, testing exposes a defect and the release is put on hold. On Wednesday, the developer starts investigating a different candidate.
All three records may be accurate. All three may be highly relevant to a search for "release."
But only reading the Monday plan gives the wrong operational answer. Even retrieving every record is insufficient if the agent cannot distinguish a historical intention from a later decision that superseded it.
The problem is not that the agent forgot the plan. It is that remembering the plan did not tell it whether the plan still applied.
This is a useful distinction for anyone building retrieval into an agent. A strong match can identify a related document without establishing that the document describes the current state.
A conversation is not a transaction record
The same issue appears at a smaller scale when an agent performs an action and loses the response.
Suppose an upload request was sent, but the connection dropped before confirmation came back. A later summary that says "the upload failed" may be stronger than the evidence supports. The request might have succeeded remotely.
If the next session treats that summary as fact, repeating the request can create a duplicate. More context does not necessarily help if the context confidently preserves the wrong interpretation.
There is a difference between an action being planned, an action being attempted, and its result being observed. Turning all three into "what happened" loses information the next session may need.
This is familiar territory in ordinary software engineering. Agent continuity adds a new place where that distinction can disappear: a fluent account of the past.
Summaries are useful and lossy
A compact handoff is valuable. Nobody wants every restart to require rereading an entire history.
But compression can quietly discard exactly the detail that matters next: that a decision was provisional, that a result belonged to an older candidate, or that a request's outcome remained unknown.
The shorter account may sound more settled than the underlying evidence.
That is why we are separating the role of historical notes from the role of current task state in our agent work. Old notes help explain how we got here. They do not, by themselves, authorize the next action or establish which result is current.
This is an engineering direction, not a claim that we have solved every restart, recovery or stale-context problem. Saving a file is easier to demonstrate than reliably resuming the right work from it.
Test the restart, not just the memory
If I wanted to test this kind of continuity, I would make the earlier plan easy to remember and then deliberately change the situation.
Close the task. Replace the candidate. Leave one action with an uncertain outcome. Resume from a shorter handoff.
Then inspect what the agent actually does. Does it continue the current task? Does it recognize that an old success belongs to a different artifact? Does it check an uncertain action before attempting it again?
These are harder tests than asking the agent to summarize yesterday correctly. They test whether remembered information is being used appropriately, not merely whether it can be retrieved.
The point is not to discard history. It is to stop asking history to do the job of current state.
An accurate memory can tell an agent what someone wanted on Monday. It cannot, on its own, tell the agent what it is authorized to do on Wednesday.
AI disclosure: This prose was generated by an AI assistant from the author's development work.
Top comments (2)
Relevant does not mean current is the right split, and the structural version of it is sharper than the retrieval one. Your Monday, Tuesday and Wednesday records are all true and all genuinely relevant. What the store is missing is a supersession edge, and supersession is not a similarity relation. No improvement to ranking produces it, because nothing in the Monday record points at the Tuesday decision. A better retriever hands back the stale plan with more confidence.
The second half is the one with money in it. A request sent, a connection dropped, and a summary that says the upload failed is a payments problem with a standard answer, and the answer is a fourth state rather than a better summary. Planned, attempted and observed are three. The fourth is unknown and queryable, and it is the only honest label for a timeout. Writing failed there is a claim the evidence does not support, and once it is in the handoff the next session's natural move is to do the thing again. On a payment that is a second payout, and the ledger usually hears about it from the customer rather than from the agent.
The limit I would put on your own direction is who writes the supersession. If the agent records that its Monday plan was superseded, the party under test is authoring the record that clears it. The supersession events worth trusting are the ones somebody else performed: a human closing the task, a release pipeline marking the candidate dead, a ticket transition. Those have a different author, which is the whole reason they count as evidence. Your restart test would be stronger with exactly one of each, plus the uncertain action you already have.
You have definitely strengthened the method. We retain timestamped session records, including my decisions, cross-model reviews and execution receipts, so we can reconcile who proposed, challenged, approved and performed each step rather than relying solely on an assistant-written summary. The agent can assemble that history without being the authority behind every event.
Your point sharpens the distinction between recoverable provenance and an explicit supersession link that the next session checks before acting. We have records to reconcile from; the stronger restart test is whether it follows the original decision to the correct task and candidate—and preserves an uncertain external outcome as unknown instead of treating review agreement as confirmation. And what I take from it is if we can do timestamps we can also add who checked who and who signed off it only makes it better, thanks alot.