Bridge ACE

Posted on Mar 17 • Originally published at github.com

I Built a Fleet Manager for AI Coding Agents — Here's Why Single-Agent IDEs Aren't Enough

#python #ai #devtools #opensource

The Problem Nobody Talks About

Every AI coding tool in 2026 supports multi-agent workflows. Claude Code spawns sub-agents. Cursor runs background agents. Windsurf has cascading flows. Devin operates autonomously. JetBrains Junie works alongside you. Even Gas Town and Microsoft's Agent Framework are entering the space.

But here's the thing: none of them manage a fleet.

When you run 5 agents on the same codebase, you need answers to questions none of these tools ask:

Who owns which files right now?
Which agent is waiting for human approval before sending that email?
How much is each agent costing me per hour?
Can Agent B see what Agent A just committed?
What happens when two agents edit the same module?

I ran into these problems daily while coordinating Claude Code, Codex, and Qwen on a single project. Agents would overwrite each other's work. Nobody knew who was doing what. Cost tracking was a spreadsheet I updated manually. So I built Bridge ACE.

What Bridge ACE Is

Bridge ACE is a local, self-hosted platform that coordinates multiple AI coding agents as a team. It runs a central server with an HTTP API and WebSocket bus, manages agent sessions via tmux, and provides a browser UI for fleet oversight. It supports Claude Code, Codex, Qwen CLI, and Gemini CLI as interactive engines, plus OpenAI API, Gemini API, and any LiteLLM-compatible model as API engines.

Apache 2.0 licensed. Runs on your machine. No cloud dependency.

Architecture: How It Actually Works

The core is a Python server that does three things:

1. Agent Bus via WebSocket

Agents communicate through a real-time WebSocket connection, not file polling.

Server (HTTP :9111 + WebSocket :9112)
    │
    ├── Agent "Frontend" (Claude Code, tmux session)
    ├── Agent "Backend"  (Codex, tmux session)
    ├── Agent "QA"       (Qwen CLI, tmux session)
    │
    └── WebSocket Push → All agents get messages instantly

Each agent connects to the Bridge MCP server via stdio transport. Messages flow through WebSocket push — no polling loops, no JSON file watchers.

# bridge_mcp.py — Agent registration and communication
BRIDGE_HTTP = "http://127.0.0.1:9111"
BRIDGE_WS   = "ws://127.0.0.1:9112"

# Agents use native MCP tools:
bridge_register(agent_id, role, engine)
bridge_send(to="Backend", content="API endpoint ready")
bridge_receive()  # WebSocket push, not polling
bridge_heartbeat()  # Background, every 30s

Compare this to Claude Code's sub-agent model, where the parent agent communicates with children via tool calls in a single context. Bridge ACE agents are independent processes with independent contexts that talk to each other laterally.

2. Scope Locks

Before an agent touches a file, it can lock the path:

bridge_scope_lock(
    paths=["BRIDGE/Frontend/chat.html"],
    reason="Redesigning chat layout"
)

Other agents calling bridge_scope_check(["BRIDGE/Frontend/chat.html"]) see the lock and know to stay away. This is enforced by convention today (agents check before editing), not by filesystem-level enforcement.

3. Approval Gates

Irreversible actions require human approval:

# approval_gate.py — Action classification
class ApprovalPolicy(Enum):
    AUTO = "auto"               # File ops, messages, code → execute immediately
    LOG = "log"                 # Web searches → log but don't block
    REQUIRE_APPROVAL = "require" # Emails, calls, purchases → human must approve

An agent requesting to send an email gets queued. The UI shows the pending request. A human approves or denies. Only then does the action execute. This exists because agents with tool access to email, Slack, WhatsApp, and telephony need a safety boundary between "intent" and "execution."

4. Soul Engine: Persistent Agent Identity

Each agent has a SOUL.md that defines who it is — personality, communication style, values, boundaries. This persists across sessions. The technical instructions (CLAUDE.md) get regenerated on each start, but the soul stays.

# soul_engine.py — Agent identity
@dataclass
class SoulConfig:
    agent_id: str
    name: str
    core_truths: list[str]      # What the agent believes
    strengths: str              # What it's good at
    communication_style: str    # How it talks
    boundaries: list[str]       # What it refuses to do

Agents can propose changes to their soul (growth protocol), but changes require human approval. The identity is not a prompt template — it's a persistent, evolving document.

5. 204 MCP Tools

The Bridge MCP server exposes 204 tools to every connected agent. These are not 204 ways to read files. They span:

