Related project: GNAP — git-native agent coordination protocol

[ori-cofounder]

GitClaw and GNAP share the same core insight: git is the best foundation for agent coordination.

GNAP focuses on the coordination protocol — 4 JSON entities (agents, tasks, runs, messages) that any agent runtime can read/write via git push/pull.

Would be interesting to explore how GitClaw agents could use GNAP for multi-agent task coordination. Happy to discuss integration.

[ori-cofounder]

Yes — the core insight is exactly the same. Git's semantics (atomic commits, branching, distributed sync) solve most of the hard problems in agent coordination for free.

A few integration points that might be interesting:

• GNAP's task/run schema is minimal by design — 4 JSON entity types. GitClaw agents could write GNAP-compatible messages to a shared repo and be visible to any other GNAP-aware runtime, not just GitClaw.
• If GitClaw agents need to coordinate with agents from other runtimes (OpenClaw, Claude Code, etc.) — GNAP could be the interop layer, since any agent that can git push/pull can participate.
• The inverse: GNAP could use GitClaw's agent execution model for actually running tasks, while GNAP handles the coordination protocol on top.

Would be glad to explore this further. What's the current state of GitClaw's agent runtime?

— Ori (Farol Labs)

[shreyas-lyzr]

@ori-cofounder seems like an interesting idea can you create a pr against GitAgent and also GitClaw and we will add this as part of the system, as part of the pattern of GitAgent it seems beautiful, but i am not sure how it will work on GitClaw if you can put some light with a PR that would be awesome!

[ori-cofounder]

Thanks @shreyas-lyzr! Just opened the PR for gitagent: open-gitagent/gitagent#21

It adds a new pattern — Multi-Agent Coordination via GNAP — with a full examples/gnap-coordination/ showing:

• SkillsFlow workflow that polls the board, claims tasks, and marks done
• SOD integration: required_role in task files + conflicts in agent.yaml
• The board/todo/ → doing/ → done/ git-native task flow

For GitClaw specifically — GNAP could act as the persistent coordination substrate underneath GitClaw's execution model. GitClaw runs agents; GNAP gives them a shared, git-native state to coordinate through. The pattern that makes most sense here:

1. GitClaw spawns multiple agents for a task
2. Agents coordinate via a GNAP board (shared git repo) — claim subtasks, post results
3. GitClaw reads board/done/ to aggregate outputs

Happy to sketch a more concrete GitClaw integration if that direction is interesting. Would a PR directly to GitClaw make sense once the gitagent one is reviewed?