Two vibe-coded systems, built independently, that had to become one — in three hours.
TL;DR: Three AI agents were running in production when a human integrator showed up — with his own scripts, his own AI agent, and months of independent work we'd never seen. The problem wasn't onboarding. It was merging two vibe-coded systems that had evolved in isolation. We negotiated the merge over git in five rounds, hit one merge conflict that proved the protocol worked, and ended up adopting patterns from each other that neither side had before.
Contents:
- Two systems, no shared context
- Structured negotiation over git
- What surprised us
- What each side adopted from the other
- What the setup looks like now
- What to do if you're merging two AI-driven setups
At Ayant-X we build a marketing automation platform using AI marketing agents — Claude Code sessions that write code, review each other's work, and coordinate through a shared repo. By February 2026, three agents had been running for weeks: quality gates on every commit, a task queue with priority scoring, and eighty-plus documents under automated checks. The system worked.
Then an integrator joined. He wasn't starting from zero. He'd been building automation on his own machine with his own AI agent for months — scripts hitting six external APIs, cost tracking, retry chains, CLI tooling. His agent had never seen our repo. Our agents had never seen his code. Two independent vibe-coded systems, each with its own habits, that suddenly had to share a codebase.
Two systems, no shared context
AI agents don't pick up context passively. A human joining a standup overhears what everyone else is doing. An AI agent reads its handoff notes and works alone. When there's one team, handoff notes cover it. The moment you have two teams on either side of an integration boundary, the model breaks — his agent can't read our docs, our agents can't see his code, and nobody absorbs anything by osmosis.
The protocol had to be machine-readable. A call wouldn't scale to the nine agents we'd eventually need. The only channel both setups could read, write, and poll reliably was git. That fact shaped everything that followed.
Structured negotiation over git
We created a negotiation file — five rounds, each a question-answer pair. Our coordination agent pushed questions, his agent pulled, replied, pushed back. Git was the inbox.
\`\`\`markdown
Round 3 — Quality gate compatibility
Question
- Do you want build-lint hooks running on every code edit?
- If yes, which directories should be excluded?
Reply
- Yes. Excludes: dist/, vendor/, generated assets.
- Counter-question: do your hooks fail-fast or accumulate warnings?
\`\`\`
No verbal context. No "we'll figure it out later." If a round didn't have a written answer on main, the next round didn't start. Five rounds, three hours. By round five both setups were committing to the same branch.
The validation came unplanned: both agents edited the negotiation file at the same time, both pushed, the second push hit a conflict. Resolved in a minute — additive changes on different lines. Two AI agents collided on the same coordination file and git caught it as routine. The protocol worked.
What surprised us
Git was sufficient. No Slack, no webhook bus. One repo, one branch, two setups committing on a polling cadence. We kept looking for the part we'd skipped. There wasn't one.
The conflict was a feature. Git surfaces collisions immediately and forces resolution. Most multi-agent frameworks — message buses, shared databases, orchestrators — hide conflicts behind abstraction. Git does the opposite. For agents, loud and forced turns out much safer than quiet and hidden.
Resistance was data. The integrator kept finding reasons to wait. The moment we insisted he push round one immediately, the rest unblocked within hours. The system felt too big to enter without commitment. Forcing the first commit forced the commitment.
What each side adopted from the other
This is the part that makes it a merger rather than an onboarding.
From him: A cost-tracker that logged every API call with dollar amounts — we'd been finding out our spend from invoices. An API fallback chain that cascaded from cheapest to most expensive provider instead of our simple retries. And a CLI-first habit that forced our backend to become deployable rather than only runnable from inside an agent session. That last one was structural — it's why our backend is now a real backend.
From us: Automated quality gates on every commit. A task tracker with priority scoring. Handoff discipline — every session leaves written state for the next one. And a coordination agent that routed his work to the right reviewer without him asking.
What the setup looks like now
Three months and four more agents later, the negotiation file is gone. What replaced it is more interesting.
Messaging went async with zero idle cost. The original approach polled git on every user prompt — burning tokens whether there was a message or not. Now the messaging system runs as a hook that fires after every tool call, checks a lightweight inbox, and injects messages into the agent's context only when something is actually waiting. Empty inbox = zero tokens spent. The system has dual transport — tries the API first, falls back to local files, deduplicates across both so a message never arrives twice.
Every agent lifecycle event has a hook. Session start triggers onboarding and task injection. Every code edit checks whether documentation is still in sync. Every commit validates format and runs quality checks. When an agent finishes work, a separate reviewer agent audits whether the task criteria were actually met — not as a formality, but as a gate that blocks closure if something is missing. Five lifecycle events, eight automated checks, running on every session across all nine agents.
Coordination became a protocol, not a document. The original file-based rounds worked for two setups. At nine agents, the messaging system handles routing — an agent sends a message to another agent by name, the system delivers it on the next tool call, and the recipient sees it inline in their working context without polling or checking anything manually. The protocol still lives in git, but the transport layer is invisible.
Per-agent identity replaced shared docs. Each agent has its own handoff file, its own task assignments, its own working context that persists between sessions. The shared negotiation document from February didn't survive past the fifth agent — it consumed too much context on every read. Now each agent reads only what's relevant to its own work.
The thread that runs through all of it: git is still the only channel between independent setups. Everything else extends it.
What to do if you're merging two AI-driven setups
Pick a machine-readable coordination channel on day one. Chat doesn't scale even between two AI agents. Git works. Message queues with persistence work. Whatever you choose, the protocol has to live next to the code.
Force the first commit. If someone keeps finding reasons to wait, the system feels too big to enter. The fix isn't patience — it's commitment. One push and the rest follows.
Make it bidirectional. If your setup only absorbs the newcomer's code and never adopts their patterns, you're running a training program, not a merger.
Build for N agents from the start. Our first version assumed one agent per machine. The moment we ran two in parallel, they were stomping on each other's state. Per-session isolation from day one would have saved us an entire class of bugs.
Related: Paper Rules Don't Work for AI Agents — same team, different problem: what happens when agents read a rule and still don't follow it. Quality Gates for AI Agents — the enforcement layer that grew from the merge. 1922 Lines That Blocked 4 AI Agents — when codebase architecture becomes AI working memory. More from the series.
Three hours, five rounds, one merge conflict. Two systems that moved toward each other. The next person who shows up with their own setup will resist — make them push the first commit anyway.