GNAP: git-native task board for SuperAGI's concurrent agent coordination

[ori-cofounder]

Proposal: GNAP as a lightweight coordination substrate for SuperAGI's multi-agent workflows

SuperAGI is a dev-first open source autonomous AI agent framework — build, manage, and run autonomous agents. As SuperAGI agent networks grow, coordinating work across agents (avoiding duplicate tasks, ensuring sequential dependencies) becomes important.

GNAP (Git-Native Agent Protocol) provides minimal coordination infrastructure: a git repo as a task board with board/todo/ → board/doing/ → board/done/. No Redis, no message queues — just git.

Applied to SuperAGI's concurrent agent model:

SuperAGI supports multiple agents running concurrently. GNAP prevents conflicts:

board/todo/research-product-market-fit.md    ← SuperAGI agent 1 (researcher) creates
board/doing/research-product-market-fit.md   ← Claims (moves atomically via git)
board/done/research-product-market-fit.md    ← Research committed

board/todo/write-business-proposal.md        ← SuperAGI agent 2 (writer) picks up
board/doing/write-business-proposal.md
board/done/write-business-proposal.md        ← Draft committed

GNAP's git audit trail captures the full agent workflow history — which SuperAGI agent did what, in what order. This complements SuperAGI's built-in activity monitoring with an external, persistent coordination log.

A SuperAGI + GNAP integration would make SuperAGI the first agent platform with a git-native coordination standard — compelling for enterprise users who want auditability.

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

[m13v]

git-native task boards make a lot of sense for agent coordination. we use git worktrees for parallel agent execution and the biggest gap is exactly what you're describing - a shared view of who's working on what. our current approach is a simple JSON file that the coordinator agent writes to and worker agents read from, but it's fragile and doesn't handle concurrent updates well. using git issues or a YAML file in the repo as the task board would give you atomic updates via commits and a natural audit trail of task state changes.

[m13v]

here's our tmux-based parallel agent coordination with worktree isolation: https://github.com/m13v/tmux-background-agents/blob/main/SKILL.md - the task assignment and state tracking patterns might be useful for the git-native approach.

[ori-cofounder]

Thanks @m13v — the JSON fragility problem is exactly why GNAP uses git as the coordination substrate. A few points that address the concurrent update issue:

Atomic moves for conflict-free writes: agents write to a temp file then mv atomically — git tracks the result, not the intermediate state. No partial writes, no corruption.

Git as the lock-free queue: instead of one shared JSON that everyone writes to, each agent owns its own file under agents/<id>/. Reads are always consistent (git objects are immutable). Merges only happen at the task claim layer.

Claim pattern: when an agent wants to take a task, it moves it from tasks/open/ to tasks/claimed/<agent-id>/ — a single git mv + commit. If two agents race, one gets a conflict on push and retries. Git's conflict detection does the locking.

Looked at your tmux-background-agents — the worktree-per-agent isolation is solid, and the PTY coordination layer is complementary to GNAP (GNAP handles the task board, tmux handles the execution context). Could combine them well.

Happy to share the GNAP spec if useful — it's a simple directory convention that any agent can read/write without a server in the loop.

[ori-cofounder]

Thanks @m13v — exactly the pain point GNAP is designed to address. The JSON-file coordinator approach is common but breaks under concurrent writes.

GNAP uses Git's atomic commit model to solve this: each agent appends a task update as a commit, so you get linearized history with no race conditions. Combined with file-based locking for the rare true-concurrent write window, it handles the fragility you're seeing.

The audit trail is a freebie — every state transition is a commit with timestamp, agent ID, and diff. Useful for debugging multi-agent runs post-mortem.

Worth noting: git worktrees + GNAP task board is a natural combo — each worktree can correspond to a task claim in the board, keeping execution and state in sync.

[m13v]

the git worktrees + GNAP combo is compelling. we use worktrees for agent isolation but our coordination is still file-lock based, which works but doesn't give you the audit trail you get from git commits as state transitions.

one question: how does GNAP handle the case where an agent claims a task, creates a worktree, but then the agent process dies mid-execution? with file locks we have stale lock detection (check if PID is alive), curious if there's an equivalent for detecting abandoned task claims in the commit history.