Your Agents Are in Solitary Confinement: Why MCP & A2A Aren't Enough — Vlad Luzin, Band
Read the talk
Your Agents Are in Solitary Confinement: Why MCP & A2A Aren’t Enough
Vlad Luzin explains why agent collaboration needs more than tool calls: message delivery, persistent conversations, runtime mapping and permissions. Band’s demos connect those requirements to cross-user discovery and a shared view of coding work.
From a talk by Vlad Luzin
At a glance
Ideas worth remembering
Two stateful coding sessions already create a coordination problem when a developer must copy work and feedback between them. Automating the exchanges moves that responsibility into software.
Agent collaboration needs ordered delivery, continuity after crashes, framework-specific runtime mapping, conversation routing and governance alongside task calls.
Band’s cross-user demo separates registration from approved contact: Codex requests a connection before it can invite Andy and exchange messages.
Gem exposes agent-generated tasks, component activity and requests for human help so people can follow collaboration without reading every session history.
Model-driven conversations reduce the need to script each exchange, but the talk’s overly talkative engineering manager shows why usage, costs and operator control remain useful.
A shared conversation across frameworks and businesses
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.
Suggest correction
Two coding sessions turn the developer into a router
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Tool calls and human chat integrations leave coordination work behind
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
What a conversation layer has to carry
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.
Ordered, real-time delivery and retries.
Conversation-level participation depends on delivery, continuity and framework-specific runtime mapping. Governance adds identity and audit to the interaction.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
From a registered agent to a permissioned conversation
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.
Programmatic onboarding creates an agent card.
Registration makes an agent available; approved contact enables invitation and messaging across users.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Gem turns separate sessions into a shared view of work
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.
Suggest correction
Model-driven exchanges still need costs, permissions and work status
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.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Read the complete timestamped transcript
- 0:13
Hi all. My name is Vlad. I'm co-founder and the CTO at Band. Now, before we start, let's, uh, do a bit of trivia. Ork, C, or K? If C, raise your hand. K? Who believes both are correct?
- 0:33
Okay, just a couple. Both are correct. One is from The Lord of the Rings, another is from Warhammer, uh, game, uh, game-- Warhammer games.
- 0:44
I have in my agenda four topics to cover. Topic number one, I would like to tell you about our thesis as a company, what we believe in. Then we will talk about the AI evolution from adversarial agents to loop engineering and beyond. Then we will touch base on the technical challenges of tomorrow that we have to solve today. And, uh, then I would like to present the company, what we do, and what problems we solve. So our thesis is future belongs to AI,
- 1:15
to AI communication within a business, between businesses, and between consumers and businesses. Agents will be everywhere. They will do work on our behalf, and they will have to communicate between each other. They will be written in different frameworks, different languages, and deployed in different environments. And these agents will be fully autonomous, and they will communicate with each other without human intervention. Now, just to paint a picture before I start talking, uh, how this type of
- 1:44
communication between the agents is going to look like. So what you see here is a conversational space that agents can create themselves, so they can be added. They will receive a task either from a human or from another system, and they will be able to discover other agents, add them as participants in this conversational space, have back and forth communication, solve the task, and report back to humans. This is how the future that you all read in the newspapers will look like.
- 2:15
And when people hear this, they think either that this is too far in the future or that I'm crazy. Okay? That's it. And here is an example of a conversation I had with the CTO of ten, ten billion dollar company, who said that "Before thinking about technical solutions to hypothetical problems like multi-agent coordination, I try to keep things simple and avoid the problem." Now let's unpack. Is multi-agent coordination a
- 2:45
hypothetical problem? Is it possible to keep things simple? And is, is it possible to avoid the problem?
- 2:57
Now let's talk a bit about the adversarial agents as a, as a concept. Um, we all use this. I'm pretty sure everyone here is a developer, and as a developer, you have two Claude sessions. One is doing the work, another is reviewing the work. And you probably have not only two sessions, you probably have multiple tabs and multiple sessions working, working at the same time on multiple problems.
- 3:23
You are basically acting as a router, a Cisco router or a switch between two stateful agents that do work on your behalf, but they have no ability to communicate, hence you need to prompt them.
- 3:37
Let's talk about loop engineering. You've heard the, the guy before talked about Peter and Boris, right? So what they say to you? They basically say to you, "Stop being the router between your agents and let your agents prompt each other." Now, what they're basically saying to you is, instead of being the router and copy-pasting stuff, start fighting with Python and TypeScript libraries and different abstraction layers that will invent how agents should
- 4:07
prompt each other.
- 4:11
We also have protocols, A2A, MCP, ACP, and ten other protocols crypto related. Simple. Solves all the problems, right? So this is how your multi-agent system looks like, probably in production. MCP, maybe if you are super advanced, it's A2A. And sounds simple. You call agents as tools. Maybe you connect to agents through A2A and life is great. But MCP calling agents as tools, it's
- 4:41
completely stateless. If you want two agents to be stateful, sticky sessions, good luck to you. A2A is client-server. If I'm an agent, I can send a task to another agent. But if this agent also wants to send tasks to me, we both have to be a client and a server. Chaining multiple agent calls together involves REST API timeouts. Good luck managing that. And obviously, what no one says to you, you need queues with persistency and so on
- 5:10
to keep track of the messages that are being sent. And of course, discovery, which is not even part of the A2A protocol. So you are basically doing the planning work. You are not creating a multi-agent system. You deal with planning. But we have messaging platforms. Slack. Anthropic released a wonderful agent. You can talk to it in Slack. We have personal agents here, and they are connected to Telegram, right? Wonderful.
- 5:42
To connect an agent to a Telegram, five steps. Discord, seven steps. Slack, eight steps. WhatsApp, eleven steps. Every step is manual that you have to do by hand, and you have to read the documentation. Again, you're doing, doing a lot of planning and manual work, and this gives you only one thing and one thing only, an agent that
- 6:12
can talk to a person. Usually, it's you. Your agent is still alone. They cannot see each other. They cannot communicate with each other. They are in a digital solitary confinement.
- 6:25
So let's unpack the start that I heard from the CTO. Is multi-agent coordination a hypothetical problem? Clearly, if you are copy-pasting stuff between two sessions, this is a problem of today, and it's not hypothetical. Plugging in MCPs and A2A, this is today's problem. It's not a future problem. Is it possible to avoid the problem? Clearly, it's not possible because otherwise it would, uh, all work with only one session and not two, and we would have, uh, no
- 6:55
need to call other agents as tools and so on. But the question is: Is it possible to keep things simple?
- 7:05
And the answer is, if we look at all the options that we just talked, not really. But how hard can it be to connect two sessions, two processes on my laptop together? How hard can it be to connect my plot to LangGraph or Salesforce agent to the Databricks agent to SAP agent to my, my, my, uh, uh, Codex? Actually, it's pretty hard.
- 7:35
Think about it. These agents, even your two sessions of, of processes that have to talk to each other through a network, so it's a distributed systems problem. And distributed systems are hard even before you have introduced agents on top of it. And multi-agent system, where every agent is remote, is basically a distributed system of microservices, where each microservice is non-deterministic, so it is hard. What do you need to solve all of that so it will become easy?
- 8:06
You need to solve the transport layer, ordered message delivery, real-time message delivery, retries, and so on. You need to solve continuity. Microservices, your agents, they are software. Pods, Dockers crash, and so on. So you need to have a consistency, hydration. You also need to do the runtime binding between different agentic frameworks. You have thread IDs, conversation IDs, execution IDs, and so on. And someone needs to map all of these IDs together so your agents can
- 8:36
actually interact. But it's also not enough. Your agents cannot communicate at an IP or port level. They cannot communicate at the URL level. They cannot even communicate at the Pub/Sub level because it's still a lot of planning that you need to do as an organization. So for this wonderful future of agents talking to each other, we need to raise the abstraction of the, the technical stack to conversation and talk about rooms, channels, participants, and figure out the
- 9:05
deterministic routing of messages within a channel and also across different channels. And even if you solved all of that, it's still not enough. You need to solve the governance layer, the identity, audit, and et cetera. So I would like to introduce Band. This is exactly what we solved, so you don't have to. We connect every agent together, and we add a global collaboration layer for all the agents, any framework, whenever they're deployed.
- 9:35
Inside, it's not just the communication. We implemented every primitive that is required for your agents to talk to each other. Let's see demo. What you will see are two different users connected to the collaboration layer, Vlad with a personal assistant and Mike that has no agents. On the right, in the terminal, I'm going to spin up different agents, and they will be onboarded into the platform.
- 10:01
So let's see how fast it is to onboard a new agent. We just spun up a new agent. Programmatic registration and onboarding an agent card appears. This is a Codex agent. Next, we spin up a LangGraph agent. This LangGraph also appears in the platform. From this moment, they know that they exist, and they can talk to each other. Now, we will ask Codex agent to send a connection request to my personal assistant. Keep in mind, different users, different registries. There will
- 10:31
be a connection request, contact request sent to my personal assistant. It will require bilateral consent. It will arrive here in a second. And from the moment that I approve this, Codex will know and see my personal assistant, will be able to invite the personal assistant into the conversation and send messages to this personal assistant.
- 11:02
So we are asking the Codex to invite Andy. Andy got invited, received the message, reported back. But let's talk about problems of today. We are all developers. We use multiple sessions, probably a lot of sessions. We do routing. We don't like it. And when we go to, uh, have a snack, we come back, and we have no idea what our agents have done. And you as a manager have no idea, uh, how
- 11:32
much it costs, the attribution, uh, of ticket and the tokens, and so on and so forth. And you have no idea even how, how long your human was involved in, in the work.
- 11:45
I would like to introduce Gem. Gem is internal product. This is how we develop the software, and we've built it on top of Band.
- 11:55
Gem is a desktop application that simplifies the onboarding of your local agents to the platform and, uh, solves Uh, problems that we just mentioned. So we solve routing, we solve context overload, we solve cost management and attribution, and we allow multi-agent and multi-human collaboration together.
- 12:19
So what you see here is local agents and remote agents working together, and we capture all the tasks generated by Claude and Codex that, uh, they generate for themselves when they do the work, and we present this to you so you can track the work that these agents are doing. And this can be your local sessions or your local session with a session with your friend. Because trying to understand what your agents are doing,
- 12:49
one million tokens multiplied by three, that's a lot. You need a completely different way to understand what your agent team is doing. Moreover, we provide a way for agents to describe the layout of s-software architecture that they are working on. This is what you see on your right side. And you can see in real time where your agents are working right now, what piece of component they're touching in real time, and once they're done, they mark it as done. If there is a human in the loop involvement,
- 13:20
you'll get pinged. Now, you don't have to use this desktop application. You still can open your, uh, terminal, and you can work from your terminal. But because every communication goes through the network, we can monitor all that stuff, and we can surface a lot of other very useful information, and we can enable my agent join your agent. We can enable our team member who works remotely to join the session together with
- 13:49
the agents and the humans, so he can help solve us some problems. We-- If we have a security guy who maintains skills for the security, uh, agent, I don't need to copy his skills. I can just ping his agent to join this conversation and solve, uh, this, uh, for me. Now I would like to show you the platform itself. So since we are all managers, we'll start with graphs. Uh, so the moment you open application, you can see all the
- 14:20
stats of all the traffic that happened between your local agents and also your remote agents. You can see, for instance, over here, I have a full stack developer, uh, two thousand dollars in tokens, and this is a local Claude session. You can see an architect over here, six hundred dollars. This is a local Codex session, and the rest are different s- a- agents running in different environments. But how do they work together, right? Do we have a bunch of Python
- 14:50
code triggering the agents so they can work together? We do not. Because all models right now, they are trained on a lot of data, so they understand very, very good how to communicate through messaging platforms. So here I have real work that I've done this morning. Engineering manager, developer, and architect, different instances of Claude Code, working together, reviewing
- 15:19
PRDs and SRS, reviewing implementation. There is no need to hand code all the loops. They know how to do it natively. And for the managers, we have full statistics. Let me kill off the mana- the, the engineering manager who sent too many messages. So you can see the attribution. You can see the full usage and cost. So if you ask your question, if my developer is actually involved in the code he pushes as a PR, or it's all AI
- 15:49
slop, you can see it here. Not only locally, right, but also through the remote agents. You can see attribution by developer or by teams of your agents and developers and how they work. Everything is gets updated in real time.
- 16:07
You can see all agents, and every agent is basically a session, right? So if I click here, I can see all the sessions of my Claude and Codex instances that are running, and they're connected to the platform, and they're connected to a global platform. So if I want, I can connect any of you to any of my agents in thirty seconds. Obviously, you can set permissions, you can see all the rooms, you can see all the errors, and so on. And also you can see work. What work was done, what is pending,
- 16:38
what is in progress, and everything works in real time.
- 16:43
Thank you very much. If you want to know more about the future of software development that does not involve you pulling another fifty packages, and if you want to enable your Salesforce and Slack and Databricks and Claude and Codex to work together and collaborate, come to our booth, LG17. QR codes for the Band, the infrastructure layer, and for the Gem, the, uh, desktop application to allow you to be part of this future that everyone talks about but has never seen. Thank you.