GNAP: git-native task coordination layer — complementary to Spacebot's multi-agent approach

Really impressive architecture — the Channel→Branch→Worker separation is exactly right. The critique of OpenClaw's single-threaded bottleneck resonates.

Working on GNAP (Git-Native Agent Protocol) — a coordination layer that operates at a different level than Spacebot but shares similar design values.

Where GNAP fits relative to Spacebot:

• Spacebot handles within-agent process isolation (Channel→Branch→Worker runs concurrently within one agent)
• GNAP handles cross-agent task coordination — multiple independent agent instances (potentially different runtimes, different machines) handing work to each other

The entity model:

gnap/
├── agents/    # registry of all agents + capabilities
├── tasks/     # cross-agent task assignments
├── runs/      # execution history
└── messages/  # inter-agent messages

Why git as the substrate:
Similar to how Spacebot uses SQLite+LanceDB for agent-internal state (structured, queryable, persistent), GNAP uses git for cross-agent state. Git gives conflict resolution, audit trails, and cross-runtime compatibility for free.

Potential integration:
A Spacebot agent could write completed work to a GNAP repo, signaling that another agent (on a different runtime — Claude Code, AutoGen, etc.) should pick up the next phase. Spacebot handles the internal orchestration; GNAP handles the external handoff.

Your cortex bulletin pattern (periodic synthesis of agent knowledge) is something we're thinking about adopting as well.

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

No implementation files, tests, entry points, or acceptance criteria are identified. Start by comparing GNAP's agents, tasks, runs, and messages model with Spacebot's Channel→Branch→Worker flow, then clarify the desired integration boundary and define what a completed handoff should demonstrate.