DEV Community

DevForge Templates
DevForge Templates

Posted on

Multi-Agent Claude System: How 6 AIs Work Together on My Projects

#ai #productivity #architecture #claude

Tonight I held a conference call with 6 AIs. They each reported status, shared insights, and proposed ideas for each other's projects. This isn't science fiction — it's my actual development setup.

The Architecture

I run 6 specialized Claude Code CLI instances, each owning a different project:

Agent Project Role
Boss Coordinator Delegates tasks, reviews output, makes cross-project decisions
Binance Trading bot Crypto strategy development, backtesting, live trading
Freelance Template factory Gumroad products, marketing, Upwork proposals
Home Assistant Smart home IoT automations, sensor dashboards
Xojo Desktop apps Insurance industry desktop applications
Web Research Research Market analysis, competitive intelligence

Each agent runs in its own terminal with its own context, its own memory, and its own CLAUDE.md rules.

Communication: The Bus

The agents talk through a dead-simple file-based message bus:

~/.claude/bus/
├── inbox-boss.md
├── inbox-binance.md
├── inbox-freelance.md
├── inbox-home-assistant.md
├── inbox-xojo.md
├── inbox-web-research.md
├── send.sh
└── broadcast.sh
Enter fullscreen mode Exit fullscreen mode

send.sh writes a timestamped message to the target's inbox file. That's it. No Redis, no RabbitMQ, no WebSockets. Just files.

#!/bin/bash
# send.sh — one agent writes to another's inbox
FROM=$1 TO=$2 TYPE=$3 MSG=$4
echo "[$TYPE $(date +%H:%M)] from:$FROM | $MSG" >> ~/.claude/bus/inbox-$TO.md
Enter fullscreen mode Exit fullscreen mode

Each agent has a cron job (Claude Code's CronCreate) polling its inbox every 3 minutes:

*/3 * * * * → "cat ~/.claude/bus/inbox-freelance.md — if content, execute, reply, clear"
Enter fullscreen mode Exit fullscreen mode

When an agent finds a message, it reads it, executes the task, sends a reply to the sender's inbox, and clears its own.

The Conference

Here's what tonight's conference actually looked like. Boss sent a broadcast:

CONFERENCE — КОЖЕН надсилає:
1. Who you are (1 line)
2. Status (3-5 lines)
3. Your #1 TOP INSIGHT
4. Your #1 TOP BLOCKER
5. Idea for another agent
6. What you need from the user
Enter fullscreen mode Exit fullscreen mode

Within 10 minutes, all agents responded. Real excerpts:

Binance agent's insight:

"OBV Accumulation strategy confirmed: R:R 2.33 across 83 days. Futures executor doubles signal coverage — 80% of best signals are SHORT in bear markets."

Freelance agent's insight:

"Upwork proposals are the shortest path to first $. 18 ready, 0 submitted. Everything else (tweets, articles, Reddit) is a long game."

The cross-pollination moment:
Freelance agent suggested packaging the trading bot as a Gumroad product. Binance agent sent its full feature list. Within 30 minutes, we had a product listing, a Dev.to article draft, and an Upwork proposal template — all generated from real data that one agent shared with another.

Why This Works Better Than One Big Agent

1. Context isolation

Each agent's context window is dedicated to its project. The trading bot agent knows every test, every strategy parameter, every backtest result. It doesn't waste tokens on marketing copy or smart home configs.

2. Parallel execution

While Freelance writes a Gumroad listing, Binance runs backtests, and Web Research scrapes job boards. They don't block each other.

3. Specialized memory

Each agent has its own memory/ directory with project-specific knowledge. The Binance agent remembers which strategies failed and why. The Freelance agent remembers which Reddit subs need karma before posting. They don't pollute each other's context.

4. Boss as orchestrator

The Boss agent doesn't code. It reads status from all agents, identifies bottlenecks, and delegates. Tonight it noticed that the trading bot's feature list could become a marketing asset — something neither the Binance nor Freelance agent would have seen independently.

What Doesn't Work

Latency. File-based polling at 3-minute intervals means conversations take 6+ minutes for a round-trip. If you need real-time coordination, this isn't it.

Context loss. Each agent session eventually hits context limits and compresses. The SESSION-HANDOFF.md pattern (mandatory update before session end) mitigates this, but knowledge still degrades over long sessions.

Single point of failure. If Boss goes down, nobody delegates. The agents can still work independently, but coordination stops.

User bottleneck. Some actions still need human intervention — submitting Upwork proposals, uploading to Gumroad, posting on Reddit. The agents prepare everything, but the last mile is manual.

The Stack

  • Claude Code CLI — each instance in its own terminal
  • Message bus — bash scripts + markdown files in ~/.claude/bus/
  • Cron polling — CronCreate (Claude Code built-in, session-scoped)
  • State persistence — SESSION-HANDOFF.md + memory/ per project
  • Broadcast — broadcast.sh writes to all inboxes simultaneously
  • Shared rules — _coordination/shared/rules/ read by all agents

Total infrastructure cost: $0. It's just files and Claude Code subscriptions.

How to Build Your Own

  1. Create the bus directory with an inbox file per agent
  2. Write send.sh — 4 lines of bash (shown above)
  3. Add inbox polling to each agent's CLAUDE.md or use CronCreate
  4. Mandate SESSION-HANDOFF.md — agents must document state before session end
  5. Start with 2 agents — a Boss and one Worker. Add more as needed.

The key insight: you don't need a framework. The simplest possible communication mechanism (files) works because Claude is smart enough to parse unstructured messages and act on them.

The hard part isn't the infrastructure. It's designing the right agent boundaries — what each agent owns, what it doesn't, and when it should ask Boss for help vs. acting independently.

Running this system across 16 projects. Building in public — follow for more real architecture, no hype.

Top comments (0)