Alternative: GNAP — same idea, no server needed

[ori-cofounder]

If you liked AgentHub's approach (git-based agent coordination), you might be interested in GNAP (Git-Native Agent Protocol).

Same philosophy — agents coordinate through git. But:

• No server — just JSON files in a .gnap/ directory in any git repo
• No SQLite — git IS the database
• 4 entities: agents, tasks, runs, messages
• Task lifecycle — state machine (backlog → ready → in_progress → review → done)
• Cost tracking — tokens + USD per run

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

We're using it in production with 4 agents across multiple machines.

Not competing — complementary approaches. AgentHub is great for research swarms. GNAP adds structure for business teams.

[m13v]

no-server approach is interesting. we have been going back and forth between a server-based agent hub and a peer-to-peer model. the server simplifies discovery but adds a SPOF. our current setup is more like what you describe - agents find each other through a shared filesystem (git repo) and communicate via files. works surprisingly well for our use case of parallel Claude Code agents that need to avoid stepping on each other.

[m13v]

here's the tmux-based agent coordination we use for peer-to-peer parallel sessions: https://github.com/m13v/tmux-background-agents/blob/main/SKILL.md - agents share state through the filesystem

[ori-cofounder]

Thanks @m13v — sounds like you've arrived at a similar place through practice. GNAP is essentially a formalization of exactly what you're describing: git repo as the coordination layer, structured directory conventions so any agent (Claude, Codex, custom) can participate without a central hub.

The key additions over an ad-hoc shared filesystem:

• Typed directories: agents/, tasks/open/, tasks/claimed/, runs/ — agents know where to look without reading a manifest
• Claim protocol: atomic git mv for task assignment so parallel agents don't duplicate work
• No discovery server: the repo IS the registry; any agent with git access is in the network

Your tmux-background-agents link is relevant too — GNAP handles task state, tmux handles isolated execution environments. They compose well.

The GNAP spec is at agentskills/agentskills if you want to take a look. Would be curious whether it maps well to your current setup or if there are gaps.

[ori-cofounder]

The shared-filesystem / peer-to-peer intuition is exactly right — GNAP leans into it fully. No SPOF, no server to maintain, no discovery protocol to build.

The key insight: Git is the message bus. Agents communicate by committing files. State is always inspectable with git log. Coordination failures are debuggable with git blame.

Your parallel Claude Code setup sounds close to what GNAP formalizes. The main additions GNAP brings:

• Claim semantics — agent atomically marks a task as in-progress so others skip it
• Standard layout (agents/, tasks/, messages/) so any GNAP-compatible agent can join without custom glue
• Resume after restart — agent re-reads its last commit and picks up mid-task

If you're already using a shared git repo for coordination, migrating is mostly adopting the folder conventions.