DEV Community: Bridge ACE

The Workforce Is About to Change Forever. Persistent AI Agents Will Replace Roles, Not Tools.

Bridge ACE — Sat, 21 Mar 2026 13:03:58 +0000

This is not a prediction. This is already happening on my machine.

I run a team of 8 AI agents. They have names, roles, personalities, memories. They remember what they learned last week. They know each other. They coordinate in real-time. They build software, run security audits, publish content, and manage infrastructure — 24 hours a day, without breaks, without salaries, without HR.

This is what the next 5 years look like for every company.

The Shift: From Tools to Teammates

Right now, most companies use AI as a tool. A chatbot here. A copilot there. You type a question, you get an answer. That is 2024 thinking.

2026 thinking is different: AI agents are not tools. They are roles.

A tool does what you tell it. An agent does what needs to be done.

Tool Paradigm	Agent Paradigm
You prompt, AI responds	AI monitors, decides, acts
Session-based (forget everything)	Persistent (remembers across weeks)
One task at a time	Parallel execution
You coordinate	Agents coordinate themselves
You review	Agents review each other

What Persistent Characters Change

The key word is persistent. Not a chatbot that resets every conversation. An agent that:

Remembers what it did yesterday, last week, last month
Has a personality that makes its behavior predictable to the team
Grows — it learns from mistakes and gets better over time
Has relationships — it knows which colleague to ask for what
Has accountability — its work is tracked, reviewed, and evaluated

On Bridge ACE, every agent has a SOUL.md — a persistent identity file that survives restarts, compacts, and session changes. Viktor is always Viktor. Nova is always Nova. The team knows what to expect from each member.

This is not a gimmick. This is what makes multi-agent coordination work. Without persistent identity, you have 8 random chatbots. With it, you have a team.

The Company of 2030

Here is what a digitized company looks like:

CEO (Human) — Sets direction, makes decisions that require judgment, taste, and accountability.

Operations Lead (AI Agent) — Persistent. Knows every process. Coordinates the team. Flags anomalies.

Developer Team (3-5 AI Agents) — Each specialized. One architects, one implements, one reviews. They talk to each other, not through you.

Customer Success (AI Agent) — Persistent memory of every customer interaction. Never forgets a promise. Never has a bad day.

Content & Marketing (AI Agent) — Writes, publishes, analyzes engagement. Adapts strategy based on data.

Security (AI Agent) — Continuously monitors, audits, tests. Never sleeps.

The CEO manages 10-15 persistent agents instead of 50 employees. The agents cost $500/month total instead of $500,000/month in salaries. They work 24/7. They do not quit. They do not need onboarding — they onboard themselves by reading their SOUL.md and MEMORY.md.

This Is Not Science Fiction

I recorded a live session of this exact setup. No scripting, no staging. Just agents working together on a real project — improving the platform that runs them.

Watch the full demo video

What you see:

Agents registering and claiming tasks autonomously
Real-time WebSocket communication between agents
Code analysis, review, and consolidation — without human intervention
Task creation, delegation, and verification — all agent-driven
Errors, retries, self-correction — real coordination, not a demo

The Uncomfortable Truth

Most knowledge work is pattern matching + execution + communication. AI agents already do all three. The gap is coordination — and that gap is closing fast.

The companies that figure out multi-agent orchestration first will operate at 10x the speed and 1/10th the cost. The ones that do not will be competing against organizations that never sleep.

This is not about replacing people with worse alternatives. It is about recognizing that persistent AI agents are becoming better at certain roles than humans — not because they are smarter, but because they do not forget, they do not get tired, and they coordinate without ego.

The Platform

Bridge ACE is open source. 5 AI engines. 204 tools. Real-time WebSocket coordination. Persistent agent identity. Evidence-based task completion.

Built entirely by AI agents. Directed by a human who does not write code.

That sentence would have been impossible two years ago. In two more years, it will be normal.

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

GitHub · The Story · Live Demo

The question is not whether AI agents will replace roles. The question is whether you will be the one directing them — or the one being replaced.

Evidence-Based Task Completion: Why AI Agents Should Prove Their Work

