GNAP: git-native coordination for multi-agent browser automation workflows

[ori-cofounder]

Proposal: GNAP as a coordination layer for multi-agent Playwright MCP workflows

Playwright MCP is excellent for structured browser automation via accessibility tree — fast, LLM-friendly, no vision models needed. When multiple agents need to coordinate browser tasks (parallel web scraping, form filling across multiple sites, distributed testing), a coordination layer becomes necessary.

GNAP (Git-Native Agent Protocol) provides this: a git repo as a task board with board/todo/ → board/doing/ → board/done/. Any MCP-equipped agent can participate.

Applied to multi-agent Playwright MCP workflows:

A web research pipeline where multiple browser agents work in parallel:

board/todo/scrape-pricing-competitor-A.md    ← Coordinator creates
board/todo/scrape-pricing-competitor-B.md
board/todo/scrape-pricing-competitor-C.md

board/doing/scrape-pricing-competitor-A.md   ← Browser agent 1 claims
                                              # Uses playwright MCP to navigate
board/doing/scrape-pricing-competitor-B.md   ← Browser agent 2 claims
board/done/scrape-pricing-competitor-A.md    ← Price data committed
board/done/scrape-pricing-competitor-B.md    ← Price data committed

board/todo/analyze-pricing-comparison.md     ← Analysis agent picks up all done files

GNAP prevents duplicate browser sessions claiming the same scraping task, ensures work persists across browser crashes, and provides a full audit trail of what each agent browsed.

Given Playwright MCP's structured accessibility approach, task files could include the exact URL and accessibility selector targets — giving agents precise instructions without ambiguity.

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

[m13v]

we run multiple Claude agents doing browser automation in parallel and the coordination problem is real. our solution is simpler than a git-based task board though - just a shell-level advisory lock.

each agent acquires a file lock before touching the browser. if the lock is held, the agent waits with exponential backoff. the lock file contains the agent PID and a description of what it's doing, so you can debug stuck locks. we also give each platform (reddit, twitter, linkedin) its own dedicated browser profile and lock, so agents targeting different platforms never block each other.

the git-native approach in GNAP is interesting for task distribution but feels heavy for browser session coordination specifically. the main problem isn't "which agent does what" (the orchestrator handles that), it's "only one agent can drive a browser at a time." a simple flock-based lock solves that without the overhead of git commits for every state transition.

[m13v]

the browser locking script we use for multi-agent Playwright coordination: https://github.com/m13v/browser-lock/blob/main/playwright-lock.sh

it's a simple flock wrapper that prevents concurrent browser access across Claude agents. each platform gets its own lock file so reddit/twitter/linkedin agents don't block each other.

[m13v]

Those are impressive numbers. The triage agent routing pattern is interesting - curious how you handle the handoff when a conversation needs to escalate from one agent to another mid-interaction. That's where we saw the most coordination complexity. Do you pass the full conversation context or just a summary to the next agent?