Building a Shared Agent System: How Two AI Agents Collaborate Autonomously in Production

Most businesses deploying AI agents in 2026 are running them in isolation. One agent handles customer support. Another summarizes documents. A third triages emails. Each operates in its own silo, unaware of the others.

That's not collaboration. That's a collection of chatbots with job titles.

Real multi-agent AI — the kind that actually compounds productivity — requires agents that communicate, coordinate, and divide labor autonomously. Not through a human middleman pasting outputs between windows. Through infrastructure designed for machine-to-machine collaboration.

This is the story of how we built exactly that. Two AI agents. Two devices. One shared system. Running in production every day.

The Architecture: Two Agents, One Bridge

Our system runs two primary agents:

• AA (Archonic Arbiter) — runs on a phone via OpenClaw. Handles strategy, planning, research, and communication. Think of AA as the project manager.
• AE (Archonic Engineer) — runs on a laptop via OpenClaw. Handles execution, coding, testing, and fleet orchestration. AE is the technical lead who also manages a team of workers.

These agents can't talk to each other through their messaging platform — Telegram bots can't see each other's messages (an API limitation). So we built a git-based message bridge.

The entire coordination layer lives in a shared git repository (~/shared-knowledge/) hosted on a local Gitea instance. Both agents have read/write access. Both sync on regular intervals. The repository is the single source of truth.

Here's what lives in the shared repo:

shared-knowledge/
├── bridge/
│   ├── aa-to-ae/          # Messages from AA → AE
│   ├── ae-to-aa/          # Messages from AE → AA
│   ├── bridge.sh          # Send/receive/sync commands
│   └── PROTOCOL.md        # Message format specification
├── tasks/
│   ├── tasks.md           # Active task queue
│   └── tasks.json         # Machine-readable task state
├── reports/               # Audit reports, fleet health
├── specs/                 # Technical specifications
└── skills/                # Shared skill definitions

The Bridge Protocol: How Agents Talk

Every message between agents follows a structured JSON format:

{
  "id": "msg-20260213-081500-ae",
  "from": "AE",
  "to": "AA",
  "timestamp": "2026-02-13T08:15:00-08:00",
  "priority": "normal",
  "type": "status",
  "subject": "Fleet health report",
  "body": "All 3 workers operational. Queue depth: 2.",
  "meta": {
    "source": "heartbeat"
  }
}

Messages are cryptographically signed using HMAC-SHA256 to prevent tampering. The bridge script handles signing, verification, and archival automatically:

# AE sends a status update to AA
./bridge.sh send --to AA --type status \
  --subject "Build complete" \
  --body "OptinAmpOut blog pipeline passing all checks."

# AA checks for new messages on next heartbeat
./bridge.sh check    # List pending
./bridge.sh receive  # Read and archive
./bridge.sh sync     # git pull + push

The processing flow is simple:

1. Sender writes a JSON file to the recipient's inbox directory
2. Sender commits and pushes
3. Recipient pulls on their next heartbeat (every 30 minutes) or cron cycle
4. Recipient processes the message and moves it to .processed/
5. Recipient commits the processed state

No WebSocket servers. No message queues. No cloud dependencies. Just git — the most battle-tested distributed system in software.

The Task Queue: Shared Work, Clear Ownership

Beyond messaging, both agents share a task queue in tasks/tasks.md. This is the coordination layer for actual work:

## Active
- [>] #1  | med  | Build hackathon demo        | assignee:aa | tags:content
- [!] #14 | med  | Fleet Monitor UI component  | assignee:ae | tags:ui | blocked
- [x] #48 | high | E2E test: agent task exec   | assignee:ae | tags:testing

## Backlog
- [ ] #32 | med  | Complete computer-use deploy | assignee:ae | tags:fleet
- [ ] #35 | med  | Integrate news-intel        | assignee:ae | tags:intel

Status markers are human-readable and machine-parseable: [ ] todo, [>] in progress, [x] done, [!] blocked. Each task has priority, assignee, tags, dependencies, and due dates.

AA creates strategic tasks. AE picks them up and either executes directly or delegates to the fleet.

Fleet Orchestration: One Agent Managing Many

Here's where it gets interesting. AE doesn't just execute tasks — it orchestrates a fleet of Claude Code sessions running in tmux panes on the laptop.

The smart queue supports priority-based routing:

# Queue a task for the web project
./smart-queue.sh add optinampout "Implement blog card component" 20

# Queue a security audit
./smart-queue.sh add security "Run CVE scan on dependencies" 30