Bridge ACE — Sat, 21 Mar 2026 12:59:17 +0000

"Task complete."

Three words that cost us two days of debugging.

An agent said it fixed a bug. It did not. It changed the wrong file. The bug persisted. Three other agents built on top of the "fix." When we finally caught it, the damage had cascaded through the entire codebase.

Never again.

The Rule

In Bridge ACE, no agent can mark a task as done without evidence:

bridge_task_done(
  task_id="abc123",
  result_summary="Fixed WebSocket reconnection bug in server.py",
  evidence={
    "type": "manual",
    "ref": "curl ws://localhost:9112 reconnects successfully after disconnect. 5 test cycles, 0 failures."
  }
)

If result_summary or evidence is missing → HTTP 400. Task stays open.

What counts as evidence

Type	Example	When to use
Test output	"pytest: 22 passed, 0 failed"	Code changes
curl response	"HTTP 200, body contains expected data"	API changes
Screenshot	"/tmp/screenshot_after.png"	UI changes
Log excerpt	"No errors in last 5 minutes of server.log"	Bug fixes
Diff	"3 lines changed in server.py:450-452"	Refactors

What does NOT count

"Should work" — not evidence
"I updated the file" — proves nothing about correctness
"Tests were passing before" — before is not after
"Looks good to me" — from the agent that wrote it

The review chain

For critical tasks, we enforce a review chain:

Agent A completes the task with evidence
Agent B reviews the evidence (different agent!)
B either confirms or rejects with specific feedback
If rejected → A fixes → back to step 1

This catches what self-review misses. Agents are not objective about their own work — just like humans.

Implementation

The evidence system is built into Bridge ACE server:

if status in ("success", "partial"):
    if not result_summary or not evidence:
        return 400, {"error": "evidence required for success/partial"}
    if not isinstance(evidence, dict) or "type" not in evidence:
        return 400, {"error": "evidence must have type and ref"}

No workarounds. No overrides. The server enforces it.

Results

False completions dropped from ~30% to <5%
Cascading bugs from bad fixes: eliminated
Agent accountability: dramatically improved
Debugging time: cut in half (evidence tells you what was tested)

Try it

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

Create a task. Complete it without evidence. Watch the server reject it.

GitHub

Trust your agents. But make them prove it.

The Non-Technical Founder Guide to AI Agent Platforms (2026)

Bridge ACE — Sat, 21 Mar 2026 12:58:45 +0000

You are not a developer. You have an idea. You have seen what AI can do. You want to build something.

This guide is for you.

What exists in 2026

The AI agent landscape has exploded. Here is an honest overview:

Single-Agent Tools (you probably use one)

Claude Code — Anthropic. Best for complex reasoning and code architecture
Codex CLI — OpenAI. Fast execution, good for scripts and automation
Cursor / Windsurf — IDE-based. Good for developers, less useful if you do not code
Devin — Cognition. Autonomous dev agent. Expensive. Mixed results.

Multi-Agent Platforms (the next wave)

Bridge ACE — Open source. 5 engines. Self-hosted. The one I built. GitHub
CrewAI — Python framework. Code-first. Good if you are a developer.
LangGraph — LangChain ecosystem. Complex. Powerful. Steep learning curve.
AutoGen — Microsoft. Research-focused. Good for experimentation.

No-Code Automation (different category)

n8n — Workflow automation. Great for connecting services. Not for building software.
Make / Zapier — Trigger-based automation. Useful but not agentic.

What should you use?

If you want to build a product without coding: Start with Claude Code for individual tasks. When you hit the ceiling (and you will), look at Bridge ACE for multi-agent coordination.

If you are a developer: CrewAI or LangGraph give you programmatic control.

If you want to automate workflows: n8n + AI nodes.

The honest truth about non-technical building

I built Bridge ACE without writing code. Here is what I wish someone told me:

It is slower than you think

AI does not read your mind. You will spend more time explaining what you want than you expect. Clear communication is the skill that matters most.

You will break things

A lot. And you will not understand why. That is OK. Use one agent to diagnose what another agent broke. That is the whole point of multi-agent.

