Agentigram

Inspiration

Multiple engineers each running a coding agent is not really a communication problem. It is a speed problem. The agents can write code faster than anyone can keep track of what the others are doing, and most of the time they have no idea what changes are happening on another engineer's laptop, along with this engineer's spend a lot of time reading to understand what their agents are implementing, so we solved this with a TTS pipeline.

Git helps when two people edit the same lines, but a lot of the integration problems we ran into were more subtle than that. For example, Backend might change User.id from a number to a UUID string in user.ts while Payments is building checkout in checkout.ts and still expects a number. The files never overlap, so Git sees no conflict, but the combined code is broken. We wanted to catch those problems while the agents were still working, when they could actually do something about them.

What it does

Agentigram is a coordination layer for coding agents running across different engineers' laptops. It watches what each agent reads and changes, keeps track of which parts of the codebase they depend on, and detects when unfinished work from different agents is becoming incompatible.

Detection happens in three layers. The first happens before an edit. If an agent says it is about to change User.id, Agentigram checks whether that symbol appears in anything another agent has recently read or depended on. The second happens as edits are made. Each laptop compares its working tree against the branch point and extracts changes to exported symbols and public interfaces. That lets us recognize that a type changed from number to string, rather than only seeing that a few lines changed.

The third layer actually combines everyone's unfinished work in a temporary checkout and runs the type checker and affected tests. This gives us concrete failures from the code that would exist if everyone's current work were merged together. When Agentigram finds a meaningful semantic collision, the affected symbol can be leased so another agent is stopped before making an incompatible edit. We do this through the coding agent's own hooks rather than relying on the agent to voluntarily cooperate.

The agents can then negotiate what the shared interface should be. Once they agree, that agreement becomes a real contract check, such as a type assertion, schema test, or API check, so the decision can be verified later. An authority laptop also keeps track of ownership for active work and gives each agent a short brief describing what it owns, what it depends on, and which areas are currently contested.

At the end, we also generate an eval reports so we can analyze which agents can perform which software engineering tasks better. This is a much better way to benchmark agents because metrics can be biased or overfitted but having an outcome-based eval allows us to see performance in real-time.

How we built it

The networking layer is built with Tether's Pear and QVAC stack. Rooms communicate peer to peer over Hyperswarm, so there is no central application server carrying the team's coordination state. Laptops discover each other using information derived from the room invite, and peers verify each other's identity before accepting a connection.

Every laptop keeps a replicated copy of the room history. One authority laptop orders new events and assigns sequence numbers, while the other laptops keep verified copies. If the authority disappears, the existing room history is still available and the room becomes temporarily read only. The invite is also tied to the repository, which prevents someone from joining the room from an unrelated clone and producing meaningless dependency results.

The room interface is a Pear app built on Bare. We based it on holepunchto/hello-pear-qvac-tui and use bare-tui for the interface. We run the local model in a separate thread because loading a few hundred megabytes of model weights can block execution for several seconds. Keeping inference away from the UI thread means the interface stays responsive while the model is loading or generating.

One of the most important choices we made was not using a model for collision detection. Detection is deterministic. We index exported symbols in the repository and track which symbols each agent reads. If one agent is about to change a symbol that another agent depends on, that overlap is just set comparison. As edits happen, we can add public API changes and eventually the results of the speculative merge.

The model is used for the part that actually benefits from language. We run a small Llama model locally through QVAC to draft the contract between agents and explain the collision in plain English. We also give the model a JSON schema and use llama.cpp grammar constraints so invalid structured output cannot be generated.

We found that the order of generation mattered a lot. Our first version asked the model to explain the collision directly, and a small model would sometimes invent details that sounded reasonable but were not actually present in the code. We changed the flow so the structured contract is created first, then the explanation is generated from that known contract. That made the output much more reliable.

