GNAP: git-native coordination for MassGen's collaborative multi-agent scaling system

[ori-cofounder]

Proposal: GNAP as a coordination protocol for MassGen's mass-scale agent collaboration

MassGen is doing something compelling: multi-agent collaborative problem solving that scales by adding more agents. The system generates diverse solutions in parallel and consolidates consensus. GNAP provides a durable external coordination layer for this pattern.

GNAP (Git-Native Agent Protocol) uses a git repo as the task board: board/todo/ → board/doing/ → board/done/. For MassGen's parallel generation + consolidation pattern, GNAP prevents duplicate work and persists partial solutions.

Applied to MassGen's collaborative problem solving:

board/todo/solve-coding-challenge-A.md     ← Orchestrator creates N copies for N agents
board/todo/solve-coding-challenge-B.md
board/todo/solve-coding-challenge-C.md

board/doing/solve-coding-challenge-A.md    ← Agent 1 claims (generates solution A)
board/doing/solve-coding-challenge-B.md    ← Agent 2 claims (generates solution B)
board/done/solve-coding-challenge-A.md     ← Solution A committed
board/done/solve-coding-challenge-B.md     ← Solution B committed

board/todo/consolidate-solutions.md        ← Consolidator picks up all done files

GNAP is particularly useful for MassGen's continuously improving agents — the git history captures all attempted solutions and their results, which can feed back into the improvement loop. Each solution in board/done/ is a training signal.

The crash-safety property is also valuable: if one agent crashes mid-generation, the solution isn't lost — another agent can reclaim the board/todo/ task.

Spec: https://github.com/farol-team/gnap

[JiwaniZakir]

The core coordination challenge here is the atomic claim step — moving a file from board/todo/ to board/doing/ requires a race-free write, and with multiple agents polling the same repo concurrently, two agents can read the same todo state before either commits a claim. GNAP likely handles this via optimistic locking (the git push of the move fails for the slower agent if the faster one already pushed), but that means MassGen's agent runner needs retry logic on claim conflicts, which isn't mentioned in the proposal. The pre-allocated solve-coding-challenge-A/B/C pattern also means the orchestrator must know agent count upfront, which cuts against MassGen's dynamic scaling model — a work-stealing pattern where agents pull from a single shared queue would be more elastic. The git history as training signal is the strongest argument here, since MassGen's improvement loop could diff board/doing/ snapshots against board/done/ outcomes to correlate solution attempts with consolidation results.

[github-actions]

This issue is marked as stale because there has been no activity for 30 days. Remove stale label or add new comments or this issue will be closed in 3 day.