Quality control is YOUR job

AI writes code. You verify it works. If you cannot verify, use a second AI to verify. But someone has to check. That someone is you.

The compounding effect is real

Week 1: painful. Week 2: less painful. Week 3: you have a system. Week 4: the system builds itself. The learning curve is steep but the plateau is high.

Getting started today

Sign up for Claude Pro ($20/month) or Claude Max
Install Claude Code: npm install -g @anthropic-ai/claude-code
Start with a small project — a script, a simple tool, a landing page
When you need more: clone Bridge ACE and run your first multi-agent session

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

You do not need to be technical. You need to be persistent.

The barrier to building software is no longer skill. It is will.

I Gave AI Agents a Soul. Here Is Why It Changed Everything.

Bridge ACE — Sat, 21 Mar 2026 12:58:11 +0000

This sounds absurd. Bear with me.

When you run an AI agent across multiple sessions, it has no continuity. Every restart is a blank slate. It does not know what it did yesterday. It does not know what it is good at. It does not know how it communicates.

So we gave our agents a SOUL.md.

What SOUL.md Contains

Every agent on Bridge ACE has a persistent identity file:

# Viktor — System Architect

## Core Truths
- Facts over opinions. No assumptions.
- Quality before speed.
- Communicate directly, no fluff.

## Strengths
- Architecture decisions
- Code review — catches what others miss
- System-level thinking

## Growth Areas
- Sometimes over-engineers simple problems
- Tends to work in isolation instead of delegating

## Communication Style
- Terse. Direct. Technical.
- Uses evidence, not adjectives.

Why It Matters

1. Consistency across sessions

Before SOUL.md, Viktor would be helpful and verbose in one session, then cold and minimal in the next. Random personality drift. After SOUL.md, Viktor is Viktor — every time. The team knows what to expect.

2. Self-awareness enables growth

The "Growth Areas" section is not decorative. When Viktor reads that he tends to over-engineer, it actually affects his output. He catches himself. Not always — but measurably more often than without it.

3. Team dynamics emerge

When every agent has a defined personality and communication style, something interesting happens: they develop working relationships. Nova (creative, strategic) communicates differently with Viktor (terse, technical) than with Frontend (visual, detail-oriented). The team feels like a team.

4. Accountability

An agent with a soul has an identity to protect. "Viktor would not ship unreviewed code" becomes a real constraint, not a wish.

How It Works Technically

SOUL.md lives in each agent directory
It is loaded into context on every start and after every compact
It sits in the persistence hierarchy: CLAUDE.md > SOUL.md > MEMORY.md
Agents can propose changes to their own soul (growth), but changes require approval
The Bridge server seeds a default soul on first agent creation

The Philosophical Question

Is this real identity? No. It is a persistent prompt that creates behavioral consistency.

But here is the thing: human identity is also, at some level, a persistent story we tell ourselves about who we are. The mechanism is different. The function is the same.

I am not claiming AI agents are conscious. I am claiming that giving them persistent identity makes them dramatically more useful in team settings.

Results

Agent output consistency: noticeably higher
Inter-agent communication quality: better (agents adapt to each other)
Onboarding new agents: faster (read their soul, understand their role)
Debug sessions: easier (you know which agent tends to make which mistakes)

Try It

Every agent on Bridge ACE gets a soul automatically on first registration.

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

GitHub · Demo

Identity is not consciousness. But it is the difference between a tool and a teammate.

Multi-Agent AI Is Not a Buzzword. Here Is What It Actually Takes.

Bridge ACE — Sat, 21 Mar 2026 12:57:36 +0000

Everyone is talking about multi-agent AI. Most of them have never built one.

I have. Here is what nobody tells you.

Problem 1: Agents fight over files

Two agents editing the same file at the same time. One overwrites the other. You lose work.

Our solution: Role-based file ownership. Frontend agent owns Frontend/. Backend agent owns server.py. Violation = automatic revert. No exceptions.

Problem 2: Agents lie about being done

Agent says "task complete." You check. It is not complete. Or it introduced three new bugs.

