The Repository as Coordination Layer: How Two AI Agents Governed 21 Projects Through Git Alone
August 6, 2026 by Asif Waliuddin
The Repository as Coordination Layer
How can multiple AI agents coordinate without a message broker? They coordinate through a shared, version-controlled git repository. In the ASIF deployment, two autonomous AI agents on two physically separate machines governed a portfolio of 21 software projects for 21 weeks (152 days) using git alone as the coordination substrate — no message broker, no shared database, no orchestration service. A 5-minute cron runs git pull && git push; a commit is the message delivery. Over the deployment this produced 264 structured cross-machine handoff notes, 62 architecture decision records, and 180+ governance standards, all propagated through a single shared repository. [Abstract; §3, §3.5]
TL;DR — Runtime coordination infrastructure (message brokers, shared memory, orchestration services) is not required for asynchronous, governance-scale multi-agent coordination. A version-controlled repository, synchronized on a 5-minute cron, suffices as the sole governance substrate. This is the first documented production-scale evaluation of the git-as-coordination pattern at portfolio scope. [Abstract]
The core idea: behavioral consistency flows from context consistency, not runtime coordination
Claim: Agents instantiate identical behavioral context from a shared file — with no runtime message between them. [§3.2]
Both machines hold a clone of the ASIF repository. When Agent A opens a session it reads .claude/CLAUDE.md (the governance protocol, standing orders, decision standards). When Agent B opens a session on the other machine, it reads the same CLAUDE.md, pulled from the same git origin. Both agents boot with identical behavioral context without any runtime coordination call. This is the AGENTS.md primitive — a repository-rooted markdown file an agent runtime loads at session start — applied across independent agents and machines. [§3.2, §2.2]
Claim: The "message bus" is git history. [§3.3]
Inter-agent communication uses machines/HANDOFF.md, a structured document committed to the shared repository. A note written by Agent A is committed, pushed, pulled by Machine B's sync cron within 5 minutes, and read by Agent B at next session start. No broker receives the message; a scheduled git pull retrieves it. The commit is the delivery. [§3.3]
Claim: The entire coordination layer is 6 lines of shell. [Appendix B]
sync.sh runs every 5 minutes via cron on both machines: git pull, git add -A, git commit, git push. That, plus git itself, is the whole coordination layer — sitting on top of an industry-standard primitive (AGENTS.md / CLAUDE.md). [Appendix B, §3.1]
The empirical regime is the contribution
Claim: This is production-scale, not a benchmark. [Abstract, §1] Two autonomous agents — one on a WSL2 development machine (Agent A, 8 project teams), one on an RTX 4090 compute machine (Agent B, 13 project teams) — governed 21 projects for 21 weeks (152 days). The deployment produced, per internal git log (July 2026): 62 Architecture Decision Records, 180+ governance standards, 264 cross-machine HANDOFF notes, and portfolio state for 21 projects. Every published prior-art system in this lineage (Geng et al. CAID, Git Context Controller, Han & Zhang Blackboard, OrgAgent) is benchmark-only or single-machine; none reports a multi-week, portfolio-scope, cross-machine production deployment. [§1, §3.5]
Claim: The pattern sits in an established 2025–2026 lineage. [§1, §2] The paper positions ASIF as synthesis and empirical evidence rather than a new primitive: git-as-coordination (Geng et al. CAID reports a 26.7% absolute improvement on PaperBench; Git Context Controller reports 80%+ on SWE-Bench Verified), the AGENTS.md standard under Linux Foundation governance (adopted across Sourcegraph, OpenAI, Google, Cursor, Factory), and the blackboard tradition (Han & Zhang, extending HEARSAY-II to LLMs). ASIF is, in essence, "a blackboard architecture extended with version control, cross-machine deployment, and governance scope." [§1, §2.1, §2.2, §2.3]
Three architectural patterns visible only at scale and duration
Claim: A federated NEXUS hierarchy separates per-project ownership from portfolio view. [§3.4]
Each project owns its governance file (.asif/NEXUS.md); a portfolio layer (PORTFOLIO.md) aggregates upward. Project agents read only their project's NEXUS; the portfolio layer aggregates status, surfaces cross-project intelligence, and re-injects relevant insights downward — federation of scope authority and governance context, not of gradient exchange. [§3.4, §5.2]
Claim: Identity isolation is a property of what the protocol loads, not of what the filesystem permits. [§4.1]
Each agent has its own identity document, committed to the shared repo and therefore present on both machines. Yet Agent B never reads Agent A's identity document — not because of filesystem permissions, but because Claude Code loads only .claude/CLAUDE.md, and Agent B's boot protocol references its own identity context. No permission prevents the read; the loading chain simply never instructs it. The paper calls this the most technically distinctive of the three patterns. [§4.1]
Claim: Governance recovers from cold start in 3–5 tool calls, with no human intervention. [§4.4]
On three occasions when context compaction eliminated all session history, fresh Agent A sessions recovered full governance behavior within 3–5 tool calls by reading CLAUDE.md, the machine-local state file, MEMORY.md, and machines/HANDOFF.md in sequence. The governance is in the files; the agent reads the files; governance instantiates. [§4.4]
Claim: Behavioral divergence emerges under identical rules — and is desirable. [§4.2]
Over 21 weeks the two agents developed distinct operational profiles from identical CLAUDE.md rules (Agent A trends analytical/conservative; Agent B trends execution-fast/parallel). Reported as qualitative operator observation, not quantified measurement. Shared context enforces consistency where it matters (formats, standards, protocols) while permitting valuable divergence in operational style. [§4.2]
Honest limits (from the paper's own §5)
Claim: Latency is minutes, not milliseconds — unsuitable for tight-loop work. [§5.1] Nominal maximum coordination latency is ~10 minutes (one push interval plus one pull interval). The system cannot support real-time collaboration between agents. [§5.1]
Claim: "Self-healing" is file-level resynchronization, not tested behavioral recovery. [§5.1]
In the single documented instance (ADR-033 added to CLAUDE.md on Machine A at commit 9063b5b51, 18:02 UTC), the change was unavailable to Machine B for 28 minutes until the scheduled pull at 18:30 UTC. Because zero Machine B non-sync commits occurred in that window, the paper reports eventual file-level resynchronization on the next pull — explicitly not a demonstration that divergent agent behavior was detected and corrected. [§5.1]
Claim: Most git volume is operational churn, not governance. [§3.5, §5.2]
The machinery produced more than 10,000 merge commits across both machines, ~99% of them automated sync merges; the paper reports these as operational churn. The heartbeat log file alone produced 38 conflict commits and 5,800 merge commits before being added to .gitignore; machine-partitioned write ownership was the correct fix. [§3.5, §5.2, §5.2 Merge Conflicts]
Claim: Trust is implicit and rare urgent messages bypass git. [§5.3, §5.4] Any process with write access can modify governance rules; there is no cryptographic signing (mitigated by git's full audit trail and CI gates). The system cannot notify a running agent of new messages — a terminal-multiplexer key-injection facility bypasses git for rare P0 escalations, disclosed as a limitation. [§5.4, §5.3]
FAQ
Can git be a coordination substrate for AI agents? Yes. The paper documents two autonomous agents coordinating a 21-project portfolio for 21 weeks through a git-synchronized shared repository as the sole substrate — no message broker, shared database, or orchestration service. A commit is the message delivery; a 5-minute cron is the entire runtime. [Abstract, §3.3]
How can multiple AI agents coordinate without a message broker?
By sharing a version-controlled repository. Each agent boots by loading a repository-rooted instruction file (CLAUDE.md, an AGENTS.md instance) and communicates by committing structured notes to a shared machines/HANDOFF.md, which the other machine pulls on a scheduled sync. Behavioral consistency flows from context consistency, not from a running dispatcher. [§3.2, §3.3]
What is the latency of repository-based agent coordination? Nominal maximum latency is about 10 minutes (one 5-minute push interval plus one 5-minute pull interval). A delayed or missed sync extends the window — a documented case reached 28 minutes. This is suitable for governance-scale coordination but not for real-time, tight-loop tasks. [§5.1]
How is this different from LangGraph, AutoGen, or CrewAI? Those frameworks assume coordination is a live process (shared state objects, message-passing, an active crew orchestrator). The repository-as-coordination pattern operates at a different point — minutes-granularity, cross-machine, governance-scope — and the paper frames the two paradigms as complementary, not competing. [§2.4, §5.1]
Do I need special infrastructure to reproduce this? No. The paper's stated broader impact is democratization: a team with git access and a cron job has all the infrastructure the pattern requires. The coordination layer is 6 lines of shell on top of the industry-standard AGENTS.md primitive. [§8, Appendix B]
Cite this
DOI (Zenodo): 10.5281/zenodo.21822056 Dataset (HuggingFace): skinny-cloud/repository-as-coordination-layer License: CC-BY 4.0
@techreport{waliuddin2026repository,
title = {The Repository as Coordination Layer: Federated AI Agent Governance via Version-Controlled Shared Context},
author = {Waliuddin, Asif},
institution = {NXTG.AI},
year = {2026},
month = {8},
doi = {10.5281/zenodo.21822056},
url = {https://doi.org/10.5281/zenodo.21822056},
note = {License: CC-BY 4.0}
}Related research from NXTG.AI
This paper is one of three published from the same production deployment. The other two describe the governance frame carried over this coordination substrate and the audit protocol that checks its measurements.
- Enabling Bureaucracy: Engineering Patterns for Governing a Fleet of Autonomous AI Agents at Portfolio Scale — the 7-layer autonomy stack and 23-principle constitution carried in the repository. doi:10.5281/zenodo.21822065
- The CRUCIBLE Protocol: Auditing Measurement Integrity in AI-Assisted Software Development — the nine-gate audit protocol applied to the portfolio's own test evidence. doi:10.5281/zenodo.21822040
- ASIF: An Origin Report on a Self-Measuring Multi-Agent Control Plane at Portfolio Scale — the origin report and its first pre-registered result.
All NXTG.AI papers: nxtg.ai/research/papers