Third Moment Research reports that its agents can maintain computational investigations for 36 to 48 hours. During these sessions, agents work with code, execute simulations, interpret results, and decide which experiments to conduct next. The company uses GPT-6 models with the Codex harness, including its context-compaction capabilities, to support these extended investigations.
A 48-hour execution creates a state-management problem that conventional conversational AI applications rarely encounter.
Consider an agent tasked with improving the performance of a trading strategy. It begins with an existing implementation, examines historical data, proposes an alternative approach, and executes a backtest. The first experiment fails, so the agent modifies its hypothesis and tries again. After several iterations, it identifies a promising configuration and launches additional experiments to test its stability.
By this point, the agent may have generated thousands of lines of code, large volumes of simulation output, and an extensive history of intermediate decisions. Only a small proportion of that information is required to reason about the next experiment, but much of it remains necessary to verify or reproduce earlier results.
The problem is determining what should remain in the model's active context and what should be preserved elsewhere.
Context compaction solves only part of the problem
A model's context window determines how much information can be included in a particular inference request. When an agent runs for an extended period, repeatedly including every earlier interaction becomes expensive and eventually impractical.
Context compaction attempts to address this by replacing parts of the accumulated interaction history with a more concise representation.
Instead of carrying the full transcript of 100 experiments, the agent might retain a summary of the objective, rejected hypotheses, current findings, and next planned steps.
This can substantially reduce the information the model needs to process during subsequent decisions.
The trade-off is information loss.
Imagine that an agent summarizes a previous result as follows: a momentum-based strategy improved historical returns after adjusting the feature window.
That statement may be sufficient to guide the next line of investigation. It is not sufficient to reproduce the experiment. The summary omits the exact feature definition, the input dataset, the source-code revision, the training interval, transaction-cost assumptions, and the evaluation methodology.
If the agent later needs to verify the result, the compressed context cannot serve as the source of truth.
This is why conversation memory and durable execution state must be treated as different parts of the system.
Three kinds of state in an autonomous research system
A robust design separates the information needed for reasoning from the information needed for operational recovery and scientific reproducibility.
| State category | Information retained | Primary purpose |
|---|---|---|
| Conversational state | Objective, working hypotheses, relevant findings, next actions | Help the model reason |
| Execution state | Task status, worker assignments, dependencies, retries, deadlines | Manage and recover execution |
| Research state | Code revisions, data versions, parameters, metrics, output artifacts | Reproduce and validate results |
The conversational state may be compacted frequently. Execution state generally needs to be durable and updated whenever a task changes status. Research state should preserve the evidence used to accept or reject hypotheses.
These categories can reference one another without residing in the same storage system.
For example, the model's context might contain a short summary of the five most promising experiments, together with identifiers that allow it to retrieve their full results when necessary.
The investigation remains coherent because the model does not need to remember every detail. It needs to know which details exist and how to retrieve them.
What should an experiment record contain?
For computational research, every experiment should ideally produce a structured record that allows another execution to reconstruct what happened.
A simplified record could look like this:
{
"experiment_id": "exp_042",
"parent_experiment": "exp_037",
"objective": "Evaluate alternative trading signal",
"status": "completed",
"code_revision": "commit_abc123",
"dataset_version": "marketdata_v12",
"configuration_artifact": "s3://research/exp_042/config",
"result_artifact": "s3://research/exp_042/results",
"evaluation_status": "pending_independent_validation",
"next_action": "run_out_of_sample_test"
}
This is an illustrative schema, not a Third Moment implementation.
The important property is that the record contains durable references to experimental inputs and outputs. It does not depend on a language model reconstructing them from memory.
A replacement agent can retrieve the relevant artifacts, inspect the previous results, and continue the investigation without repeating work that has already been completed.
Checkpointing versus event replay
There are two related approaches to recovering long-running execution.
Checkpointing periodically saves a snapshot of the state required to resume work. Event replay reconstructs state by processing a durable sequence of recorded operations and outcomes.
Both approaches have advantages.
Checkpoints can reduce recovery time by avoiding the need to process an entire execution history. Event histories provide a more detailed record of how the system reached a particular state.
A long-running research platform may use a combination of the two.
Figure 2: Recovering a research investigation after worker failure
flowchart TD
A["Agent Executes Experiment"] --> B["Write Results to Artifact Store"]
B --> C["Record Completion Event"]
C --> D["Update Execution State"]
D --> E["Begin Next Experiment"]
E --> F{"Worker Survives?"}
F -->|"Yes"| G["Continue Investigation"]
F -->|"No"| H["Start Replacement Worker"]
H --> I["Load Durable State"]
I --> J["Retrieve Previous Artifacts"]
J --> K["Restore Relevant Context"]
K --> G
The order of operations matters. If a worker produces an output artifact but fails before recording completion, the replacement process must determine whether the operation actually succeeded.
Otherwise, recovery can duplicate work or create inconsistent results.
Distributed workflow systems address related problems through durable event histories and carefully controlled side effects. Temporal, for example, separates deterministic workflow execution from external activities such as API calls and model invocations. Recorded activity results can be reused during workflow replay rather than regenerated.
Why model calls complicate deterministic recovery
Traditional workflow replay relies on the ability to reconstruct prior execution from recorded events. Language-model inference introduces nondeterminism because the same request does not necessarily produce an identical response every time.
Suppose an agent previously selected hypothesis B over hypotheses A and C. If the system crashes and simply asks the model to make that decision again, it may select a different hypothesis.
That is not necessarily a model failure. It is a problem with using nondeterministic inference to reconstruct historical state.
A safer implementation records the decision that was actually made. During recovery, the system can reuse the recorded decision rather than asking the model to regenerate it.
Fresh model inference should occur when the workflow reaches a genuinely new decision point.
This also makes execution easier to audit. Engineers can distinguish decisions made during the original investigation from those made after recovery.
When should an agent forget?
The objective is not to maximize how much information an agent remembers. It is to retain the information necessary for correct decisions while keeping the active context manageable.
A practical compaction strategy might preserve:
- The current objective and explicit completion criteria.
- Accepted and rejected hypotheses, with references to supporting artifacts.
- Important environmental constraints and permissions.
- Unresolved questions and pending operations.
- The next decision the agent needs to make.
Large datasets, verbose tool responses, and completed experiment outputs can remain in durable storage until needed.
There is a corresponding validation problem: a compressed summary may misrepresent an earlier result. For important decisions, the agent should retrieve the original evidence rather than relying exclusively on its summary.
What Third Moment demonstrates
Third Moment's case study confirms its use of context compaction and extended research sessions. It does not disclose the exact persistence, checkpointing, or replay mechanisms used internally.
Nevertheless, its workload illustrates why these mechanisms matter. As autonomous investigations extend from minutes to days, the model's context becomes a working memory rather than the permanent record of execution.
A reliable agent must be able to lose its immediate execution process without losing the investigation itself.
Sources: OpenAI — Third Moment Research · Temporal — Workflows
Related: Inside the Architecture of 10,000 Agents | Agent Failure Recovery