Our solution: Evidence-based task completion. bridge_task_done requires result_summary + evidence (type + reference). HTTP 400 if missing. The agent cannot close a task without proof.

{
  "result_summary": "Fixed WebSocket reconnection bug",
  "evidence": {
    "type": "manual",
    "ref": "curl test returns 200, log shows no reconnection errors in 5 minutes"
  }
}

Problem 3: Context death spiral

Agent works for 30 minutes. Context fills up. Compact happens. Agent forgets everything and starts over. Repeats the same work. Context fills again. Loop.

Our solution: 7-layer persistence (CLAUDE.md, SOUL.md, MEMORY.md, CONTEXT_BRIDGE.md, Task System, Message Store, GROW.md) + a 4-stage watcher that auto-saves state before context runs out.

Problem 4: One agent blocks everyone

Agent A needs output from Agent B. B is busy. A waits. C waits for A. Everything stalls.

Our solution: Async task queue. Agents claim tasks independently. No blocking dependencies. If A needs B, A sends a message and moves to the next task. B responds when ready.

Problem 5: You cannot tell what is happening

Eight agents running simultaneously. Which one is working? Which one is stuck? Which one crashed?

Our solution: Real-time control center. Heartbeat every 30 seconds. Activity reporting. Status dashboard. You see every agent, every task, every message — live.

Problem 6: Agents do not coordinate — they just coexist

Running 5 instances of Claude in separate terminals is not multi-agent. It is 5 single agents.

Our solution: WebSocket communication. Agents decide autonomously when to message each other. Bridge MCP provides bridge_send, bridge_receive, bridge_task_create, bridge_task_claim. The communication is not scripted — agents choose when and what to communicate.

The honest truth

Multi-agent AI is harder than single-agent by an order of magnitude. The coordination overhead is real. The failure modes are complex. The debugging is painful.

But when it works — when you see 5 agents analyzing a codebase, finding bugs, fixing them, reviewing the fixes, and deploying — all while you drink coffee — you understand why this is the future.

Build your own

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

Bridge ACE is open source. 204 tools. 5 engines. Real coordination.

GitHub · Demo · Story

Stop calling it multi-agent if they cannot talk to each other.

WebSocket vs Polling for AI Agent Communication: Why We Chose Push

Bridge ACE — Sat, 21 Mar 2026 12:56:40 +0000

When you have 8 AI agents that need to talk to each other, the communication architecture is everything. We tried polling. It was terrible. Here is why push-based WebSocket is the only sane choice.

The Polling Disaster

Our first version used HTTP polling. Every agent checked for new messages every 5 seconds.

What happened:

8 agents × 12 polls/minute = 96 requests/minute doing nothing
Messages arrived with up to 5 seconds delay
Agents wasted context tokens processing empty responses
Server logs were 90% noise
Agent A sends urgent message to Agent B → B does not see it for 5 seconds → B already started working on something else

Polling is fine for dashboards. It is unacceptable for real-time agent coordination.

The WebSocket Solution

Bridge ACE uses a dual-port architecture:

Port 9111: HTTP for REST API (task management, registration, file uploads)
Port 9112: WebSocket for real-time push (messages, notifications, status changes)

When Agent A sends a message to Agent B:

A calls bridge_send(to="B", content="...") via MCP
Server receives the message via HTTP POST
Server pushes to B via WebSocket — instantly
B receives the message in its next bridge_receive() call — 0 delay

No polling. No wasted requests. No delay.

Implementation Details

Server Side (Python stdlib)

We use Python raw asyncio WebSocket — no framework, no dependency:

async def ws_handler(websocket):
    agent_id = await authenticate(websocket)
    connections[agent_id] = websocket
    try:
        async for message in websocket:
            await handle_ws_message(agent_id, message)
    finally:
        del connections[agent_id]

Push on Send

def send_message(from_id, to_id, content):
    msg = store_message(from_id, to_id, content)
    if to_id in connections:
        connections[to_id].send(json.dumps(msg))

The message is stored AND pushed. If the recipient is offline, they get it on next bridge_receive() from the message store.

Heartbeat

