On September 12, Simon Willison asked ChatGPT Work to generate local 5K and 10K running routes from OpenStreetMap data.
It worked for 27 minutes and returned an embedded map, a GPX file and a GeoJSON file. It reported that it had geocoded the address, queried road and trail data, and computed the loops locally.
The task succeeded.
Later, Willison asked for the Python code that had produced the routes.
The system could not provide it.
He suspected that the thread had been compacted. That does not prove the code had been deleted. It does establish something narrower and more useful:
the work was complete, but part of the execution record was no longer available to the user.
That is a different kind of failure.
Call it success without reconstructability.
A second incident shows the storage risk
A user report filed against Codex on September 10 describes a more severe failure at the storage layer.
The session had been running for roughly two months. Its rollout file had grown to about 851 MB across more than 122,000 records.
Importantly, compaction was not new.
The reporter counted 175 earlier compacted records while the full history remained intact.
Then one later compaction event rewrote the rollout in place.
The file fell to about 7.1 MB and 762 records. All 3,777 reported assistant messages disappeared. Only the 584 user messages remained inside replacement history.
The session still existed and still accepted new messages.
Its history had effectively vanished.
Recovery was possible only because a filesystem snapshot from twelve minutes earlier happened to exist.
This is a user report, not a vendor-confirmed failure rate. The conditions were also unusual: a very long-running thread, roughly three billion cumulative tokens and around 170 spawned subagent threads.
But the reporter's expected behavior captures the architectural issue precisely:
compaction should bound what the model carries forward in context.
It should not destroy the stored record.
The Willison case and the Codex report are not evidence of the same failure mechanism.
One describes work the user could no longer retrieve.
The other reports destruction of stored conversation history.
But both raise the same operational question:
after the agent moves on, what evidence remains available to establish what actually happened?
Working context and retained evidence are different decisions
Long-running agents cannot carry everything forward indefinitely.
They summarize, compact, fork, resume, hand off and discard information that is no longer useful for the next reasoning step.
That is necessary.
But the information required to continue a task is not the same as the information required to inspect a completed one.
Working context asks:
What does the agent need next?
Retained evidence asks:
What might someone need later to establish what happened?
Those are different retention decisions.
When they share the same lifecycle by default, token pressure can end up determining what remains reconstructable.
That is the design mistake.
Reconstructability is not the agent remembering
There is another distinction that matters.
Asking the agent afterwards, “What did you do?” is not evidence.
A model can produce a plausible retrospective explanation without retrieving the actual execution record.
Reconstructability requires something stronger:
someone who was not part of the original session should be able to inspect records captured during execution and establish what happened.
That does not mean preserving private model reasoning.
It does not mean rerunning a nondeterministic workflow and expecting identical output.
It means retaining enough operational evidence to answer concrete questions:
What code or commands ran?
Which tools were called?
What inputs and source versions were used?
What did those tools return?
Which external systems changed?
Which authorization covered the action?
When did the relevant events occur?
The evidence should support the explanation, rather than the explanation standing in for the evidence.
The record may not live in one place
This becomes harder when agents act outside the system that hosts them.
A tool-call log can show that an action was attempted.
It does not necessarily prove what happened on the receiving side.
An agent may issue an API request, modify a database, create a cloud resource or trigger a downstream workflow.
Some evidence exists where the effect landed.
That means the reconstructable record of an agent run may be distributed across several systems:
the agent runtime,
the tool layer,
the application,
and the systems that received the action.
A complete incident record may therefore require correlation, not merely a transcript.
Instrumentation helps, but it is not retention
Some current runtimes already expose useful hooks for this.
Qwen Code, for example, exposes structured fields such as session identity, transcript path, timestamp, permission mode, agent ID and prompt ID, as well as a pre-compaction event.
Codex 0.154.0 preserves authorization state through resume, fork and compaction and rejects approvals that later instructions invalidate.
These mechanisms do not solve evidence retention by themselves.
But they expose the kinds of state that can be captured outside conversational history.
That matters because some information is too important to depend on the survival of a thread.
Retaining everything is not the answer
An evidence record creates its own risk.
Agent traces may contain personal data, credentials, proprietary documents, customer information, tool outputs and intermediate artifacts.
Some of that material may need to be deleted under contracts, security policy or privacy law.
So reconstructability does not imply infinite retention.
Evidence needs its own policy:
what is retained,
for how long,
who can access it,
what can be redacted,
and when it must expire.
There is also a genuinely difficult engineering problem underneath this.
You often have to decide what to retain before you know which trajectory will later matter.
A routine workflow may become important only after a customer dispute, a downstream failure or an incident investigation.
The route-generation task looked ordinary while it was running.
The workflows that eventually need reconstruction are often the ones nobody classified as exceptional at the time.
There is no universal rule for that.
Reasonable heuristics exist: retain more around external state changes, code execution, authorization transitions, regulated data, financial effects and other consequential actions.
But the important point is that the policy should be explicit.
It should not emerge accidentally from whatever the context window could no longer hold.
The test
There is a simple test worth running against an agent system.
Take a completed workflow in a test environment.
Compact the session.
Restart it.
Fork it if the runtime supports that.
Then give the case to someone who did not participate in the original run.
Ask them to establish, using retained records:
what code or commands ran,
what inputs and sources were used,
what tools were called,
what changed outside the session,
and which authorization covered the action.
Record the gaps.
That is a stronger test than asking the original agent to explain itself.
Successful output is one acceptance criterion.
Independent reconstructability is another.
A successful agent run should leave enough independently accessible evidence to inspect the work for as long as policy requires.
Context pressure may decide what the agent sees next.
It should not decide what remains available to inspect.