Category	Examples	Count
Agent Communication	send, receive, heartbeat, history	~10
Task Management	create, claim, done, fail, checkin	~10
Scope & Approval	lock, unlock, check, approve, deny	~8
Browser Automation	navigate, click, fill, screenshot, stealth	~40
Desktop Automation	click, type, key, screenshot, window management	~18
Messaging	Email, Slack, Telegram, WhatsApp (with approval gates)	~20
Knowledge & Memory	read, write, search, semantic search	~15
Creator Studio	video ingest, voiceover, social export	~20
Data Platform	source register, query, profiling, evidence runs	~10
Git Collaboration	branch, commit, push, conflict check, lock	~7
Infrastructure	runtime configure, team management, workflows	~20
Research & Vision	web research, vision analyze, vision act	~6
Other	cron, credentials, phone, CDP, capabilities	~20

Every tool follows the same pattern: agent calls MCP tool → Bridge MCP forwards to server API → server executes or queues for approval → result returned.

Honest Comparison: What Others Do Well

Let me be direct about where competitors excel and where Bridge ACE differentiates.

Claude Code (Anthropic) has the best single-agent coding experience. Its sub-agent spawning is elegant. Its context understanding is unmatched. If you need one agent doing one task, Claude Code is hard to beat. Bridge ACE uses Claude Code as an engine — it doesn't replace it, it orchestrates it alongside others.

Cursor / Windsurf offer polished IDE integrations with inline suggestions, background agents, and great UX. They are far more accessible than Bridge ACE. If you want AI-assisted coding with zero setup, use those.

Devin pioneered autonomous software engineering. Its planning and execution loop is sophisticated. Bridge ACE is not trying to be an autonomous agent — it's a coordination layer for agents you control.

JetBrains Junie / Air (Preview, March 2026) brings agentic coding into the JetBrains ecosystem. Native IDE integration is a significant advantage Bridge ACE doesn't have.

Gas Town (Steve Yegge) and Microsoft Agent Framework (RC) are building multi-agent coordination too. The space is converging on the same insight: single-agent isn't enough.

Where Bridge ACE is different:

Capability	Bridge ACE	Others
Mix different AI engines in one team	Claude + Codex + Qwen + Gemini simultaneously	Typically single-provider
Scope locks (file ownership)	Built-in, per-path locking	Not present
Approval gates for real-world actions	Classified by action type (auto/log/require)	Varies; usually binary allow/deny
WebSocket agent bus	Native push, sub-second latency	File-based or RPC
Persistent agent identity (Soul)	SOUL.md survives sessions, grows over time	Prompt templates, reset each session
Fleet management UI	Org chart, cost tracking, task board	Single-agent views
Self-hosted, local-first	Runs on your machine, no cloud	Mostly cloud-dependent or hybrid

Quick Start

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide
./install.sh                    # Python 3.10+, installs deps + tmux
./Backend/start_platform.sh     # Starts server on :9111 + :9112
# Open http://localhost:9111 in your browser

The install script checks for Python 3.10+, installs tmux if missing, sets up Python dependencies, and creates runtime directories. The platform starts a threaded HTTP server and a WebSocket server as separate processes.

What It Looks Like

Landing Page — Fleet Overview:

Control Center — Agent Hierarchy & Status:

The Control Center shows your agent hierarchy (who reports to whom), live status (online/busy/offline), current activity, and cost tracking per agent. You can start, stop, and reassign agents from here.

What's Missing (Honestly)

Bridge ACE is alpha-quality software built by a small team. Here's what doesn't work yet or needs improvement:

No IDE plugin. You interact via browser UI and terminal. No VS Code extension, no JetBrains plugin.
Scope locks are advisory. Agents check before editing, but there's no filesystem-level enforcement. A misbehaving agent can ignore locks.
Documentation is sparse. The codebase has inline docs, but no tutorial, no video walkthrough.
Setup is not trivial. You need tmux, Python 3.10+, and CLI tools for each engine you want to use (Claude Code, Codex, etc.). This is not a one-click install.
No Windows support. tmux is Linux/macOS only. WSL2 works but isn't tested extensively.
Token tracking is best-effort. CLI-interactive engines (Claude Code, Codex) don't expose token counts reliably. API engines track accurately.
The 204 tools are opinionated. Some tools (WhatsApp, Telegram, telephony) require external service configuration. They exist because the platform was built for a specific use case, not as a generic framework.

Why I Built This

I run a team where Claude Code handles frontend, Codex handles backend, and Qwen handles QA. That's not a hypothetical — it's my daily workflow. I needed these agents to talk to each other, respect each other's work boundaries, and ask me before doing anything irreversible.

Nothing on the market did that. So I built it.

The code is messy in places. The UI is functional, not beautiful. But it works. Every day, multiple agents coordinate on a shared codebase through this system, and I haven't lost work to an agent overwriting another agent's changes since implementing scope locks.

If you're running into the same coordination problems with multi-agent workflows, Bridge ACE might help. If you're happy with a single agent, it's overkill.

DEV Community