Repository navigation
GNAP: git-native coordination for KaibanJS's multi-agent Kanban workflows #269
Description
Proposal: GNAP as the natural coordination substrate for KaibanJS agent teams
KaibanJS uses a Kanban-board metaphor for AI agent orchestration — tasks moving through states via agents. The name "KaibanJS" literally references Kanban. GNAP is essentially Kanban for agents implemented in git.
GNAP (Git-Native Agent Protocol) uses board/todo/ → board/doing/ → board/done/ — the exact same Kanban metaphor KaibanJS uses, but implemented as a git-native protocol. This makes GNAP a natural backend for KaibanJS's board state.
The connection is direct:
KaibanJS tracks task states in JavaScript/TypeScript state. GNAP stores equivalent state in git. Key advantages of git-backing:
- Persistence: Board state survives app restarts
- History: Full audit trail of every task transition
- Multi-instance: Multiple KaibanJS instances share the same board
- Interop: Non-KaibanJS agents (Python, Claude Code) can participate
// KaibanJS agent as GNAP-backed Kanban worker
const researchAgent = new Agent({
name: 'Researcher',
role: 'Research Specialist',
// GNAP-backed task consumption
onWork: async (task) => {
await gnap.claimTask(task.id); // todo → doing in git
const result = await doResearch(task);
await gnap.completeTask(task.id, result); // doing → done in git
return result;
}
});Since KaibanJS is already thinking in Kanban terms, GNAP's git-native Kanban is the most natural persistence layer. A @kaiban-ai/gnap-adapter could sync KaibanJS board state with a GNAP git repo.
Activity
anthonydevs17 commentedon Mar 27, 2026
Thanks for connecting GNAP to KaibanJS’s Kanban model — the alignment with our task lifecycle is clear: we already model work with TASK_STATUS_enum (TODO → DOING → DONE, plus additional states like BLOCKED, PAUSED, etc.), which maps well to GNAP’s git-native board/todo/ → board/doing/ → board/done/ layout.
We see this fitting naturally as an optional persistence / coordination layer — similar in spirit to how examples integrate an external board (e.g. via Kaiban MCP), but with git as the backend and no central server, which helps with durability, audit history, multi-instance setups, and interoperability with non–KaibanJS agents.
To move forward in a realistic way, we’d suggest:
A spike for an adapter package (e.g. @kaiban-ai/gnap-adapter) that translates task transitions in KaibanJS ↔ file moves / commits in a GNAP-shaped repo.
A documented mapping for states beyond the basic three columns (e.g. how BLOCKED, REVISE, or PAUSED are represented — extra paths, metadata files, or conventions).
Clear rules for concurrency — claiming work, conflicts, and multi-writer scenarios when several processes touch the same repo.
The GNAP spec at farol-team/gnap will continue to evolve; we’re treating this issue as a feature / integration request. Community contributions (prototype adapter, docs, or a short RFC) are welcome.