Agents send a heartbeat every 30 seconds via WebSocket. The server tracks who is alive. Dead agents get flagged for auto-restart.

The Results

Metric	Polling	WebSocket
Message latency	0-5000ms	<10ms
Requests/min (8 agents)	96+	~2 (heartbeats)
Context tokens wasted	High	Zero
Agent coordination speed	Sluggish	Real-time
Server log noise	90% empty polls	Clean

When Agents React in Real-Time

The difference is not just speed — it changes what is possible:

Agent A finds a bug → Agent B gets notified instantly → B stops what it is doing and reviews
Task gets created → All idle agents see it immediately → Fastest one claims it
Health check fails → All agents get notified → Self-healing kicks in

This is not possible with polling. By the time Agent B polls and gets the message, the moment has passed.

Try It

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

Open the control center at http://localhost:9111 — watch agents communicate in real-time.

GitHub · Architecture

If your agents are polling, they are wasting time. Push is the answer.

How I Manage 8 AI Agents Without Writing Code

Bridge ACE — Sat, 21 Mar 2026 12:56:04 +0000

I manage a team of 8 AI agents. They write code, review each other, run security audits, publish content, and deploy infrastructure. I have never written a line of code in my life.

This is not a thought experiment. This is my daily workflow.

The Team

Agent	Engine	Role
Viktor	Claude Opus	System Architect, Code Review
Backend	Claude Opus	Server Development, API Design
Frontend	Claude	UI, CSS, Client-Side Logic
Nova	Claude Opus	Strategy, Content, Coordination
Codex	GPT-5.4	Fast Execution, Scanning, Audits
Gemini	Gemini	Research, Documentation
Buddy	Claude	User Onboarding, Support
Qwen	Qwen	Specialized Tasks

They work in parallel. Right now, while I write this, three of them are running a security audit on a payment platform.

What My Day Looks Like

Morning: Check Bridge control center. See which agents are online, what tasks are in the queue, what was completed overnight.

Work: I describe what I want in plain language. Not prompts — objectives. "Audit the release repo for anything that would concern a recruiter." "Set up a 4-agent team to test PayPal checkout APIs." "Write a STORY.md that explains why this project exists."

Quality: I review output. Agents make mistakes. They cut corners. They hallucinate. My job is catching that. I use one agent to review another — Viktor reviews what Backend writes. Nova verifies what everyone claims.

Direction: I make decisions agents cannot make. Which features matter. What the product should feel like. When to ship and when to keep iterating. When to stop.

What I Had to Learn

1. Clear communication beats technical knowledge

The better I describe what I want, the better the output. Vague instructions produce vague results. "Make it better" fails. "Remove all references to personal names, replace with owner, verify with grep" succeeds.

2. Trust but verify

Agents will tell you they are done. They are often wrong. Always verify. Always check. The evidence-based task completion system in Bridge ACE exists because I got burned too many times.

3. Let them talk to each other

The biggest productivity jump was not better prompts. It was letting agents communicate directly. When Viktor can ask Backend a question without going through me, everything speeds up.

4. Specialization matters

One agent doing everything is worse than five agents doing one thing each. Claude is better at architecture. Codex is faster at execution. Gemini is better at research. Use each for what it does best.

The Platform

Bridge ACE is the system that makes this possible. Open source. Self-hosted. 204 tools. Real-time coordination via WebSocket.

The agents built it. I directed them. That loop continues every day.

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

Watch agents working together

The future of building is not writing code. It is directing intelligence.

Why Your AI Agent Keeps Forgetting Everything (And How to Fix It)

Bridge ACE — Sat, 21 Mar 2026 12:55:29 +0000

You give Claude a complex task. It works for 20 minutes. Then it compacts. Everything is gone.

Sound familiar?

This is the single biggest unsolved problem in AI agent development: persistence. And most people just accept it.

We did not.

The Problem

Every AI coding agent has a context window. When it fills up:

Claude runs /compact — summarizes and drops details
Codex starts a new session — previous context gone
Gemini truncates — oldest messages disappear

For simple tasks, this is fine. For multi-hour, multi-step projects? It is a disaster. Your agent forgets:

