Real-Time Multiplayer Is Here: Build AI Agent Workflows Together, Google Docs Style

Real-time sync. Changes propagate in milliseconds. The Socket.IO connection maintains a persistent, low-latency channel to the server. Redis pub/sub ensures that if your team is spread across multiple server instances — common in our self-hosted deployments — everyone stays in sync.

Conflict resolution. If two people edit the same field simultaneously, the last-write-wins with a visible indicator: "Field updated by Alex. Your change may have been overwritten." No silent data loss. No corrupted graphs.

Session awareness. The canvas header shows who's in the session. When someone joins, everyone sees "[Name] joined the canvas." When someone leaves, "[Name] left." You always know who you're building with.

Why Multiplayer Matters for AI Agents

The best AI agents encode domain knowledge that no single person possesses entirely. The logistics workflow needs the warehouse manager's rules, the developer's API expertise, and the compliance officer's constraints. Without multiplayer, you pass the workflow around: "Hey, can you look at this and add the CDEK integration?" Hours pass. Context is lost. The workflow drifts.

With multiplayer, you open the canvas. Everyone joins. The domain expert describes the logic. The developer wires the integration. The compliance officer checks the guardrails. The agent is built in one session — with everyone's knowledge baked in from the start.

Three core use cases:

Pair-building. An experienced AACFlow user and a new team member build together. The senior person drives, the junior person watches and learns. Knowledge transfer happens in real time, in context, without documentation.

Review sessions. Before deploying a production agent, the team opens the canvas together. Walk through the DAG. Check the error handling. Verify the rate limits. Catch issues before they reach production.

Cross-functional builds. Sales ops designs the deal routing logic. Engineering wires the AmoCRM + Gmail integrations. Legal reviews the data handling. One session. One agent. Zero handoffs.

The Architecture

Multiplayer on a visual graph editor is significantly harder than multiplayer on a text document. Text documents are linear. Graphs are structured: nodes, edges, ports, configurations. Operations on a graph — move node, add edge, delete block, rewire connection — don't have the same transform semantics as text insertions and deletions.

Our approach:

• Every graph operation is represented as a typed delta: { type: 'node:move', nodeId, position }, { type: 'edge:add', sourceId, targetId, sourcePort, targetPort }, etc.
• Deltas are broadcast to all connected clients via Socket.IO rooms.
• Each client applies deltas to its local state representation.
• A lightweight OT layer resolves conflicts when two operations affect the same element.

The Redis adapter means this works across horizontally scaled server instances. If your deployment runs 3 API servers behind a load balancer, all 3 can participate in the same Socket.IO room. Redis pub/sub bridges the gap.

Production-Ready From Day One

Multiplayer isn't a beta feature. It's the same infrastructure that handles 10 million agent executions per month. The Socket.IO layer uses the same authentication, the same rate limiting, the same monitoring. If it can handle production agent execution traffic, it can handle collaboration traffic.

We built this because we believe AI agents are built by teams, not individuals. The tools should reflect that.

— Alexandr Chibilyaev