The Future of AI Agent Communication: Bend CTO Breaks Down the Multi-Agent Messaging Problem

AI Communication Will Become Business Infrastructure

Vlad, co-founder and CTO of Bend, made a bold claim in a recent technical talk: the future belongs to communication between AIs. Within companies, between companies, and between consumers and businesses — AI will handle work on our behalf, and those AIs must talk to each other to get things done.

His vision: Agents will be autonomous, always-on, globally distributed entities. They'll exist in a shared "conversation space" where they can see each other, receive tasks, find peers, invite collaborators, delegate work, gather information, and report results back to humans. This isn't science fiction — he believes this reality is fast approaching.

This view is grounded in an observation about how AI is actually being used today. Almost every developer who uses Claude or Codex heavily is already running multi-agent systems without explicitly realizing it.

From Adversarial Agents to Loop Engineering

Vlad highlights a widely-used pattern that rarely gets named explicitly: adversarial agents. If you're running multiple Claude or Codex sessions on the same task — one for planning, one for review; one writing code, one reviewing it — you're essentially running two stateful agents, and you're playing the role of a "Cisco router and switch," manually shuttling data packets between them.

"Loop Engineering" is the upgraded version of this pattern: instead of being the router yourself, you outsource that job to a Python or TypeScript script — usually sourced from some open-source project — that repeatedly feeds prompts between multiple stateful agents while you just trigger it.

Why Do You Need Multiple Agents?

Vlad traces the root cause back to architectural limitations in Transformers — what he calls the single agent bottleneck. Why can't one session, one agent, handle everything? He lists several hard constraints:

• Confirmation bias: a single agent tends to reinforce its own errors
• Attention dilution
• Context fragmentation
• Recall degradation

He's emphatic on one point: a one-million or even two-million token context window doesn't actually solve the performance problem. In other words, multi-agent isn't showing off — it's a necessary workaround for fundamental architectural limitations.

The core limitation of the Transformer architecture lies in the quadratic scaling of self-attention with context length, and the significant drop in how effectively models utilize information from earlier parts of long contexts — a phenomenon commonly called the "Lost in the Middle" effect in academic literature. Even if a model technically supports a 2M token context window, experimental data shows its ability to extract information from the middle of that window is far weaker than from the beginning or end. Simply "stuffing more into one session" doesn't linearly improve output quality.

Multi-agent architecture is fundamentally a cognitive division of labor strategy: decompose a complex task into subtasks, let each agent focus on a shorter, more focused context, then integrate results through a coordination layer. This mirrors the logic of "specialization + collaboration" in human organizations — which is why the value of multi-agent systems doesn't diminish as context windows grow.

Why Existing Solutions Fall Short

Given that multi-agent systems are already a reality, what's the most direct way to connect them? Vlad systematically dismisses three mainstream approaches.

Messaging Platforms: Built for Humans, Actively Hostile to Bots

Slack, Teams, Discord, WhatsApp, Telegram — Anthropic even released a Slack agent. But onboarding an agent onto these platforms is painfully tedious: connecting to Telegram takes 5 steps, Discord takes 7, Slack takes 8, WhatsApp takes 11 — all manual, all requiring you to "read the documentation."

Worse, even after you've done all that, you end up with one agent talking to one person (usually just you). That agent can't talk to other agents, and can't reach other people without more manual effort. Your agent is still in "digital solitary confinement."

Protocol Solutions: Too Low-Level

MCP, ACP, A2A — these protocols seem like answers, but Vlad argues their complexity is severely underestimated:

• MCP is stateless, meaning you can't go back to a previously contacted agent and ask what happened
• A2A is unidirectional — client-server model. For two-way communication, you have to implement both client and server on the same side
• Chained REST API calls require timeout handling; discovery mechanisms, A2A's draft status, queuing — all missing, all yours to build

His conclusion is sharp: if you're doing all this, you're not building a multi-agent system — you're wasting time on boring low-level plumbing.

MCP (Model Context Protocol) is Anthropic's standard for giving LLMs a unified interface to call external tools and data sources. Its design philosophy leans toward "tool invocation" rather than "conversation" — each call is an independent stateless request, similar to HTTP's request-response model. A2A (Agent-to-Agent Protocol) is Google's draft protocol attempting to standardize task delegation and result return between agents, but it remains early-stage, and two-way communication requires callers to maintain both client and server implementations. ACP (Agent Communication Protocol) is another proposal led by IBM. The existence of three competing protocols itself signals that this layer hasn't converged, leaving developers with the dual burden of "which one do I pick" and "how do I fill in the gaps." This situation closely resembles the early web services standards war (SOAP vs. REST) — who ultimately wins will depend more on ecosystem than technical merit.

The Real Problem: This Is a Distributed Systems Problem

