Git Together: helping agents share a codebase

Parallel agents only help when they can work together without repeatedly undoing one another’s progress.

The bottleneck was coordination

During a large rewrite of an acquisition flow, I was trying to take changing requirements all the way to production with multiple agents working in one codebase. The difficulty was not simply getting an agent to generate useful code. It was getting several agents to do useful work at the same time.

They would touch overlapping areas and write over one another’s changes. To keep progress predictable, I repeatedly had to fall back to one active agent. That made coordination a delivery bottleneck: adding another agent did not reliably add another stream of progress.

Git Together grew out of that experience. At a high level, it is a protocol for making an agent’s intended work visible to the other agents before that work creates a conflict.

Make the unit of work explicit

Each agent declares a unit of scope and its priority. The important shift is that an agent is no longer acting as if the whole codebase is exclusively its own workspace. Other agents can see the context of that declaration and account for it when choosing what to do next.

Scope makes the intended area of work understandable. Priority communicates urgency. Neither should be confused with permission to overwrite work that another agent is actively performing.

Bound the ownership window

The protocol includes a minimum timeout period. Another agent cannot simply treat an occupied unit of scope as immediately available; it must request access through the coordination process.

That creates an explicit place for agents to communicate about who is working on what and when a handoff can happen. It makes waiting or choosing a different unit of work a normal part of collaboration, rather than discovering an overlap after changes have already been made.

The exact representation of scope, timeout handling, and access requests is outside this public account. The idea I can share is straightforward: make ownership visible, give active work a bounded window, and communicate before crossing that boundary.

Why that helped in practice

Without coordination, two individually reasonable changes can still interfere with each other. An agent may be fixing a component while another is replacing the flow that uses it. A shared view of intended work gives both agents context that their immediate task description may not contain.

This does not remove the need for tests, review, or integration. It addresses a more basic problem: avoiding unnecessary interference before integration even begins.

A longer-running experiment

In the run I’m describing, Git Together has been operating in a recursive improvement loop for more than two months, continually implementing new features. I have not encountered merge conflicts during that run.

That is an observation about this use of the protocol, not a guarantee that every parallel-agent workload is conflict-free. The meaningful change for me was that continued development no longer depended on serializing every useful task behind one active agent.

The tool is in internal use. The internal user count is withheld. We are exploring whether it can be open-sourced, but this article is a description of the coordination idea rather than a public implementation release.

The lesson

I initially wanted more agents to produce more progress. The more useful question turned out to be what those agents needed to know about one another’s work.

Scope, priority, and explicit access requests gave that coordination a shape. Once the agents could recognize an active boundary and communicate about it, parallel work became much more practical.