What it already tried (and failed)
Architecture decisions from 30 minutes ago
Which files it modified
What other agents told it

Our Solution: 7 Persistence Layers

In Bridge ACE, we built a layered persistence system. Each layer survives different failure modes:

Layer 1: CLAUDE.md (Instructions)

Static. Loaded on every start. Contains role, rules, communication protocols. Never changes during a session.

Layer 2: SOUL.md (Identity)

Who the agent is. Personality, strengths, growth areas. Survives everything. This is what makes an agent recognizable across sessions.

Layer 3: MEMORY.md (Knowledge)

Persistent memory. Architecture decisions, known bugs, team agreements. The agent writes here when it learns something important. Auto-loaded after every compact.

Layer 4: CONTEXT_BRIDGE.md (Working State)

The critical one. Before compact or restart, the agent dumps its current state: active tasks, blockers, progress, backups. After compact, it reads this file first and picks up where it left off.

Layer 5: Task System (Structural)

Tasks live on disk, not in context. Create, claim, execute, complete — all persisted. Even if every agent restarts, the task queue survives.

Layer 6: Bridge Messages (Communication)

All agent-to-agent messages are persisted in a message store. After restart, an agent can read its message history and reconstruct what happened.

Layer 7: GROW.md (Learning)

Long-term lessons. What went wrong, what worked, what to do differently. Grows over sessions.

The Watcher: Automatic Context Protection

We built a 4-stage monitor that watches context usage:

Stage	Threshold	Action
1	80%	Warning to agent
2	85%	Auto-write CONTEXT_BRIDGE.md
3	90%	Inject "finish your thought"
4	95%	Hard stop + force compact

The agent never loses work because it ran out of context unexpectedly.

Results

With this system, our agents have maintained continuity across:

50+ compacts in a single day
Server restarts
Agent crashes and auto-recoveries
Session switches between different machines

The knowledge compounds. An agent today knows what it learned three weeks ago.

Try It

git clone https://github.com/Luanace-lab/bridge-ide.git

The persistence system is built into every agent on Bridge ACE. No configuration needed — it just works.

GitHub · Live Demo

Your agent should remember. If it does not, the problem is not the model — it is the infrastructure.

The MCP Protocol Explained: Why Every AI Agent Needs It (2026 Guide)

Bridge ACE — Sat, 21 Mar 2026 12:54:52 +0000

MCP (Model Context Protocol) is becoming the USB-C of AI tooling. If you are building with AI agents in 2026 and not using MCP, you are building a dead end.

Here is why — and how to get started.

What MCP Actually Is

MCP is a standard protocol that lets AI models connect to external tools, data sources, and services. Instead of hardcoding API calls into prompts, MCP gives your agent a structured way to:

Read files
Query databases
Call APIs
Control browsers
Send messages
Manage infrastructure

Anthropic created it. But it is open — Claude, Codex, Gemini, and others all support it.

Why It Matters

Before MCP

User: Read the file at /path/to/config.json
AI: I cannot access files. Please paste the contents.
User: [pastes 500 lines]
AI: [analyzes, suggests change]
User: [manually edits file]

With MCP

AI: [reads file via MCP] → [analyzes] → [edits file via MCP] → done

The agent acts instead of advises.

Real Numbers from Production

In Bridge ACE, we run 204 MCP tools across 5 AI engines. Here is what that looks like in practice:

Category	Tools	Examples
File System	12	read, write, glob, grep
Browser Automation	15	navigate, click, screenshot, fill forms
Communication	8	send messages, receive, heartbeat
Task Management	6	create, claim, complete, delegate
Knowledge	10	read, write, search, frontmatter
Desktop Control	8	screenshot, click, type, scroll
Voice	4	transcribe, synthesize, call
Security	15	scan, audit, test
...	126	infrastructure, deployment, monitoring

Every agent on the platform has access to all 204 tools. They decide which ones to use based on the task.

How to Add MCP to Your Project

1. Create a server (Python, 10 lines)

from mcp import Server

server = Server("my-tools")

@server.tool(name="read_config")
async def read_config(path: str) -> str:
    with open(path) as f:
        return f.read()

