Multivergence Launches as Open Source Forkable State for AI Agents

Multivergence 0.1 is out, open source under the Apache License 2.0. It’s a state engine for software that keeps several possible futures open at once: fork the state into branches, give each a weight, constraints and a deadline, let evidence thin them out, and promote the one that’s left. The code is on GitHub, and ready-built binaries for Linux, macOS and Windows are on the download page.

The first users in mind are AI agents that try before they commit. They fork a plan per approach, feed tool results back as facts and likelihoods, and promote the plan that survives. The explainer goes through why that job belongs in the state, where every agent can share it.

The quickest way to see it is the demo that comes in every archive. Run multivergence-demo and an agent books a trip with three plans in flight. A fare search kills the flight when its fare breaks the budget. A disruption feed moves the train to 88%. The coach’s seat hold runs out, and the train is promoted. It prints the probabilities at each step and checks every one of them.

The middle of the demo’s run, from the fare search to the moment one plan is left.

What’s in Version 0.1

• The Go library. A store lives in memory or in one file, and is safe to share between goroutines. It has no dependencies outside the Go standard library.
• The multivergence command. It works on the same file from the shell, and with -json every command prints one JSON value, so Python, TypeScript or anything else can drive it. Exit code 4 means a change was made and the branch died of it.
• The engine’s rules, written down. Observe runs in a fixed order: expired branches die, facts go to every live branch, constraints are checked, likelihoods are multiplied in, weights renormalise, and an optional prune runs last. The engine never works out a probability itself. The repository’s UPDATES.md has the exact rules and a worked example.
• A file that survives crashes. Every change is one checksummed record, synced before the call returns, and a promote is a single record. Compaction keeps the file small, and it writes the nodes that branches share only once, so 1,000 branches over a 10,000-key state fit in a 5.9 MB file.
• Two examples. The agent demo, and a speculative-execution example that prepares two guesses at a user’s next edit in branches and promotes the right one.

What It Doesn’t Do Yet

Promote takes one branch and drops the rest; branches can’t be merged. A branch is data, so if one takes a real action, like paying for a ticket, nothing undoes that when the branch dies. A store is one file on one machine, written by one process at a time. And each change copies the table of branches, which costs about 70 µs per write with 1,000 live branches. That’s quick next to an agent’s tool calls, but it isn’t built for millions of branches.

How It Was Tested

The tests aim at the things the engine promises. Isolation was checked against a model that copies every map in full, across 86.8 million reads. Writer processes were killed with SIGKILL 1,000 times, 106 times in the middle of a promote, and every file reopened whole. 300,000 random changes replayed to the same weights, bit for bit. A 30-day simulated schedule fired 1,152 deadlines and 609 broken constraints, each on time. And 8 processes shared one file through 4,000 updates without losing one. The testing post has the details, and the raw results are in the repository.

Releases go out through an automated workflow. It builds the binaries from the exact commit the tests passed on, runs a smoke check on each one on its own kind of machine, and only then publishes.

Start with the quick start, or just run the demo.