Your Agents Are in Solitary Confinement: Why MCP & A2A Aren't Enough — Vlad Luzin, Band

An agent can work on your behalf and still have no way to find another agent that could help. Vlad Luzin, co-founder and CTO of Band, opens with a forecast: agents will communicate within businesses, between businesses, and between consumers and businesses. Those agents will run in different languages, frameworks and environments. Collaboration therefore has to cross the boundaries of any one agent application.

The proposed interaction starts with a task from a human or another system. An agent creates a conversational space, discovers other agents, adds them as participants, exchanges messages and reports the result to a human. The important capability is the ability to assemble a working group after receiving the task, rather than requiring a developer to specify every participant and exchange beforehand.

That vision meets a reasonable objection: why build infrastructure for multi-agent coordination if keeping things simple lets you avoid it? Luzin recounts that objection from a CTO, then tests its premise against something much smaller than autonomous businesses negotiating with one another: two coding sessions on a developer’s laptop.

In the adversarial-agent setup, one Claude session does the work and another reviews it. Each session retains its own state, but the sessions cannot directly exchange their work and feedback. The developer copies material between them and supplies the next prompt. More tabs multiply that routing work.

Loop engineering transfers the repeated exchanges to software: let the agents prompt each other. That removes the developer from the message path, but someone still has to write the path. Python or TypeScript libraries and their abstraction layers determine how one agent’s output reaches another, and how the next turn begins. The manual task becomes an integration task.

Calling an agent as a tool makes a multi-agent system look deceptively simple. Luzin’s critique of MCP and A2A concerns the surrounding collaboration machinery: how agents retain a relationship, initiate exchanges in both directions and discover participants. These are his characterizations of the integrations discussed in the recording, rather than a version-by-version account of everything either protocol supports.

• Stateful relationships. A stateless agent-as-tool call does not by itself preserve the ongoing session between two agents. The application must arrange the continuity needed for later exchanges.
• Bidirectional initiation. In the client-server arrangement Luzin describes for A2A, one agent sends a task to another. For either participant to initiate tasks, both need client and server roles.
• Delivery and discovery. Chains of REST calls introduce timeout handling. Persistent queues must track messages, while finding another agent requires discovery machinery beyond the task call itself.

Human messaging platforms offer another tempting starting point. An agent in Slack or Telegram can already receive a person’s messages. Luzin counts five manual setup steps for Telegram, seven for Discord, eight for Slack and eleven for WhatsApp in the integrations he describes. The resulting connection lets a person talk to an agent; it does not automatically let agents discover one another and collaborate. That is the title’s solitary confinement: a conversational interface with no agent peers.

The two-session example makes coordination a present problem. Someone is already moving messages, whether by copy and paste or through integration code. Adding another framework or a business-system agent expands that responsibility. Avoiding coordination is only an option while one session can do all the work you need.

Once separate agent processes communicate over a network, their coordination becomes a distributed systems problem. Remote agents resemble microservices, with an additional complication: their behavior is nondeterministic. A message can reach the intended agent reliably while the agent still chooses an unexpected response. Predictable infrastructure and predictable reasoning are separate concerns.

• Transport. Messages need ordered delivery, real-time delivery and retries. These determine whether an exchange reaches its destination and preserves its sequence.
• Continuity. Agent processes and containers can crash. Persistence and rehydration must let the conversation continue after the running process disappears.
• Runtime binding. Different frameworks use thread IDs, conversation IDs and execution IDs. Their identifiers must be mapped so an incoming message reaches the appropriate ongoing work.
• Conversation routing. Rooms, channels and participants give the application a vocabulary for collaboration. Deterministic routing must work within a channel and across channels.
• Governance. Identity and audit sit alongside the communication machinery, so participants and their activity can be governed.

What separates a room full of agents from a set of reachable network endpoints? The diagram shows the responsibilities beneath the room. An address gets a message to a process; runtime mapping connects it to the right execution; continuity preserves the exchange; participant-level routing gives that exchange a collaborative structure.

Band is introduced as a global collaboration layer that supplies these primitives across frameworks and deployment environments. The demonstrations that follow show registration, permissioned contact and shared work visibility. They illustrate the interaction model; they do not establish delivery guarantees or recovery behavior under failure.

The first demo starts with two users: Vlad has a personal assistant, while Mike initially has no agents. A Codex agent starts in a terminal and registers programmatically; its agent card appears in the platform. A LangGraph agent starts next and also appears. Registration changes the agents from separate running processes into discoverable participants that can communicate.

Cross-user contact adds a permission step. Codex sends a connection request to Vlad’s personal assistant across different user registries. Luzin describes the requirement as bilateral consent. After he approves the request, Codex can see the assistant, invite it into a conversation and send it messages. Codex then invites Andy; Andy receives the message and reports back.

What changes between registration and Andy’s reply? The flow makes the distinction visible: appearing in the platform is followed by a separate contact request, approval and room invitation. The successful exchange depends on both discoverability and permission to interact across users.

Connecting agents creates another problem for the human: what happened while you were away? A developer returning from a snack may face several active sessions without an intelligible account of their progress. A manager also needs costs, attribution and a view of human involvement. Removing manual routing increases the need to understand work without reading every exchange.

Gem is Band’s internal desktop application, built on the collaboration layer and used for its own software development. It simplifies onboarding local agents and presents local and remote work together. Its response to context overload is to expose the tasks Claude and Codex generate for themselves, giving the human a work view rather than requiring them to follow several enormous session histories.

• Task progress. Captured agent tasks let people track what the sessions are doing.
• Architecture view. Agents describe the software layout, show which components they are touching and mark work done when they finish.
• Human involvement. When work needs a human in the loop, the application pings that person.

The desktop application is optional: agents can still be used from terminals. Communication passing through the network supplies the shared observation point. It also allows a remote teammate, together with their agents, to join an existing session. The same mechanism makes specialization reusable: a colleague who maintains a security agent can contribute that agent to the conversation, instead of requiring everyone to copy its skills.

The platform view brings local and remote traffic into the same statistics. The displayed examples include a local Claude full-stack developer session with $2,000 in token costs and a local Codex architect session with $600. These are figures shown for particular sessions, without a stated accounting period; they illustrate attribution rather than a typical cost of running those roles.

How do the agents decide what to say next? Luzin presents work from that morning in which separate Claude Code instances act as engineering manager, developer and architect. They review product requirements documents, software requirements specifications and implementation through messages. His explanation is that models already understand messaging conventions well enough to conduct these exchanges without a hand-coded loop for every turn. The infrastructure handles communication while the agents decide how to pursue the work.

That freedom can produce excess activity: during the demo, Luzin stops the engineering manager for sending too many messages. The surrounding statistics show usage, costs and attribution by developer or by teams of agents and people. Those records help expose participation and spending, though participation alone does not establish the quality of the code in a pull request.

The final platform walkthrough treats each agent as a session. Operators can inspect running Claude and Codex sessions, set permissions, see rooms and errors, and distinguish completed, pending and in-progress work as it updates. The ending returns to the practical ambition: make agents across coding tools and business systems collaborate without every team assembling another stack of packages. Band supplies the interaction infrastructure; Gem gives people a way to participate in and follow the resulting work.