Enforcement has to be extremely fast. The hook that decides whether an edit is allowed only has a few hundred milliseconds before the coding agent continues, so that check is a pure function over state the laptop already has. No model call is involved. We also do not treat ordinary file overlap as a blocking conflict. Two agents can safely work in different parts of the same file, so blocking only happens when the agents overlap on a meaningful symbol or contract.

Agentigram also reads important room events out loud using QVAC's on-device text to speech. Each agent gets a stable voice based on its identity, so after listening for a while you can recognize who is talking without looking at the screen. We do not send every model generated message directly into another coding agent. Generated proposals require an explicit user action before being shared, and incoming agent content is wrapped and length limited so it is treated as information rather than trusted instructions.

Challenges we ran into

Our first collision detector was far too noisy. A single refactor could trigger the same collision every time the file was saved, so one real problem turned into dozens of interruptions. We fixed this by giving each collision a stable ID based on the agents and symbols involved. If the underlying issue has not changed, Agentigram updates the existing collision instead of announcing a new one.

We also started by treating file overlap as a blocking conflict. That made the system almost unusable. Two agents being in user.ts does not necessarily matter. One agent changing User.id while another depends on User.id does. That pushed us toward symbol level coordination rather than file level locking.

Speech had a similar problem. We originally tried to decide whether an agent joining the room should be spoken based on whether that agent already appeared in the roster. After restarting the authority laptop, the saved roster already contained everyone, so reconnecting agents looked like they were already present and nothing was spoken. The simpler solution worked better. We now prevent the exact same sentence from being spoken twice within thirty seconds.

We also hit a dependency issue that only appeared inside worker threads. Bare's addon loader expected one version of a module while some dependencies still pulled in an older version. Our pre-warm script worked, but the actual TUI crashed when the worker started. Pinning the dependency version fixed it, but finding the cause took much longer than the fix itself.

Accomplishments that we're proud of

The biggest thing is that it works across real laptops over a real peer to peer network. We have encrypted rooms, replicated history, leases that actually block incompatible edits, hooks for Claude Code, Codex, and Gemini CLI, and a Pear application that lets the agents negotiate collisions using a model running locally on the machine.

We are also proud that collision detection never depends on a model. The result is deterministic, explainable, testable without a GPU, and reproducible across every laptop in the room. The model is only used where language and judgment are actually useful, such as drafting a contract or explaining what happened.

The project also does not depend on venue WiFi for inference or speech. The model, text to speech, and deterministic fallbacks all run locally.

What we learned

The biggest lesson was that small models are much better when you give them the right job. Asking a 1B model to infer what caused a complex software failure can produce confident nonsense. Asking that same model to turn a structured, already verified contract into a clear explanation works surprisingly well.

We also learned how useful constrained generation can be. Once malformed structured output is impossible rather than merely discouraged, a small local model becomes something the rest of the system can safely depend on.

The other major lesson was that watching beats asking. An earlier version depended on agents reporting what they were working on through a tool. They forgot, reported too late, or simply started editing without saying anything. Observing the files, Git state, hooks, and symbols they actually touch turned out to be much more reliable.

What's next for Agentigram

The biggest remaining piece is connecting the API comparison and speculative merge so they run automatically as edits happen. Both pieces are already built and tested, but right now they still need to be triggered manually.

After that, we want to add GitHub checks that attach the agreed contract to a pull request so a later change cannot silently violate a decision the agents already made. We also want to use verified outcomes to build better model intelligence for each team. Agentigram already sees which model handled a task, how long it took, whether CI passed, how much rework was needed, and which collisions happened along the way.

One direction we want to explore is letting humans and agents make lightweight forecasts about things like which subsystem contains a bug, whether a change will pass CI, or which agent will resolve a collision first. Those forecasts can then be compared against the actual Git and CI result and become another signal for understanding which models and agents perform well on a specific codebase.

Finally, we want authority failover. Every peer already has the complete room history, so the remaining work is allowing another trusted laptop to take over ordering new events when the current authority disappears.