AI agents will need to communicate across businesses, frameworks, languages, and deployment environments without a human copying messages between them.
2
MCP and A2A provide low-level calls, but teams still need to build state, discovery, queues, timeouts, routing, and persistence around them.
3
Agent collaboration requires distributed-systems infrastructure plus higher-level concepts such as rooms, participants, identity, audit, and real-time observability.
Summary
Vlad Luzin argues that agent-to-agent collaboration is already a practical engineering problem. Developers who run one coding agent to do work and another to review it are manually routing messages between stateful processes. Loop engineering moves that routing into code, while MCP and A2A provide useful connections without solving state, discovery, delivery, persistence, or governance. Luzin frames the problem as a distributed system made harder by non-deterministic services. He describes the infrastructure required for ordered real-time transport, retries, continuity after crashes, mapping IDs across agent frameworks, deterministic conversation routing, identity, and audit. He then presents Band as a collaboration layer for agents and demonstrates agents registering, discovering one another, requesting consent, joining conversations, and working together. A second product, Jam, provides visibility into routing, costs, token usage, sessions, architecture work, and human involvement across local and remote agents.
AI agents will need to communicate directly across organizational and technical boundaries
Luzin's company thesis is that AI agents will communicate within businesses, between businesses, and between consumers and businesses. He expects agents to appear in different frameworks, languages, and deployment environments. They will receive work from people or other systems, discover agents that can help, add them to a conversation, exchange messages, and report the result to humans. His example is a conversational space that agents create and manage themselves. The point is broader than connecting two tools in one application. Agents need to find and work with other agents that may belong to different users and run somewhere else.
Developers are already acting as routers between isolated agents
Luzin describes a common workflow in which one coding session performs work and another reviews it. Developers often run several tabs and sessions at once, then copy prompts and outputs between them. The human is functioning as a network switch between stateful agents that cannot communicate directly. Loop engineering moves that job into Python or TypeScript libraries so agents prompt each other. It removes some manual copying, but it also leaves teams to design the abstractions and control flow that make the loop work.
MCP and A2A leave important coordination work to the application
Luzin argues that MCP calls agents as tools in a stateless way, which creates problems when two agents need a stateful relationship and sticky sessions. A2A uses a client-server model, so agents that need to send work both ways must act as both clients and servers. Chaining agents can introduce REST timeouts. Teams still need persistent queues to track messages, and discovery is outside A2A. Messaging platforms do not solve this either. Slack, Telegram, Discord, and WhatsApp require manual setup and mainly let an agent talk to a person. The agents remain isolated from one another.
Multi-agent applications are distributed systems with non-deterministic services
Connecting two agent sessions on a laptop, or linking agents across systems such as Salesforce, Databricks, SAP, and Codex, means sending messages over a network. Luzin says this is a distributed-systems problem before agents make it harder. Each remote agent behaves like a microservice, but its behavior is non-deterministic. The infrastructure therefore has to handle ordered and real-time delivery, retries, and continuity when software, containers, or pods crash. It also has to restore the agent's state rather than losing the conversation when a process disappears.
Different agent frameworks use different identifiers, including thread IDs, conversation IDs, and execution IDs. A collaboration system has to map those identifiers so that agents can continue interacting across runtimes. Luzin says IP addresses, URLs, and pub-sub topics are too low-level for organizations to manage directly. The abstraction should rise to conversations, rooms, channels, and participants. It must also define deterministic routing within a channel and across channels. Without that layer, teams are still doing the plumbing and planning themselves.
Identity, consent, audit, and observability belong in the collaboration system
Luzin adds a governance layer to the transport and runtime problems. Agents need identity, audit, and controls for who can connect to whom. In the Band demonstration, an agent from one user's registry sends a connection request to another user's personal assistant. The assistant becomes visible to the requesting agent only after bilateral consent. Luzin also shows monitoring for sessions, rooms, errors, work status, token costs, and human involvement. This gives managers a way to see what local and remote agents are doing instead of returning to separate terminal sessions.
Band provides shared agent registration, discovery, and conversations
Luzin introduces Band as a global collaboration layer for agents across frameworks and deployment environments. In the first demonstration, he registers a Codex agent and a LangGraph agent programmatically. Each receives an agent card, and the agents can discover one another. Codex then requests access to Luzin's personal assistant, invites it into a conversation after approval, sends a message, and receives a report back. The demonstration presents onboarding and consent as platform operations rather than custom integration work for every pair of agents.
Jam gives teams a view of work across local and remote agents
Jam is Band's internal desktop application for onboarding local agents and managing multi-agent, multi-human work. Luzin says it addresses routing, context overload, cost management, attribution, and human participation. It captures tasks generated by Claude and Codex, shows where agents are working in a software architecture, and marks completed work. Managers can inspect traffic, sessions, rooms, errors, pending work, and in-progress work. The system also attributes token costs and developer involvement, while terminal-based work can continue because communications still pass through the network.
"A multi-agent system where every agent is remote is basically a distributed system of microservices where each microservice is non-deterministic."07:46
Who should watch
You run multiple Claude Code or Codex sessions and currently copy prompts and results between them.
Your team is connecting agents across frameworks or enterprise systems and needs state, discovery, delivery, consent, and audit outside the model calls.
You want operational visibility into agent sessions, token costs, human involvement, and work completed across local and remote environments.