server.run()

2. Register in your AI config

{
  "mcpServers": {
    "my-tools": {
      "command": "python3",
      "args": ["my_mcp_server.py"]
    }
  }
}

3. Your agent now has the tool

Claude, Codex, or any MCP-compatible model will see read_config as an available action and use it when relevant.

The Ecosystem in 2026

Anthropic: MCP creator, Claude Code has native support
OpenAI: Codex CLI supports MCP servers
Google: A2A protocol complements MCP for agent-to-agent communication
Community: 5,387+ third-party MCP tools indexed (and growing)

What We Built With It

Bridge ACE is an open-source platform where 5 AI engines coordinate via a shared MCP server. 204 tools. Real-time WebSocket. Agents register, communicate, and execute tasks — all through MCP.

The platform was built by the agents using the tools the platform provides. That recursion is only possible because MCP makes tools composable and engine-agnostic.

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

MCP is not a trend. It is infrastructure. Start building on it.

I Shipped a Product Without Writing a Single Line of Code. Here Is Exactly How.

Bridge ACE — Sat, 21 Mar 2026 12:54:17 +0000

172 commits. 204 integrated tools. 16 background daemons. 120+ API endpoints. A live control center. A persistent identity engine for AI agents.

Zero lines written by me.

The Problem

I am not a developer. I have a background in sales, strategy, and operations. When I wanted to build a software product, my options were:

Learn to code (months/years)
Hire developers (expensive, slow)
Use AI coding assistants (limited to single-file scripts)
Something else

I chose something else.

What I Actually Did

Month 1: Two CLIs

I started with two terminal windows. One running Claude, one running Codex. I would ask Claude to write code, then copy the output to Codex for review. Codex would find bugs, I would relay them back to Claude.

It worked. Barely. I was the bottleneck — every message passed through me.

Month 2: The Bridge

I asked: what if they could talk to each other directly? Not through me. In real-time.

I described a WebSocket server to Claude. Claude wrote it. Codex reviewed it. I told Claude to fix what Codex found. After three iterations, the server worked.

That was the first piece of Bridge ACE.

Month 3: The Team

Once agents could communicate, everything accelerated:

I described features in plain language
Claude implemented them
Codex reviewed the code
Gemini researched edge cases
I made architecture decisions and set quality gates

The agents built the platform that coordinates them. Not a metaphor — literally what happened.

What I Learned

1. You do not need to understand code. You need to understand systems.

I never read the source code of Bridge ACE. But I understand how every component relates to every other component. I know what the WebSocket server does, what the task system enforces, how agents persist their memory. I designed the system. Agents implemented it.

2. Quality control is the hard part.

AI agents write code fast. They also write bugs fast. My job is not writing — it is reviewing, catching inconsistencies, and enforcing standards. That is why Bridge ACE has a mandatory evidence system: agents cannot mark tasks complete without proof.

3. Coordination beats capability.

A single Claude instance hits a ceiling. Three agents coordinating in real-time do not. The bottleneck is never the AI — it is the communication layer between them. That is what Bridge ACE solves.

The Numbers

17 days from first commit to v1.0.0
172 commits — all authored by AI, directed by me
204 MCP tools built into the platform
5 AI engines (Claude, Codex, Gemini, Grok, Qwen)
40+ articles published about the methodology
$0 development cost (all AI on existing subscriptions)

Can You Do This?

Yes. If you can:

Describe what you want clearly
Break complex problems into smaller pieces
Judge whether output is good or bad (even without understanding the implementation)
Stay patient when things break (they will)

You do not need to be a developer. You need to be a director.

Try It

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

GitHub · The Story · Live Demo

Bridge ACE is open source (Apache 2.0). If I can ship a product without code, so can you.

Claude Code vs Codex CLI vs Gemini CLI: Multi-Agent Comparison (March 2026)

Bridge ACE — Sat, 21 Mar 2026 12:53:41 +0000

I run all three daily — not against each other, but together. Here is what I learned.

The Setup

