Every run is
an artifact.
the entire industry is building the wrong thing.
Look at the agent frameworks shipping today. LangChain: 166 megabytes of abstractions wrapping abstractions. LangGraph: 51 megabytes of state machines for problems that aren't state machine problems. CrewAI: 173 megabytes of role-playing prompts. These tools have real users solving real problems. I don't dispute their utility. I dispute their premise.
The premise is that agent execution is ephemeral. Your agent runs, calls some tools, produces some output, and the execution vanishes. The process exits. The state is gone. If something went wrong at step 23, your only option is to re-run all 47 steps from scratch. The framework gave you orchestration but not observability. It gave you execution but not history. It gave you a process but not an artifact.
This is the same mistake software made before version control. Before git, code was ephemeral. You edited files, and previous states were gone. The insight of version control wasn't just “save old copies” — it was that every state of your codebase is a first-class artifact you can navigate, branch, diff, and share.
I believe agent runs deserve the same treatment.
The run tree
In opentine, every agent execution is a tree of steps. Not a flat log. Not a stream of events. A tree. Each step records what the agent thought, which tool it called, what inputs it sent, what outputs it received, how long it took, and what it cost.
Each step is content-addressed — its identity is the hash of its inputs and configuration. This means identical steps are automatically deduplicated. It means you can verify the integrity of any run. It means caching is built into the data structure, not bolted on.
This tree is the artifact. You can save it to a .tine file and send it to a colleague. You can fork it from any step and try a different approach. You can replay it on a different machine with a different model. You can diff two trees step-by-step and see exactly where they diverged.
Against bloat
opentine's core is 250 lines of Python. This is not an accident. It is a design constraint I enforce ruthlessly.
When your core is 250 lines, any developer can read it in 10 minutes. There is nowhere for bugs to hide. There is no “framework magic” — you can trace any behavior to a specific line. This is not minimalism for aesthetic reasons. It is minimalism for trust. If you are going to run AI agents in production, you need to understand exactly what the framework is doing. At 250 lines, you can.
I also refuse vendor lock-in. opentine treats every model provider equally: Anthropic, OpenAI, Google, Ollama, or anything else via LiteLLM. Same protocol, same API, same run tree format. Your choice of model should be a runtime decision, not an architectural commitment.
The fork
The most important operation in opentine is the fork. When your agent fails, you don't start over. You find the step where things went wrong, fork from the step before it, adjust the prompt or tools, and replay. The good steps are cached. The fix costs only the tokens for the new path.
This changes the economics of agent development. Debugging goes from “re-run everything and hope” to “surgical correction at the failure point.” It changes the workflow, too. You stop thinking of agent runs as disposable attempts and start thinking of them as branches you can navigate.
A tine is the prong of a fork. opentine literally forks agent runs.
What I believe
I believe the right primitive is the run tree, not the orchestration graph.
I believe 250 lines of core is not a limitation but a feature.
I believe vendor lock-in is a tax on experimentation.
I believe every agent run should be forkable, replayable, resumable, and shareable.
I believe open source should empower builders, not constrain them.
This is opentine. Fork your runs.