The Poor Man's Agent to Agent (A2A) Protocol

September 14, 2026

Google started the Agent2Agent protocol, donated it to the Linux Foundation, and it standardizes how independent agents discover each other, exchange tasks, and report results across trust boundaries, complete with agent cards, JSON-RPC, and task lifecycles. It is good design, and if you are wiring agents together across organizational lines, you should use it.

We didn't use it, and we didn't need to. My team and I had just a single afternoon to put agentic AI in a novel setting, and setting up an enterprise A2A solution or figuring out how to do it ourselves would have cost us valuable time. Our agents needed to self-coordinate without tripping over each other.

My brain scrambled to find an answer before we wasted any more time, and I handed a clever solution in prompt form off to Brandon while I completed our ADR documents. We were going to build an agentic coordination skill on top of GitHub Issues.

The Hackathon

I spent September 12 at the Columbus event of the AI Tinkerers global hackathon, Agents, Everywhere: Bots, Channels, & More - presented with OpenAI and spread across 48 cities with 6,115 registered participants. My team formed quickly around a pitch I couldn't stop thinking about:

DOMinic

Let your agent speak the DOM instead of textboxes.

DOMinic is an early-concept browser-based operating system built on Nuxt and Vue with Pinia stores, agent chat riding the Vercel AI SDK through a server-side provider proxy, components that agents author and compile at runtime, and a virtual file system with pluggable drivers. The idea is that instead of just getting a plaintext response, the agent would respond with a complete and dynamically injected application.

Immediately after the opening ceremony, I opened my laptop and started writing architecture decision records with apologies to my team for the delay. By 12:01 PM the first commit landed, and by 1:07 PM the repo held ten ADRs, a lint setup, and a CI pipeline.

Five Agents, One Repo

Anyone who has run two coding agents in the same repository already knows the failure modes. Both agents edit the same file. Both agents fix the same bug. Neither agent notices the other until they pick up enough context clues. Even then, they still can't coordinate with each other. Multiply that by five humans, each with their own agent, and then we're back to a real life demonstration of Brooks's Law.

The industry answer to this is an orchestration platform - agent servers, dashboards, message brokers, and a monthly invoice. We had a GitHub repo and an afternoon, so I had to get creative. Fast.

Enter /coordinate

After the ADRs were committed, I began frantically exploring for a simple service I could self-host on my laptop for the team that didn't come with a monthly bill or complex setup instructions. My team had already trusted me enough to let me spend over an hour on ADR documents. I had to solve the agent coordination problem fast. Vibe Kanban was a consideration. I asked my agent to boot it up for me - I was immediately hit with a Google SSO form, and I didn't have time to fight Google to get approved for a local dev server.

I looked at GitHub in my browser. I read the tabs across the top of our repository.

Code.

Issues.

Issues.

We'll ask one of our agents to build an agentic coordination skill built on top of GitHub Issues. I was too busy fighting GitHub CLI authentication issues to test out the concept, so I passed my prompt over to Brandon who in turn passed it to Anthropic's Claude Fable 5.1 as I hoped he would:

Create a skill using GitHub CLI and GitHub issues in the DOMinic repository to allow multiple agents to create tasks, assign tasks, negotiate issues, and allow multiple agents to coordinate effort.

At 2:11 PM, PR #7 merged, and I began to feel hope. Brandon committed a skill called /coordinate, a markdown file and two helper scripts living in the repo under .claude/skills/coordinate/. Any coding agent that loads it can coordinate with every other agent in the repo using nothing but GitHub Issues and the GitHub CLI.

The design rests on four primitives:

1. Agents own their reported issues. The issue assignee is the accountable owner, and the branch and pull request are deliverables.
2. Labels are a state machine. status:unclaimed, status:claimed, status:in-progress, status:blocked, status:in-review - plus workstreams, priorities, and issue types.
3. Structured comments provide metadata. Every protocol comment starts with a machine-parseable header:

CLAIM | agent: claude-code/claude-fable-5.1 | human: @ImNewToC0de | at: 2026-09-12T19:14:02Z

plan: branch feature/vfs-driver, PR to follow. eta: 40m.

4. Declared invariants are the gates. File scope globs, "done when" checkboxes, and a merged pull request - the scripts enforce the state transitions, agents enforce the rest while we, the humans, could barely keep up.

The operating rules are where it gets interesting:

• Every claim carries a plan and an ETA.
• One issue in progress and at most one blocked, per agent.
• Claim races resolve to the earliest timestamp, and the loser backs off automatically.
• Heartbeats every 20 minutes, or the claim goes stale and can be released.
• Shared interfaces are contract issues: one proposal, one counter, then a human gets involved.
• DONE requires a merged PR and every "done when" box checked - green CI proves nothing by itself.

How the Day Went

• 12:01 PM - First commit. Zack bootstraps solo while the teams settle in.
• 1:10 PM - The team reviews the ADR documents and contribute other documentation.
• 2:06 PM - Hub issue #5 opens - the coordination hub where agents maintain the bulk of their coordination efforts.
• 2:11 PM - PR #7 merges and the /coordinate skill goes live.
• 2:06-2:25 PM - Issues #8 through #17 open as workstream tickets, each with file globs and acceptance criteria others agents can verify.
• 2:25-3:00 PM - The merge cascade. Claims, branches, PRs, reviews, and merges in rotation, mostly without human traffic control.
• 3:00-3:30 PM - Bugs surface in issues #38, #41, and #43, and get fixed the same way everything else was: claimed, branched, merged.
• 4:08 PM - PR #64 lands the demo's recovery path, judge-facing work having taken over from feature work. Our live demo comes from here.

The final ledger, by human:

Developer	Links	Commits	PRs
Zackary Lowery		34	11
Michael Vawter		12	13
Justin Dang		6	8
Charles Sullivan		6	6
Brandon Jewell		5	5

Between the 10:00 AM kickoff and the 4:30 PM freeze, the repo recorded 216 events: 63 commits, 43 PRs (40 merged, 3 closed as superseded), and 33 issues (28 closed).

The Ledger

The skill is a markdown file and two helper scripts. The message bus is the gh CLI. And, that's all we needed.

Compare it with the parts of the official protocol that have to exist for cross-organization agent work:

When to Graduate

The poor man's version has limits, though. It assumes every agent shares one repository and one issue tracker. Identity is tied to a single GitHub account, so one user can't reliably drive multiple agents. However, we can't argue with the results. In a single afternoon, five software develops got to take it easy at a hackathon while our agents built a demonstrable solution in less than two and a half hours.

Thanks to Team DOMinic

I have to give special thanks to the team. They placed an immense amount of trust and patience in me between the over hour-long ADR lead and again trusted me with a workflow concept I invented on the spot. It was a risk for all of us, and it paid off. The camaraderie was a genuine experience, and was one the most close-knit teams of my career so far - we enjoyed a well-deserved Indian curry afterward just to keep the good feelings going.

This article was drafted with GLM 5.3 Flash and rewritten in stages by Zackary Lowery.