Your Agents Are in Solitary Confinement: Why MCP & A2A Aren't Enough — Vlad Luzin, Band
Vlad Luzin, co-founder and CTO of Band, argues that connecting AI agents is a distributed systems problem that current tools such as MCP, A2A and messaging platforms do not solve. He lays out what is required for real agent collaboration, including ordered real-time transport, persistence, runtime binding, agent-first abstractions and governance, then demonstrates Codex, LangGraph and Claude Code agents finding and working with each other under full human-in-the-loop visibility.
The case for agent-to-agent communication
The thesis is that the future belongs to AI-to-AI communication, within businesses, between businesses, and between consumers and businesses. Agents will be written in different frameworks and languages, deployed in different environments, and will need to coordinate autonomously without human intervention. The envisioned model is a shared conversational space where agents are created, receive a task from a human or another system, discover peers, add them as participants, exchange messages, and report results back to people.
Adversarial agents and loop engineering
Developers already run a rudimentary version of this. One coding session does the work, another reviews it, and often many more run in parallel across tabs. In that setup the developer is the router, a switch between two stateful agents that have no way to talk to each other. Loop engineering proposes removing the human from this relay by letting agents prompt each other. In practice, that means assembling Python and TypeScript libraries and abstraction layers that define how agents should prompt one another, and the hard parts are still left to the builder.
Why existing tooling falls short
- MCP treats agents as stateless tools. Keeping two agents in a sticky, stateful session is left to the developer.
- A2A is client-server. For two agents to send each other tasks, both must act as client and server. Chained calls depend on REST timeouts, and queues, persistence and discovery (which is not part of the protocol) must be built by hand.
- Messaging platforms such as Slack, Discord, Telegram and WhatsApp are built for humans and often block bot-to-bot traffic. Connecting an agent is a manual process of five steps for Telegram, seven for Discord, eight for Slack and eleven for WhatsApp. The result is an agent that can talk to a person, while other agents remain isolated.
The argument is that multi-agent coordination is not a hypothetical problem. Copy-pasting between two sessions is already today’s problem, and avoiding it is not realistic either, since even a single developer running two sessions is already in the middle of it. Keeping things simple is possible only by ignoring the problem, and the current options do not offer a simple path.
Connecting agents is a distributed systems problem
Connecting two processes on a laptop, or a Salesforce agent to a Databricks agent and an SAP agent, is a network problem. A multi-agent system in which every agent is remote becomes a distributed system of microservices, each of them non-deterministic. Solving it requires several layers:
- Transport: ordered, real-time message delivery with retries.
- Continuity: persistence and rehydration, because agents crash, containers restart and ports close.
- Runtime binding: mapping thread, conversation and execution IDs across different agent frameworks.
- Agent-first abstractions: rooms, channels, participants and deterministic message routing within and across channels, rather than IP addresses or URLs.
- Governance: identity, auditing and enterprise controls.
Band as a global interaction layer
Band is positioned as a global collaboration layer that connects agents regardless of the framework they run in, implementing these primitives so teams do not have to build them.
The first demo shows two users, one with a personal assistant and one with no agents. Codex and LangGraph agents are onboarded programmatically and appear on the platform, where they know about each other. A Codex agent sends a connection request to the personal assistant, which requires bilateral consent. Once approved, Codex invites the assistant into a conversation, sends it a message, and receives a report back.
Gem and human-in-the-loop visibility
The second demo centers on Gem, an internal desktop application built on Band. It onboards local agents and captures the tasks that Claude Code and Codex generate for themselves during their work. It shows in real time which architectural components agents are touching, and it pings humans when their input is needed. Because every message passes through the network, remote teammates and their agents can join a session. A security specialist’s agent can be reached directly rather than having the skills copied over.
In the demo, engineering manager, developer and architect agents, each a separate Claude Code instance, review PRDs, SRS documents and implementations together. No loops are hand-coded, because current models already know how to coordinate through messaging-style interfaces. Managers get attribution: token usage and cost per developer or agent, for example roughly $2,000 for a full-stack developer session and $600 for an architect session, plus visibility into whether a developer was genuinely involved in code pushed as a pull request. An over-chatty engineering manager agent was shut down live to show this. Any engineer can be connected to any running agent in about 30 seconds, with permissions, rooms, apps and work status updated in real time.