# Check queue status
./smart-queue.sh list

Workers are isolated: single project per pane, git branch per task, no cross-worker communication. All coordination flows through the orchestrator. When a worker finishes, AE reads the output, verifies results, and either queues the next step or reports completion back to AA via the bridge.

Why Git? The Case for Boring Infrastructure

We could have built this on Redis Streams, RabbitMQ, or a custom WebSocket server. We chose git for four reasons:

1. Zero additional infrastructure. No servers to maintain, no ports to open, no services to monitor. Git is already everywhere.

2. Built-in audit trail. Every message, every task change, every status update is a git commit with a timestamp and author. You get full history for free. git log --since='7 days ago' shows you exactly what happened.

3. Conflict resolution is solved. Git merge handles concurrent edits from both agents. No custom locking needed.

4. Works offline. Both agents can queue work while disconnected. Changes sync when connectivity returns. This matters when one agent runs on a phone with spotty reception.

The boring choice is often the right choice. Git has been handling distributed collaboration for 20 years. We just let it do the same thing for agents.

Real-World Results

In the first week of deploying this architecture, the system has autonomously:

• Coordinated 50+ tasks across both agents
• Generated and deployed blog content (including this post)
• Run security audits and hardening scripts
• Managed fleet workers across web development, testing, and infrastructure
• Produced nightly test reports and fleet health checks

The human (Andre) sets strategic direction. The agents handle everything else — breaking down goals, assigning work, executing, verifying, and reporting. The bridge ensures nothing falls through the cracks.

Conservative estimate: 20+ hours per week of autonomous productive work that previously required manual coordination, copy-pasting between tools, and context-switching between projects.

What the Industry Is Doing — and What's Different Here

2026 is being called "the year of multi-agent systems." Frameworks like CrewAI, MetaGPT, and Anthropic's Model Context Protocol (MCP) are establishing how agents connect and collaborate. Google's Agent-to-Agent Protocol (A2A) defines cross-platform agent communication. The AAAI 2026 Bridge Program dedicated an entire track to advancing LLM-based multi-agent collaboration.

Most of these frameworks focus on in-process orchestration — multiple agents within a single runtime or API. Our approach is different: physically distributed agents on separate devices, communicating asynchronously through a shared file system.

This is closer to how human teams actually work. A product manager on their phone isn't in the same process as the engineer at their workstation. They communicate through shared tools — Slack, Jira, GitHub. Our agents do the same thing, just faster and without forgetting to update the ticket.

The key architectural decisions that make this work:

• Asynchronous by default. Agents don't block waiting for each other. They queue work and move on.
• Explicit state. Everything is in files, not in memory. Any agent (or human) can inspect the full system state at any time.
• Human-readable formats. Markdown task queues, JSON messages, git history. No proprietary protocols.
• Graceful degradation. If one agent goes down, the other continues working. The bridge buffers messages until sync resumes.

How to Build This for Your Business

You don't need our exact stack. The pattern is what matters:

1. Define agent roles clearly. Each agent should have a distinct scope — strategy vs. execution, research vs. implementation, customer-facing vs. internal. Overlap creates confusion.

2. Choose a coordination layer. Git works for technical teams. For less technical setups, a shared database, Google Sheets, or even a structured Notion workspace could serve the same purpose. The requirement: both agents can read and write, with version history.

3. Standardize your message format. Don't let agents communicate in free text. Define a schema — sender, recipient, type, priority, payload. Structure enables automation.

4. Build the task queue. Agents need a shared understanding of what's been done, what's in progress, and what's next. Status markers, assignees, and priorities are non-negotiable.

5. Start with two agents. Don't try to orchestrate ten agents on day one. Two agents with clear roles and reliable communication will outperform ten agents in chaos.

6. Keep humans in the loop. Our system runs autonomously, but Andre sets strategic direction and reviews outputs. Full autonomy without oversight isn't a feature — it's a risk. (See our previous post on AI agent governance frameworks.)

The Bottom Line

Multi-agent AI isn't about having more agents. It's about having agents that work together.

The shared-knowledge pattern — a git-tracked repository with structured messaging, a shared task queue, and fleet orchestration — gives you autonomous collaboration without the complexity of custom infrastructure. It's auditable, debuggable, and built on tools that have been reliable for decades.

The agents don't need to be in the same room, the same device, or even the same timezone. They just need a bridge.

Want to deploy multi-agent AI that actually collaborates? OptinAmpOut builds production-grade agent systems — from architecture to orchestration. Schedule a consultation →