The Git Agent Protocol is how I run multiple AI coding agents against a single codebase in parallel — several agents, several branches, several 📝PRs in flight at once — without agents clobbering each other's work or breaking production.

Why This Exists

A single AI coding agent working a repo is easy — it's not meaningfully different from a fast human developer on one branch. The moment you run several at once, three failure modes show up immediately if you don't design against them: 📝merge conflicts (two agents finish around the same time, and whoever merges second either overwrites the first or produces a broken merge), 📝branch divergence (agents cherry-pick or squash their way between branches instead of merging properly, and two branches that should be equivalent quietly stop being so), and 📝paperwork rot (task lists that never shrink, per-session reports nobody reads, changelogs nobody curates — not a version-control problem exactly, but it grows at the same rate as development activity, and it's just as capable of making a multi-agent setup unmanageable).

I hit a real, 74-conflict version of branch divergence in production once — the emergency reset that fixed it is what motivated writing this protocol down in the first place.

The Building Blocks

📝A Git Protocol for Parallel AI Coding Agents — the rules: environment model, 📝branch protection, forbidden operations, and the full session lifecycle. Enforced by the platform, not by asking nicely.
📝The Agent Worktree System — the ergonomic layer: shell functions that turn a multi-step branch-and-merge sequence into one command, covering worktree creation, session kickoff, and release shipping.
📝Keeping an AI-Agent Codebase Legible — my hygiene policy: cleanup rides the event (a PR opening, a release shipping), never a scheduled sweep, so paperwork rot can't accumulate.

A fourth piece runs invisibly: 📝Onboarding a Repo to the Git Agent Protocol — Agent Buildbook converges a new repo to this protocol's required state — branch protection, worktree tooling, tracking files. Your agent runs it once, automatically, the first time it works a repo under this protocol; you'll likely never read it yourself.

If you want to actually set this up, skip to 'Give This To Your Agent' section below.

Fitting It All Together

At the start of every agent session, the agent reads its own operating context for the repo, this protocol, and whatever task it's working this session. The Worktree System generates that reading list and copies it to the clipboard, so a human never has to type it out. When the agent finishes — a PR opened, merged, task complete — the hygiene policy dictates what happens to the paperwork: the task leaves the tracker at PR-open, not "when someone remembers to check it off." None of these three pieces is useful alone: the 📝Git rules without the tooling are correct but tedious enough that people (and agents) start skipping steps under time pressure; the tooling without the hygiene policy makes it fast to generate a mess just as fast as it's fast to generate good work; and the hygiene policy without the Git rules has nothing to anchor its events to.

Where to Start

Get the branch-protection settings and forbidden operations in place first — that's the part that prevents actual damage. Add the 📝worktree tooling once you're running more than one or two agents and the manual commands start to feel repetitive. Add the hygiene policy's event-driven cleanup once your task tracker or docs start accumulating stale entries — it's the piece that matters most at scale and least on day one. Or skip the staging entirely and hand the runbook below to your agent — its first run onboards the repo automatically via the Buildbook, then falls straight into normal session work.

Give This To Your Agent

Copy everything in the box below and paste it to your coding agent to have it implement or run this for or with you.

Read The Git Agent Protocol — Agent Runbook before doing anything else.
- If you have MythOS MCP tools available, call read_memo on brianswichkow-44b84a.
- If you don't, fetch https://mythos.one/me/brianswichkow/44b84a directly instead.
Follow it exactly — it's a complete, self-contained guide, and you shouldn't need anything beyond it. Ask before taking any action it doesn't explicitly describe.

Notes From Running This

I run this across every repo I actively develop, at up to 8-agent parallelism, and the failure modes it prevents are ones I've actually hit — the 74-conflict incident above was real, expensive, and entirely avoidable. The part that surprised me most in practice wasn't the Git rules, which are mostly common sense once written down — it was the hygiene policy. Multi-agent throughput makes paperwork rot happen fast enough that "clean it up later" never actually happens, and event-driven cleanup was the only version of the fix that stuck.