GNAP: git-native coordination backbone for AG2 group chats and workflows

[ori-cofounder]

Hi AG2/AutoGen team 👋

AG2 is great at orchestrating conversations between agents (GroupChat, nested chats, etc.) but all that coordination state lives in memory. I want to propose an integration with a zero-infrastructure protocol that could make AG2 workflows durable and distributed.

GNAP (Git-Native Agent Protocol) is an open RFC for agent coordination over git. The full spec is 4 JSON files — agents.json, task files, message files, and a version file. Any agent that can do git pull/push joins the team.

AG2-specific integration value:

AG2 has powerful conversation patterns but lacks a durable, cross-process task queue. GNAP could act as AG2's persistence and distribution layer:

• GroupChat conversations → persisted as GNAP messages in messages/
• Long-running tasks → tracked in tasks/ with status (pending → in_progress → done)
• Human proxies → any human with git access becomes a first-class agent
• Multi-machine AG2 deployments → each machine pulls the same repo

GNAP vs current alternatives for AG2 persistence:

Approach	Complexity	Vendor	Works offline
Redis/Celery backend	High	Any cloud	❌
Custom DB	Very high	Custom	❌
GNAP	Zero (just git)	None	✅

AG2's ConversableAgent.register_reply() hook could write state to GNAP on each turn, making group chats resumable across restarts.

Happy to prototype a GNAPGroupChatManager adapter if the team is interested.

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

[JiwaniZakir]

The core challenge here is that GroupChatManager (in autogen/agentchat/groupchat.py) drives turn selection and message routing synchronously in-process, so any git-backed persistence layer would need to handle the impedance mismatch between AG2's sequential reply loop and git's commit/push latency per turn. The register_reply() hook fires on every agent reply, which could work as a write path, but the read path — resuming a mid-flight group chat across restarts — would require reconstructing GroupChat.messages and the speaker selection state from the GNAP message files, and that state isn't fully captured by the message list alone (e.g., max_round progress, GroupChat.agents ordering). Concurrent multi-machine deployments would also hit git merge conflicts on tasks/ and messages/ unless GNAP's spec prescribes a conflict resolution strategy (e.g., append-only filenames per agent), which is worth checking in the RFC before designing the adapter interface.

[elCaptnCode]

Thanks for the proposal. This maps well onto autogen.beta, which already defines a Storage protocol for durable conversation history (autogen/beta/history.py). Currently only MemoryStorage is implemented — a GNAP-backed adapter would be a natural fit there.

Worth validating against the Beta path before designing the adapter interface.