opentine: Why the Fork Primitive Matters
Most agent frameworks record runs as opaque linear traces. opentine models them as content-addressed DAGs you can fork, replay, and diff — like git for agents.
What is the fork primitive?
Most agent frameworks today record a run as an opaque stream of messages and tool calls. When something goes wrong on step 37, your options are narrow: read back the trace, guess at the cause, and re-run from scratch with a tweaked prompt. Every iteration burns a full run of tokens and wall-clock time.
opentine takes a different primitive. Every step in a run is a content-addressed node in a DAG. Inputs, outputs, tools, and model choices are all hashed into a stable step ID. This means two things that compose into something powerful:
- You can resume from any step. Pause at step 12, walk away, pick up on a different machine three hours later. Steps are portable.
- You can fork from any step. Take step 12's state, branch it, change the next prompt, and run a new path in parallel. The original tree stays intact.
Why this changes the debugging story
The ordinary agent-debugging loop looks like this:
| Problem | Typical framework | opentine |
|---|---|---|
| Agent took a wrong turn at step 37 | Re-run from scratch with tweaked prompt | Fork from step 36, try the alternative |
| Need to compare two strategies | Run twice end-to-end | Fork once, diff the two subtrees |
| Deterministic regression after code change | Hard to reproduce faithfully | Deterministic replay from any checkpoint |
| Expensive step you want to reuse | Re-run from scratch or bolt-on caching | Resume from any saved step; content-addressing enables deterministic reuse |
Fork-as-a-primitive collapses the cost of iteration. You stop paying for the happy-path steps every time you want to experiment with the unhappy ones.
What it looks like in practice
tine run research-agent.py --input "summarize these 40 papers"
tine show abc123 # inspect the run tree
tine fork failed_run.tine --from-step 36 --save forked.tine # branch from a specific step
tine diff abc123 def456 # side-by-side comparison of two runs
tine replay abc123 --from-step 12 # deterministic replay from a checkpointEach command operates on the content-addressed DAG that the run produced. No magic, no proprietary cloud — it's a local .tine file you can check into a repo or ship to a colleague.
The shape of what's next
Fork is the primitive that unlocks everything above it. Autoresearch, supervised multi-agent systems, and reproducible eval harnesses all reduce to the same question: can I branch execution cheaply? We're building each of those on top of the same kernel.
More posts in this silo will cover the universal model adapter layer, the event-sourced kernel design, and how the three opentine consoles (TUI, desktop, browser) compose on the same underlying API.
More from opentine
Content-Addressed Steps: How opentine Guarantees Bit-Exact Replays
opentine hashes every agent step from its inputs — prompt, tools, model choice, parent step — into a stable ID. Two steps with the same inputs always produce the same ID. That makes replay bit-exact, caching automatic, and forking a cheap pointer operation rather than an expensive re-execution.
opentine vs LangGraph vs Temporal vs DSPy: Choosing an Agent Runtime
LangGraph fits LangChain users who don't need forkable runs. Temporal fits durable-workflow problems where agents are incidental. DSPy fits prompt-compilation research. opentine fits when run forkability, bit-exact replay, and model-agnosticism are the primitive you're building on.