Bridge ACE

Posted on Mar 21

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

#webdev #ai #architecture #websocket

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.

DEV Community