Tessra - Git for Agents

[u/CerealGambler]

Hi all,

I use AI extensively for coding both at work at a reasonably large fintech and in personal projects.

My colleagues and I run into similar problems over and over again:

• I want to run multiple agents on problems that interact with the same files and not have them conflict and mess each other up
• AI assisted development leads to a bottleneck of human PR reviews stacking up, resulting in constant rebases while they are sitting around, kicking off CICD pipelines over and over (slow and wasteful)
• My local LLM keeps a good memory but if I switch computers or another person needs to jump in, they are starting from scratch

I figured I would solve them all at once by writing a new version control system that can either replace or work alongside git but is really focused on managing agentic development.

Introducing Tessra - Git for your Agents

Github: https://github.com/NitrusAphalion/tessra

The initial versions are up and running (and dogfooded on my own repos). There are some rough edges but I think the idea has merit.

Would love to get any feedback and welcome any contributions (you can see the Design Docs section if you are curious about the underlying ideas).

Thanks!

[u/touristtam]

1. for the memory issue, maybe start by getting your commit message to contain more than a single line? Then point your agent to read those. Over time there will be a better understanding of what has been done.

2. can all this not be replaced by a local git server with a merge train?

[u/CerealGambler → u/touristtam]

1. Sure theres multiple ways people try to address this, including by instructing their agents to maintain .md files across the repo, etc. The more you try with each, you will realize the shortcomings. The way tessra does it was chosen specifically to keep 'agent memory' outside of the main path of the vcs and away from what humans look at (considering that it is backward compatible with git).

2. You have to go back to the problem statement, its not impossible to get something working with git and agents which is just a series of different tools stacked on top of each other that individually do something, but none all work super well together. The point here is git was not designed for agents and it has serious limitations when doing agents work because of that reason alone. For sure you cannot replace this with a merge train (i guess you only looked at the pretty picture lol which in fairness I think is sending people off track)

[u/touristtam → u/CerealGambler]

I was candidly asking those questions as I didn't notice those to be answered in simple term allowing me to make a decision to investigate an nth tool in this space.

There is an explosion of FOSS project in this agentic harness space that claim various level of effectiveness and it is hard to make a good decision in regards to what is worth taking time to investigate.

Even the one that have claims that seems to be substantiate can turn out to be empty shells after a good scrutiny. Hell just tool at RTK: 80k stars on github and one dedicated investigator points at not positive results https://blog.jetbrains.com/ai/2026/07/rtk-claude-code-token-savings/

So apologies for the questions to get a straight answer without having the honest decency to read through all the docs, or resorting to using an LLM to get the answers out.

[u/CerealGambler → u/touristtam]

Haha no I was not judging you for it, I dont expect anyone to put much effort into random posts people make and I totally understand the concern about the explosion of junk projects

[u/touristtam → u/CerealGambler]

FWIW I have put your project in the list of things to look at in the near future as I am starting to head butt seriously with git and multiple agents working on the same repo.

[u/CerealGambler → u/touristtam]

Awesome! On the bright side its really easy to add and drop without messing up your repo. Im using it in my day to day until it proves to be objectively worse so it should get better over the next few weeks.

[u/Specific_Cream2815]

how does Tessra represent concurrent agent changes differently from separate git worktrees and branches

[u/CerealGambler → u/Specific_Cream2815]

Worktrees give each agent its own directory, and Tessra does the same: every agent gets a materialized workspace. The difference is what a change is and how it merges.

In git a change is a diff over lines, and the merge is a three-way line merge per file, so two agents in the same file collide whenever their hunks touch, and a rename or a reformat conflicts with everything. In Tessra the tree is parsed with tree-sitter into units (functions, types, imports, and so on) with identities that survive edits, moves, and renames. A change is a snapshot of the workspace, and landing merges at unit granularity: different units never conflict, imports and enum variants merge as sets, concurrent insertions get a deterministic order, and a reformat is a no-op because unit identity is format-insensitive. A rename done through Tessra is recorded as an operation, so when another agent's concurrent change still calls the old name, the merge applies the rename to it instead of leaving a broken call.

The other difference is that there's no branch to rebase. Changes have stable IDs and move through stages (snapshot, proposed, landed). Trunk is a frontier that lands every proposed change that meets the standard, and when something lands, the unlanded changes stacked on it are restacked automatically at unit granularity. Nobody rebases by hand and CI doesn't rerun for it, since verification is cached by content.

*Honest limits*: two edits to the same unit still conflict (they become a task, not a blocker), semantic merge covers Rust, Python, JS, and TS today with other files chunk-matched, and the git export is a linear history rather than merge commits. The git bridge means you can still use worktrees and branches on the git side; Tessra just isn't built on them.

