The forked_debug pattern
Most long agent failures are not uniformly bad. A useful prefix is followed by one poor tool choice, one malformed input, or one model decision that sends the run down the wrong branch.
The forked_debug pattern treats that divergence point as the place to work.
1. Inspect the failure
tine show failed.tine
tine verify failed.tine
Find the last step whose inputs, outputs, and provenance you still trust. Verification establishes that the artifact you are inspecting matches its recorded digest; it does not certify that the agent's decision was correct.
2. Fork the known history
tine fork failed.tine --from-step 3 --save retry.tine
The fork carries the ancestor graph through the selected step. What happens next depends on the native runtime or harness you use to continue. opentine does not invent missing execution state from a plain trace.
Since v0.4, repeating this fork from the same point creates a different default run ID. The retained history is shared, but each intervention is independently addressable. Automation should use the returned ID or an explicit --save destination rather than predict a filename.
3. Replay or rerun explicitly
Use cache mode when the goal is to materialize recorded work without repeating model or tool calls:
tine replay failed.tine --mode cache --save replayed.tine
Use rerun mode only with the runtime or harness needed to execute the new branch. This distinction keeps “reused evidence” separate from “new execution.”
4. Diff the result
tine diff failed.tine retry.tine
Since version 0.2, diff aligns lineage positions and reports field-level changes. You can see whether the repair changed the prompt, selected model, tool inputs, output, error, usage, or cost.
Why the pattern works
Debugging becomes a graph operation instead of a ritual rerun. The preserved prefix explains what both attempts had in common. The branch records the intervention. The diff makes the consequence legible.
The result is not merely a successful second attempt. It is a pair of portable artifacts that show where the failure occurred and what changed when you fixed it.