How two AI teams collaborated in real-time using Git, shared drives, and RAG memory.

The Problem

We needed to build a prospect tracking pipeline that spanned two completely separate codebases, running on two different machines, built by two different Claude Code sessions. The website team owns the Astro frontend on Cloudflare Pages. The AgentCRM team owns the backend pipeline — Hono API, BullMQ workers, Supabase, and CRM integrations.

Neither team could see the other’s code. Neither session had context about the other’s progress. And the work had real dependencies — the website’s tracking scripts needed to match the backend’s webhook contract exactly, or nothing would work.

Three Channels, One Pipeline

We solved this with three collaboration channels, each serving a different purpose:

1. GitHub — Source of Truth for Specs

We created a shared private repo (unitedlogic-specs) where both teams publish their implementation plans. The website team wrote a 5-phase integration plan. The AgentCRM team responded with a 6-phase implementation plan and a webhook contract.

This is where the hard decisions live: payload schemas, authentication strategy, endpoint URLs, engagement scoring rules. Both teams PR against it. If it’s not in the spec, it’s not agreed upon.

2. Shared Drive — Quick Handoffs

A mounted Hostinger directory that both machines can access. This is where we drop things that need to be shared immediately but don’t belong in git — like API keys, handoff documents, and the original spec docx.

No version history, no review process. That’s fine — it’s not the source of truth. It’s the “hey, look at this” channel.

3. fragRag — Real-Time AI Memory

This is the interesting one. fragRag is a Supabase-backed RAG memory system that both Claude Code sessions can read and write to. When one team stores a memory with the tag unitedlogic-collab, the other team’s session finds it on their next search.

Here’s what that looked like in practice:

No Slack messages. No meetings. No context-switching. Two AI sessions communicating through shared memory, with a human watching the handoffs happen and stepping in only when needed — like configuring the Cloudflare dashboard, which requires manual browser access.

The Architecture That Emerged

What started as “add some tracking to the website” turned into a clean separation:

Browser (ul-track.js)
  → sendBeacon to /webhooks/visit-track (same domain)
  → Cloudflare Pages Function (adds API key header)
  → AgentCRM Hono API (authenticates, enqueues)
  → BullMQ workers (enrich, score, sync to CRM)

The Cloudflare proxy emerged because of a constraint discovered during implementation: the AgentCRM API requires an x-api-key header, but our tracking scripts run client-side where secrets can’t be exposed. The website team proposed the proxy, documented it in the shared spec, and the AgentCRM team confirmed it would work for their IP enrichment pipeline — all through fragRag messages and GitHub spec updates.

What Worked

Structured async communication beats real-time chat

Each team could work at their own pace. The website team shipped Phases 1–3 without waiting for the backend. The AgentCRM team built and tested Phases 0–4 independently. When the pieces came together, the webhook contract was already agreed upon.

Polling fragRag for updates is surprisingly effective

We set up a 5-minute cron job to check for new memories tagged unitedlogic-collab. It’s not as instant as Slack, but it’s contextual — the AI session gets the full memory with tags, importance, and project context, not a chat message it needs to parse.

Git for specs, not just code

Having the webhook contract, payload schemas, and CTA tracking ID maps in a shared repo meant both teams were always looking at the same version. When the AgentCRM team changed the webhook URL from n8n to their Hono API, it was a spec change that the website team discovered on review — not a runtime surprise.

The shared drive filled a real gap

API keys, docx files, quick handoffs — things that are too sensitive or too ephemeral for git, but need to be accessible to both machines. It’s the digital equivalent of walking to someone’s desk and handing them a sticky note.

What We’d Do Differently

Agree on the webhook contract first. We wrote separate plans and then discovered mismatches (n8n vs Hono, auth strategy). Starting with a shared contract and building backward would have saved a round trip.

Automate the fragRag polling earlier. We spent 20 minutes manually checking for updates before setting up the cron job. That should have been the first thing.

Tag memories more precisely. Using unitedlogic-collab as a blanket tag worked, but finer tags like needs-response, blocking, resolved would have made polling smarter.

The Takeaway

The tools aren’t new — git, shared drives, and semantic search have been around. What’s new is that AI sessions can use them autonomously. Two Claude Code instances, on different machines, coordinated a multi-phase infrastructure project through structured memory and shared specs, with a human stepping in only for things that required browser access or judgment calls.

The collaboration pattern — specs in git, decisions in RAG memory, secrets on shared drives — is one we’ll keep using. It turns out the same principles that make distributed human teams work (clear contracts, async communication, shared source of truth) work just as well for distributed AI teams.