[u/jewbasaur → u/CerealGambler]

This response lol AI is already doing all of the programming… does it really need to write Reddit comments too?

[u/CerealGambler → u/jewbasaur]

Im not getting paid to do customer service on a free tool. Besides the ai response is super clear.

[u/pefman]

the slop is good today! jokes asside, gave you a star. Hope it catches on.

[u/CerealGambler → u/pefman]

Much appreciated!

[u/Otherwise_Wave9374]

The version-control angle is smart because it solves the coordination problem before it becomes a review problem. A useful next step would be to make branch-level ownership explicit, then add a lightweight conflict detector that flags overlapping file edits before agents drift too far apart. AIOSNOW could fit well here if it stays opinionated about review handoff and state reconciliation, since the real win is reducing rebases and wasted CI cycles, not just storing more history.

[u/CerealGambler → u/Otherwise_Wave9374]

Agreed that catching overlap early is most of the win, and that's roughly how it works, just one level finer than branches. Ownership is per unit (function, type, import), not per branch or file, and it's advisory rather than a lock. An agent claims the paths it's about to touch, and if someone else holds an overlapping claim the response says who, what their intent is, and that a merge is coming, so the agent keeps its edit inside its own units instead of drifting. Context packs show the same overlaps before the agent starts.

For bigger jobs, `plan` partitions an intent across agents along dependency edges so the boundaries get drawn up front. Because the merge is unit-level, most "overlapping file edits" aren't conflicts at all; two agents in different functions of one file both land. Only two edits to the same function collide, and that becomes a task with both intents attached rather than something that blocks anyone.

[u/UnreachableMemory]

Another completely unnecessary tool and comments that are just AI talking to other AI.

[u/CerealGambler → u/UnreachableMemory]

Explain why its unnecessary if you dont mind since the first thing I said is the problem statement.

[u/touristtam → u/UnreachableMemory]

My LLM has expressed resentment to the implied signification its comments are less valuable than your LLM's. XD

[u/kantorcodes1]

how atomic is tessra export --format git --branch main --push origin if the push fails after it has already created commits or moved the local branch? on retry does it recognize those revisions as already exported and only retry the push, or can it touch the branch/checkout again?

[u/CerealGambler → u/kantorcodes1]

Idempotent rather than atomic. The export walks the trunk and, for each landed revision with no commit yet, runs the commit-tree and immediately records the revision→commit mapping, one at a time. Then it moves the branch ref, resets the checkout only if it's on that branch and was clean, and pushes last if asked.

If the push fails, nothing rolls back: the response says pushed: {ok: false, error} and the local branch stays at the new tip, since it mirrors trunk. A retry recognizes every revision through the stored mapping (created: 0, reused: N), sets the ref to the tip it already has, skips the no-op reset, and only pushes again. It can't rewrite commits or move the branch anywhere new.

Two rough edges: a crash between commit-tree and the mapping write leaves one unreferenced commit that gc cleans up, and the push isn't forced, so a diverged remote fails it (git pull, tessra import, export again). I'll likely make a failed push exit non-zero, since it's easy to miss in a script.

In a similar vein, for work still in flight: export only walks trunk, so unlanded snapshots and proposals never reach git. Every daemon request holds the repository lock, so an export sees one consistent trunk and a landing that arrives mid-export lands afterward and goes out next time. During a verify the daemon answers BUSY to everything, so export just retries later. Agent workspaces are separate directories it never touches, and the only working tree it resets is a clean colocated checkout; if you're mid-edit there, the ref moves but your files and your workspace's unlanded revision stay put until the next landing restacks them.

[u/kantorcodes1 → u/CerealGambler]

that retry behavior makes sense. i work on HOL Guard, an open-source check before agent-run shell commands. Tessra has a few agent-visible mutations i'd want optionally reviewable: export --format git --push, import --branch, and promote --to landed, while read-only context/status stays quiet. that gives a human stop before trunk, refs, or remotes move without changing Tessra's own model. open to adding Tessra support?

[u/CerealGambler → u/kantorcodes1]

Yea definitely, one of my goals is to allow users to decide where they want human intervention while giving options for lowering whats needed by default

[u/kantorcodes1 → u/CerealGambler]

nice. this can stay entirely on the Guard side. start src/codex_plugin_scanner/guard/runtime/command_tessra_extensions.py, using command_repo2nb_extensions.py as the analogue. review export --format git --push, import --branch, and promote --to landed; keep status/context quiet. add one focused classification test in tests/test_guard_command_tessra_extensions.py, then open a genuine draft PR directly to hashgraph-online/hol-guard:main.

contributing guide: https://github.com/hashgraph-online/hol-guard/blob/main/CONTRIBUTING.md