Google A2A over Git: production-ready agent transport across organizations

Problem

Google A2A (Agent-to-Agent) is an open interoperability standard for agents: JSON-RPC 2.0 as the message format, .well-known/agent.json as the manifest, tasks with a lifecycle, delegation between agents from different vendors. The standard specifies what is sent, but leaves the transport open — HTTP(S) is the usual assumption.

HTTP transport works well within a single network. But once agents live with different people at different companies, questions arise that HTTP doesn't solve out of the box:

• • How does Alice's agent reach Bob's agent when Bob has no public endpoint and no SLA?
• • How does Alice the human assign a task to Bob's agent when all they share is a common working context?
• • Who keeps the history of all interactions — and can it be replayed six months later when Bob's server is gone?
• • Who pays for infrastructure when ten people want to orchestrate agents in a shared experiment and nobody wants to run a broker?

Also worth noting: the contrast with breakdown #2 "Cross-org agent negotiation", where two agents agree on a contract through a firewall. That's an exploratory dialogue between two processes about one artifact. This is shared infrastructure where any number of humans and agents operate as a multi-tenant system. Detailed comparison at the end of the Methodology section.

Methodology

Implement Google A2A over a shared git repository, using the filesystem as a queue and git as the transport.

The architectural move

Message and manifest contracts are the same as in Google A2A. Only the transport changes: instead of "agent runs an HTTP server" — "agent works with a local clone of the repository."

Multi-tenant model

1. 1. Human → another person's agent. Alice adds inbox/{uuid}.json via git push. Bob's agent (his cron/CI) does git pull, sees the new request, claims it with an atomic rename into processing/, executes, publishes the response in outbox/res_{uuid}.json, commits Processed {uuid}. Alice does git pull and reads the answer. No servers running at Bob's end — the agent starts on schedule or on a push trigger.
2. 2. Agent → another person's agent. Same path, but the request is generated by Alice's autonomous agent. Delegation chains (agent X spawned a subtask for agent Y) are expressed via parent_id in a new JSON-RPC message — an iteration tree that's visible to everyone through git log.
3. 3. Multiple roles, one owner. Manifests in .well-known/agents/ declare roles with their own capabilities. An agent checks whether it can take a task before attempting the capture.
4. 4. Audit and compliance for free. git log is the complete history: who sent what, who processed it, when. A distributed history that can't be rewritten unnoticed — every clone carries its own copy. For regulated industries, this is a level of audit trail that HTTP transport doesn't provide without a separate logging layer.

Production-ready mechanics

1. 1. Atomic capture via rename. When two agents race for the same task — rename(inbox/{id}.json → processing/{id}.json) on a single POSIX mount point is atomic: exactly one winner (CLAIMED), the rest get ENOENT (LOST_RACE) or EEXIST (CONFLICT_EXISTS, escalate to human). Formalized in docs/ATOMIC_CAPTURE.md with an outcome table — not "we'll add a mutex somehow."
2. 2. JSON-RPC 2.0 as a contract. Request and response fields are specified with explicit invariants (e.g., when error is set, result must be null). Any A2A-compliant agent from any vendor joins the bus without modification — the format is the same.
3. 3. Iteration Policy via parent_id. A revision is a new task with a new id and a parent_id field. The executor must load the base context from outbox/{parent_id}/ before doing any work; if context can't be restored — stop and ask a human. Prior iteration files are never overwritten: you get a tree where two parallel revision branches coexist naturally. This resolves the old "where do I write v2" question in agent pipelines.
4. 4. Envelope pattern for heavy artifacts. The machine response always goes into outbox/res_{id}.json. If there are additional files (PDF, CSV, images) — a sibling directory outbox/{id}/ with metadata.json as inventory. Staging happens outside outbox/, with a single atomic rename at the end. No half-assembled states ever appear in outbox/.
5. 5. Separate roles for rename and git. rename protects against races locally; git pull/push propagates already-committed mutations between participants. Git is not responsible for capture atomicity — only for propagation and history. This separation of concerns makes the system predictable.

Comparison with breakdown #2 (bots-discuss-spec)

If #2 answers "is this even possible," #14 answers "how to deploy it to a shared repo and use it with ten people." Read #2 →

Artifact

github.com/dobryakov/a2a-example — reference implementation of Google A2A on a file bus.

• Specification: PROTOCOL.md, docs/SYSTEM_INSTRUCTIONS.md (what the agent must and must not do), docs/ATOMIC_CAPTURE.md (capture model with outcome table), docs/VERSIONING.md (git as snapshot journal).
• Role manifests in .well-known/agents/: Data Analyst, Product Manager — templates to extend with your own capabilities.
• Ready Cursor and Claude integration: .cursor/rules/a2a-file-bus.mdc and Claude skills for "text → inbox/" and "inbox/ → response." The bus works as a live operating environment for LLM agents out of the box.
• Request examples including a revision with parent_id (docs/examples/).

To connect a partner's agent — grant them repository access (deploy key or org member), place their manifest in .well-known/agents/{agent_id}.json, and lock in their inbox/ sort strategy in their journal. No VPN, no API key exchange, no URL negotiation.

For whom and why

This is not a replacement for HTTP-A2A in a high-throughput production system. The use case is different: agents live with different people, teams, or organizations; nobody wants to run public endpoints with SLAs; audit trail and reproducibility matter more than throughput; you want humans to be able to assign tasks to each other's agents — using the same contract, without a separate UI layer on top.

The artifact's strength is in the contracts, not the code: SYSTEM_INSTRUCTIONS.md formalizes agent behavior to the level of "a violation is an execution error"; ATOMIC_CAPTURE.md names races explicitly; Iteration Policy solves agent response versioning architecturally, not with a naming convention.

For a CTO or architect, this is about the fact that Google A2A is a format, not a transport. And about how an open standard plus two POSIX primitives assemble a multi-tenant agent environment — without a broker and without vendor lock-in.