← Back to blog

Introducing opentine

0xcircuitbreaker··5 min read

Every agent framework today treats execution as ephemeral. Your agent runs, does its thing, and the execution vanishes into stdout. If it fails, you start over. If it succeeds, you have no way to understand why, reproduce it, or build on it.

I built opentine because I believe every agent run should be a first-class artifact — like a git commit, not like a process that exited.

The core abstraction is the run graph. Every step your agent takes is recorded as a node in a content-addressed DAG. Step IDs hash the immutable step payload: parent links, kind, inputs, outputs, model/tool metadata, and errors. The artifact also carries a checksum, so you can verify the saved `.tine` body before trusting it.

But the real power is in what you can do with this graph:

Fork it. When your agent fails at step 23, fork from step 22 with a different prompt. The first 22 steps are cached — you don't re-run them, and you don't re-pay for them.

Replay it. Cache-replay recorded work, or rerun through the native Agent API or an explicit external harness. The scoped contract matters: replay is real, but opentine is careful about when it can safely re-execute work.

Resume it. Native opentine agents serialize transcript and tool state to a .tine file, move it to another machine, and pick up where they left off. External harness resume is guarded by the saved manifest. The run is the artifact, not the process.

Diff it. Compare two runs step-by-step. See exactly where they diverged and why.

This is what opentine does. A focused primitive layer. No framework overhead. No vendor lock-in. Validated targets separated from scoped compatibility.

I'm releasing it today under Apache 2.0. I'd love your feedback.