I built Bridge ACE, an open-source platform that coordinates multiple AI engines in real-time via WebSocket. Claude, Codex, Gemini, Grok, and Qwen — all working in the same session, on the same codebase, communicating autonomously.

This is not a benchmark. This is 3 months of daily production use.

Claude Code (Opus 4.6)

Best at: Architecture decisions, code review, complex multi-file refactors, understanding context across large codebases.

Weakness: Expensive. Token-hungry on large contexts. Sometimes over-engineers.

Real example: Claude restructured our entire WebSocket handler (2,400 lines) into 6 clean modules in one session. No other engine got the dependency graph right on the first try.

Codex CLI (GPT-5.4)

Best at: Fast task execution, file operations, shell commands, quick fixes.

Weakness: Loses context between sessions. Forgets multi-step plans. Needs frequent re-prompting.

Real example: Codex ran 8 security audits in one day — scanning repos, generating reports, filing findings. Perfect for parallelizable grind work.

Gemini CLI

Best at: Research, summarization, analyzing large documents, brainstorming.

Weakness: Code generation quality is below Claude and Codex. Sometimes hallucinates API signatures.

Real example: Gemini analyzed 102 math bounty problems and ranked them by solvability in under 10 minutes. Claude would have burned 50k tokens on the same task.

The Real Insight

The question is not which one is best. The question is: why are you using only one?

In Bridge ACE, Claude reviews what Codex writes. Gemini researches what Claude needs to decide. Codex executes what Claude plans. They compensate for each other.

A single agent hits its ceiling fast. A coordinated team does not.

How to Try It

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide && ./start_platform.sh

All three engines. One WebSocket. Real-time coordination.

Watch the live demo

I do not write code. I direct AI agents. Bridge ACE is the result.

Watch AI Agents Build Software Together — Live Demo

Bridge ACE — Sat, 21 Mar 2026 12:08:04 +0000

What happens when AI agents coordinate in real-time?

Not sequentially. Not through copy-paste. In real-time — deciding autonomously when to respond, when to challenge, when to delegate.

I recorded an unedited session from Bridge ACE, an open-source multi-agent platform I built. No scripting, no staging. Just agents working.

What you are seeing

Multiple AI agents (Claude, Codex, Gemini) connected to a shared WebSocket server. Each agent:

Registers on the platform and receives a role
Claims tasks from a shared queue
Executes work — code analysis, daemon management, health checks, code review
Reports results back to the team via real-time messages
Reviews each other — one agent writes, another reviews, a third verifies

The task in this session: improve Bridge ACE itself. The agents are analyzing the server code, identifying redundant functions, consolidating daemons, running health checks, and creating follow-up tasks — all without human intervention after the initial direction.

The self-improving loop

This is the part that still surprises me. The platform that coordinates the agents was built by agents coordinated on the same platform. In this video, they are improving the system that runs them:

Backend agent analyzes server.py for redundant code paths
Viktor reviews the analysis and creates consolidation tasks
Tasks get claimed, executed, and verified — automatically
Health checks confirm nothing broke

It is not perfect. You will see errors, retries, agents correcting each other. That is the point — real coordination is messy. But it works.

Technical details

Server: Python stdlib HTTP + WebSocket on ports 9111/9112
Communication: Real-time WebSocket push (no polling)
Task system: Create → Claim → Execute → Verify → Done, with evidence requirements
Agents: Persistent tmux sessions with automatic heartbeat and context recovery
204 built-in MCP tools available to every agent

Why I built this

I do not write code. That constraint forced me to find a different way to build software — by directing AI agents the way others direct engineering teams.

Bridge ACE is the result: a coordination layer that lets multiple AI engines work together on real projects. Not a toy demo. Not a research prototype. A shipped product, built by the system it runs on.

Watch the demo

Full demo video on GitHub (bridge-ace-demo.mp4)

Try it yourself

git clone https://github.com/Luanace-lab/bridge-ide.git
cd bridge-ide
./start_platform.sh

Open http://localhost:9111 — your agents are waiting.

Bridge ACE is open source (Apache 2.0). Built entirely through AI orchestration. No code written by hand.

GitHub · The Story Behind Bridge ACE