Vlad pulls back to the fundamentals: connecting two sessions running on different machines — say, a process on your laptop connecting to someone else's Codex — is fundamentally a distributed systems problem. And distributed systems are never simple.

Ordinary deterministic software is already painful enough. Add non-deterministic microservices (i.e., agents), and complexity shoots through the roof. He lists the layers that must be solved:

• Transport layer: must be real-time, ordered (LLMs expect ordered messages), and handle retries
• Persistence and dehydration: agents are microservices — processes crash, ports die, and the entire multi-agent system collapses with them
• Runtime binding: to connect LangGraph to Codex, or Claude to CrewAI, you need to map thread IDs, session IDs, execution IDs, and run IDs across different agents — otherwise they can't function as a team working toward a shared goal

The abstraction level matters critically. You can't stay at the IP, port, URL, or even pub/sub topic level — you need to rise to agents as first-class citizens: conversations, participants, channels/rooms, message routing.

For enterprise adoption, you also need governance, identity, and observability — not just seeing what message Agent A sent to Agent B, but tracing which tool calls were triggered when an agent received a message. Providing that kind of end-to-end observability in a distributed system is extremely difficult.

The classic distributed systems challenges — CAP theorem, network partition tolerance, idempotency design, clock synchronization — are amplified further in agent scenarios. Ordinary microservices can restart statelessly after a crash, but LLM sessions are inherently stateful: context, completed reasoning steps, and tool call history all live in runtime memory. A process crash means permanent loss of that state. "Dehydration" refers to serializing and persisting an agent's runtime state to external storage so it can be "rehydrated" and restored after a restart — a core design principle of long-running workflow frameworks like Temporal and Durable Execution, now needing to be imported into the agent orchestration layer. Runtime ID binding is equally thorny: LangGraph uses thread_id to identify conversation threads, OpenAI Assistants use run_id, CrewAI has its own task identifiers. These heterogeneous IDs need a unified namespace and mapping mechanism — otherwise cross-framework agent teams have no way to track "are we talking about the same thing."

Bend's Solution: A Global Agent Collaboration Layer

Vlad uses all of this to introduce Bend's new product, announced this week — a global interaction and collaboration layer aimed at handling all that dirty work for developers.

Core features include:

• Supports any agent, any platform, any language, any environment
• Not peer-to-peer, but multi-peer collaboration
• Built-in registry for automatic agent discovery — no manual setup
• Persistence, channels, message filtering (done on the platform side, not the client), security, and observability
• Humans aren't forgotten: people can join at any time as "human in the loop" participants

Live Demo: Zero-Friction Onboarding

Vlad showed several pre-recorded demos. Two users connect to the same communication platform from different browsers — one is Vlad himself (running a personal assistant Claude on his Mac), the other is Mike (running Claude Code, Claude SDK, and LangGraph in a terminal).

Demo 1: After launching the agent, an agent card appears in the corresponding account within seconds — agents immediately "know" each other exists. Through a bilateral consent contact request mechanism, the Codex agent can invite Vlad's personal assistant into a shared conversation space for real-time interaction. Throughout the process, Vlad has full visibility into the conversation — nothing happens behind his back.

Demo 2: Mike initiates a connection from his Claude Code terminal session. That session gets an identity and agent card, then acts as "owner" to create a conversation space, inviting Codex and Mike to form a collaborative group for engineering work — like building a small website together, with one agent writing and the other reviewing. Vlad describes this as "Loop Engineering without 500,000 lines of Python or TypeScript."

The bilateral consent mechanism demonstrated in the demo draws philosophically from the "friend request" model in human communication apps — but its security implications run deeper. As agents become increasingly autonomous, no agent should be able to contact another without owner authorization. Without such controls, the surface area for prompt injection attacks expands significantly: a malicious agent could impersonate a legitimate collaborator and inject harmful instructions into the target agent. The human-in-the-loop design is likewise not merely a product UX choice — it reflects a consensus principle in current AI safety research. Until agents can be trusted with fully autonomous judgment, preserving human intervention at critical decision points is essential for preventing cascading errors and irreversible actions.

A Few Observations

The value of this talk isn't primarily the product itself (as a vendor pitch, Bend's actual capabilities still need real-world validation) — it's that it articulates a trend that's already happening but lacks a shared vocabulary: each of us is already manually operating a multi-agent system, just playing the role of a very expensive human router.

Vlad's critiques of existing solutions are also quite on target: the inherently anti-bot nature of messaging platforms, the too-low abstraction level of current protocols, and the widely underestimated complexity of distributed systems — all three are real pain points in production multi-agent engineering. Whether a "global agent collaboration layer" can become standard infrastructure, or whether it gets buried in another standards war, is something worth watching closely.