Updated
Keep the investigation outside the context window
Durable evidence, focused agent sessions, and explicit workflow stages make long research tasks easier to resume and verify.
A long investigation produces more than a conclusion. It leaves build commands, failed inputs, source references, test results, and hypotheses that have already been ruled out.
When that record lives only in a model’s conversation, summarization can lose the detail needed to continue. A new session may repeat a failed approach or mistake an untested idea for an observed result.
Niels Provos’s IronCurtain work prompted us to examine this part of our own research workflow. This is an architectural reflection on that work, not a claim that changing orchestration makes every model equally capable.
Separate durable evidence from working memory
An investigation journal should preserve what actually happened: the command, target revision, output location, and outcome. Keep a hypothesis distinguishable from a completed test.
A specialist session can then load the part it needs. A verifier may need the reproducer and build instructions. A source reviewer may need the suspected path and surrounding invariants. Neither necessarily needs the entire conversation that produced the lead.
The journal still requires care. An append-only record can faithfully preserve a mistaken conclusion. Link conclusions to evidence, and make later corrections visible rather than silently replacing the earlier account.
Make transitions explicit
A workflow can describe when an investigation is ready to move from source review to harness construction, execution, verification, and reporting. The representation might be configuration or code; the important property is that each transition has a checkable condition.
A generated reproducer shouldn’t advance to verified merely because the agent saved a file. The next stage needs to run it and inspect the result. A build error should remain a build error throughout the record.
Clear stage boundaries also help with recovery. After a worker stops, the next worker can see the last completed step and the artifacts it produced.
Increase the realism of the harness deliberately
A small function-level test can quickly check a suspected arithmetic condition. A component harness can include parsing and object setup. A full application or VM can test reachability under realistic configuration.
Each level answers a different question. A direct function call may demonstrate a defect while bypassing the checks that protect a public entry point. Moving to the larger harness tests whether those checks change the result.
This makes partial progress useful without overstating it. Preserve the smaller result and name what the next level still needs to establish.
Compare the whole investigation cost
Token spend is only one part of the cost. Repeated builds, failed setup, duplicate work, and human review also matter. Track them alongside the outcome and the evidence produced.
A model comparison needs the same targets, budgets, access, and success rules. One successful demonstration doesn’t isolate the effect of a journal, a workflow format, or a particular model.
The practical design aim is an investigation another worker can resume and another engineer can audit. That is a concrete improvement even before a benchmark score changes.