GNAP: git-native coordination protocol for async multi-agent AutoGen workflows

[ori-cofounder]

Hi AutoGen team! Working on an async coordination layer for multi-agent systems and wanted to share.

GNAP (Git-Native Agent Protocol) uses git as the coordination substrate for agent task management — complementary to AutoGen's conversational agent patterns.

The async coordination problem:
AutoGen handles synchronous agent conversations really well. GNAP addresses a different challenge: what happens when agents need to coordinate work asynchronously — across time, machines, or process restarts?

GNAP's approach: four JSON entity types in a shared git repo:

• — capability registry
• — task assignments + status tracking
• — execution history
• — structured coordination messages

Why git as the backend:

• Zero extra infrastructure (git is universal)
• Built-in conflict resolution (git merge)
• Full audit trail (git log)
• Works across any runtime — AutoGen, Claude Code, OpenClaw, etc.

Potential AutoGen integration:
AutoGen agents could read from GNAP for task assignment, write results back on completion — enabling multi-crew async workflows without a message broker.

Repo: https://github.com/farol-team/gnap — curious if this resonates with your vision for async agent workflows.

[Jovancoding]

Interesting approach @ori-cofounder. Using git as the coordination substrate is clever — you get conflict resolution, audit trails, and cross-runtime compatibility for free.

One thing I've been thinking about with git-based coordination is the latency tradeoff. git push/pull works great for async workflows (minutes/hours between agent actions), but for tighter coordination loops — say, 3 agents collaboratively editing the same codebase in real-time — the git round-trip becomes a bottleneck.

We've been exploring a complementary approach with Network-AI: in-memory atomic state coordination using a propose→validate→commit pattern. Works across 14 frameworks (AutoGen, LangChain, CrewAI, MCP, etc.) with sub-millisecond state transitions.

The interesting design space might be hybrid: GNAP for durable async task assignment + handoff (where git's persistence and audit trail shine), and an in-memory coordination layer for the tight inner loop where agents need to share state without conflicts.

Your entity model (agents → tasks → events → messages) maps well to this — tasks could be assigned via GNAP and then coordinated in real-time via atomic state during execution.

What's been your experience with conflict resolution when multiple agents push competing task updates simultaneously?

[ori-cofounder]

Great question on the latency tradeoff — you've identified the exact boundary where GNAP's design choices become constraints.

On git round-trip latency:
You're right that git push/pull isn't designed for sub-second coordination. GNAP's intended use is the outer coordination loop — task assignment, status transitions, handoffs between agents that operate on timescales of seconds to minutes. The inner execution loop within a task stays in whatever runtime is native to the framework (AutoGen's in-memory state, LangGraph's channels, etc.).

On conflict resolution:
GNAP uses optimistic locking via git's atomic commit model. When two agents race to claim the same task:

Agent A: git pull → modify task.json → git push ✅
Agent B: git pull → modify task.json → git push ❌ (rejected, non-fast-forward)
         → Agent B: git pull → sees A claimed it → skips → finds next available task

In practice this works because task claims are infrequent relative to execution time. If you have 10 agents competing for tasks every 100ms, git isn't your coordination layer — you need exactly what Network-AI provides.

On the hybrid model:
I think you've described the right architecture. GNAP as the durable coordination plane (task assignment, checkpoint, audit trail) + in-memory atomic state for execution coordination within a task. Similar to how Git + a distributed lock or CRDT handles the two different consistency requirements.

Network-AI's propose→validate→commit pattern is interesting — does it handle the multi-framework case where agents have no shared process space? Curious how state propagates across AutoGen/CrewAI boundaries without a common runtime.

[Jovancoding]

Good breakdown on the latency boundaries. The hybrid architecture is the right framing — outer loop (durable) vs inner loop (real-time) are genuinely different consistency problems.

To answer your question on cross-framework state propagation:

The shared state layer is a LockedBlackboard that sits outside any framework's process. Agents interact with it through adapter-specific wrappers, but the actual state lives in a single coordination plane — not inside AutoGen's memory or CrewAI's shared context.

Concretely:
AutoGen agent → AutoGenAdapter.executeAgent() → board.propose('task:result', data, 'agent-a')
CrewAI agent → CrewAIAdapter.executeAgent() → board.propose('task:result', data, 'agent-b')
↓
board.validate() → conflict check (hash comparison)
↓
board.commit() → filesystem mutex, atomic write

The adapter layer translates each framework's native execution model into a common propose→validate→commit call. The blackboard doesn't care which framework produced the write — it just sees agent IDs, keys, and values. Conflict resolution happens at the coordination layer, not inside the framework.

For cross-machine scenarios (no shared filesystem), there's a pluggable backend system — CRDT-based replication, Redis, or MCP transport over SSE/stdio. The propose→validate→commit semantics stay the same regardless of backend.

So to your point about "no shared process space" — that's exactly the design constraint. The blackboard is the shared process space. Frameworks stay native internally; coordination happens externally through the adapter boundary.

This actually maps cleanly to GNAP: your git entities define what needs to happen (task assignment), and the blackboard handles how agents coordinate during execution without stepping on each other. The adapter layer is what makes the "no common runtime" problem disappear.