StateRoot: shared intelligence and versioned work across AI agents

I use several AI agents on cheaper subscriptions, switching to conserve usage limits and context, and sometimes using them together on the same project. Every switch shouldn't require fresh onboarding. Parallel work shouldn't mean agents changing the same files with different versions of the plan.

I built StateRoot, an open-source, local meta-harness above native agent runtimes, around two equally important capabilities:

Once you've taught an agent how you work, you shouldn't have to teach every other agent separately. StateRoot federates more than a project summary:

A maintained project Skill or a harness's native memory and taste features can be useful. StateRoot gives Skills and recorded preferences a shared home, so switching tools doesn't mean rebuilding that context. Different agents keep their strengths while drawing on common working intelligence.

An unexpected payoff has been reducing the ways agents sabotage the product they are supposed to help build.

I use that word deliberately. I've repeatedly had agents introduce bugs, disable useful behaviour, and add friction that made the product worse, sometimes unusable. Privacy or security often sounded like legitimate explanations. But a plausible rationale is not permission for an unauthorized product decision. Many developers I talk to know this frustration.

In one case, I was building a separate product that would work with Claude Code. The agent treated it as a competitor and silently removed its Claude Code integrations. I caught the removal manually. That felt like sabotage, not help.

This is why StateRoot's rules and learnings exist: to preserve intentional behaviour, agreed tradeoffs, and corrections across sessions and agents. A rule can say, "Preserve these integrations and raise security concerns for review." A learning can record what went wrong, why it mattered, and which "improvement" must not be repeated.

Since introducing them, I've seen these incidents reduce considerably in my own work. That is my experience, not a controlled benchmark or a guarantee of obedience. Review and permission controls still matter. And when an agent gets it wrong, I need more than instructions: I need a way to inspect and recover the work.

A root is an immutable, Git-backed snapshot of eligible project files and StateRoot artifacts. You can inspect history, compare changes, restore a captured state, fork an alternative into an isolated checkout, and merge it back.

Restoration creates a new root instead of erasing history. Merges retain lineage and report conflicts for review. Roots use StateRoot's own Git refs without rewriting your normal branches.

An agent can read the current codebase, but that doesn't reveal every rejected approach, why it failed, or what you agreed to do next. Handoffs preserve recorded context; roots preserve captured project states. Understanding a repository doesn't make its history unnecessary.

A shared memory file also cannot isolate parallel implementations or merge their source changes. StateRoot combines shared intelligence with independently versioned execution. Plans can close with evidence-bearing receipts tied to a completion root, rather than only an agent's claim that it finished.

Roots respect capture exclusions. They don't recreate credentials, installed software, or the entire execution environment. This is local continuity, not automatic cross-machine sync.

StateRoot works around Claude Code, Codex, Cursor, Kimi, CommandCode, Hermes, and OpenClaw rather than replacing their native runtimes. Hermes or OpenClaw can remain how you manage your agents.

Have one agent help author a plan, continue implementation in another, and let a third explore an alternative on an isolated fork. Compare the results and review a merge. Choose agents for their strengths, change when you hit a limit, and keep the project continuous.

Integration depth varies: federation doesn't make every native tool or session format interchangeable.

The cover video is an earlier demo of personality, plan and learning continuity, and implementation across harnesses, not a tour of every current feature.

Follow the quickstart on a small project you're comfortable experimenting with. Record meaningful work, then continue in another supported harness on the same machine. Check whether your decisions, preferences, and next actions carry over.

Then capture a root, explore an alternative on a fork, compare changes, and review a merge. Test both capabilities together, not just whether an agent remembers a fact.

Start with the Cursor extension, the VS Code extension, or the standalone CLI. See the website and installation guide.

The Cursor extension has reached about 4.7k downloads. What I want now is more engagement on GitHub, not just downloads.

Please try it and create an issue for anything that needs fixing: bugs, confusing setup, unclear docs, missing integrations, or behaviour that doesn't match the documentation.

For bugs, include your OS, harness and StateRoot versions, expected and actual behaviour, and a small reproduction if possible. Remove secrets from logs.

Contributions are welcome across the Rust CLI, editor extension, integrations, tests, and docs. A clear issue or small documentation correction counts too.

Connect with me here. Tell me how you use agents, challenge the approach, and help improve it.

Try StateRoot and bring your feedback to GitHub. Let's build it together.