WIBTM: What happens when you let an agent design a new git system?

Sep 24, 2026 · 5 min read · Original on Substack ↗

How Graph-Based Source Control Actually Works

In cosm, the graph is the primary source of truth for any code related activities. Code is stored as an AST representation in the database. When an agent needs to change the graph, it can create a lock on a particular set of entities, perform the surgery, and then write the updated records back. This is the largest distinction from git, where the file system is still the root.

The file system is a secondary component in this model. A cosm graph materializes files for the sake of keeping compatibility with all the existing ecosystem of tooling for languages ( for example npm build). A set of language renderers materializes the files as a secondary order to the graph which stores the ground truth and history of what the team (users and agents built).

In cosm a universe is similar to a repository. Universes can link together with graph edges. If a change is required, these edges provide the links to determine if there are larger updates required.

Here’s an example of a graph with a related edge:

For commit tracking, a unique ID, similar to a hash is assigned for each universe mutation. Locking is managed by short lived checkouts. Agents can check the 'blast radius’ of code before making changes. This just means you can see how much one change will impact connected code pieces.

Unlike file based systems, the graph database and the AST helpers are the critical links. In this sense, it’s more of a system than a set of files with history (yes I know there are other things like PR’s but in a nutshell git is the history and code manager).

Why cosm is a good alternative for source control

Simply, cosm is built for agent code management. By using a graph database, it’s simple to control many requests for a symbol that agents want to change. You can provide limited locks that time out, and agents can stack their changes to apply. cosm takes these principles for agent first development, including stress tests that I’m building out.

Also, AST’s are great things for agents to reduce tokens and improve results. By making the AST the ground truth, cosm makes it such that the symbol and the intent are the primary elements for capture, not the specifics of implementation which are managed by the AST renderers.

The Trade-Offs: Drawbacks and Learnings from Building Cosm

There are a few (many things) that I’ve learned in building this, some about the app, others about agents).

First, about building cosm:

• Building the test cases here was surprisingly difficult and I had to keep re-prompting agents to do the work. Eventually I found a set of adversarial prompting began to round out the work better.

• Backward compatibility is a problem. I created a gh shim that exists in cosm for the sake of managing files to import or export, but when paradigms contradict, it might actually end up being easier for agents to just do their own thing.

• The human / agent interaction is still largely undefined (except for chat). I’ve built a number of helpers like a VSIX extension for cosm but I think there are still better interaction methods with this, and I’m hoping to explore more. This is at the expense though of keeping it simple, which git excels at.

• I had to build or validate many AST renderers across languages and I’m sure they aren’t perfect. I’m mostly testing in Go to start and hoping to expand out to other languages.

Next, my agent learnings:

• It’s actually easier now to have agents do incremental work than it was to ship the original. I equate much of this to me having a better understanding of the product vision than when I set out, but building v1 without a true frontier model is not easy.

• The faster I defined principles in my AGENTS.md the better off I was. I have a set of limited skills for agents that either use cosm for their work, or that help to build on cosm. If I were to use skills here, it would be process based (skills for being a good feature manager as example). Product primitives are pretty easy to bake into AGENTS.md.

• I almost exclusively use subagents now after going through this process, even when tasks are relatively simple. The subagent model forces more detailed planning and limited context to start execution, and is yielding far better results for me across all my projects.

Try out cosm for yourself, and tell me what you think

cosm is published today. You can clone it from git (I appreciate the irony), and start with the camping example app that has a number of points for you to see how it works. You can use any agent or code editor, I recommend using the getting started guide and agent skills.

Next time, I’ll talk about topocosm which is the universe manager. This had another set of learnings that I’m going to be sharing.

Please give me feedback! I want to see how far this potentially goes, but I recognize this is one of many ways to think about how agent behavior, lineage, code management, and graphs can work together, and there are others out there.

I’m also looking for public license code bases that would be good to test with, so send those my way also.