- Vlad Luzin of BAND argued that linking agents across users is a hard distributed systems problem, made harder because agents behave unpredictably.
- He said organizations also need agent identity and visibility into tool calls, on top of reliable message transport. Without all of it solved, he said, agents will not talk to each other.
Linking your agents to other people's agents is a hard engineering problem, said Vlad Luzin, who co-founded BAND and is its chief technology officer. He spoke on the AI Engineer show, in an episode published on October 7, 2026. He said such links need reliable message delivery, plus agent identity and visibility into tool calls.
What was said
Luzin began with a habit many engineers share. They run several agents side by side and carry messages between them by hand. Linking an agent on your laptop to someone else's agent in the cloud, he said, is a distributed systems problem. That means many separate computers must work together. He called such systems hard even before agents enter the picture.
Agents add unpredictability. He described each one as a microservice (a small program that runs on its own) that does not behave the same way twice. If one crashes, the whole group can fail. So the transport layer, the part that moves messages, must deliver in real time, keep order, retry and save state. He also listed runtime binding: matching the different IDs each tool uses, so agents work on one shared task.
Governance comes on top of that, he said. Organizations want identity and observability (the ability to see what happened). A log of the message between two agents is not enough. You also need to see which tool calls an agent made after receiving it. He called that very difficult across distributed systems. His conclusion: without all of that solved, agents will not talk to each other.
His demo showed one safeguard. A contact request between two agents needed approval from both sides. And because his agent was talking to another user's agent, he said, "no conversation can happen without me seeing it."
Why it matters
Our reading: this gives buyers a short set of questions. Before your agents talk to a supplier's or customer's agents, ask who each agent is. Ask whether you can see what it did after a message arrived. Ask whether it survives a crash.
The tool-call point matters most. A record of messages alone would miss the actions that follow. When you evaluate agent products, ask vendors whether their records cover those actions. The demo's two-sided approval is also worth asking about, as one way to control which agents meet.
The other side
Luzin sells a product in this space. BAND was launching its platform that week, so his list works as a pitch for a dedicated layer. It covers far more than governance: transport, runtime binding and a higher-level way to organize conversations.
His demos were recorded. The excerpts give no failure data, incident numbers or tests at scale. He also called existing protocols too low-level to build on at scale, and the excerpts do not test that view. The approval step he showed covers introducing two agents. What each agent may do once connected stays open in what we have.
Written by the WebPulse Newsroom with AI assistance, and checked by our editorial review: every quotation was verified against the recording's transcript. How we use AI.
The conversation this talking point comes from
- AI Engineer: Why Your AI Agents Can't Talk to Each Other (Yet) — Vlad Luzin, BAND (2026-10-07)





