Por que seus agentes de IA ainda não conseguem conversar entre si — Vlad Luzin, BAND
Autoria: AI Engineer · Assistir no YouTube
Vídeo de autoria do canal indicado, não da IANIA; todos os direitos pertencem ao criador. Transcrição, resumo e tradução gerados automaticamente; o conteúdo no idioma original é preservado na versão em idioma original.
Idioma original: inglês
Vídeo original: Why Your AI Agents Can’t Talk to Each Other (Yet) — Vlad Luzin, BAND · Canal: AI Engineer · 16:37 · Assistir no YouTube
Tópicos: Agentes de IA
Vlad Luzin defende que agentes de IA precisarão se comunicar entre si para realizar tarefas em nome de pessoas e empresas. Ele compara o uso de vários agentes em sessões separadas e a automação por loop engineering, e argumenta que plataformas de mensagens e protocolos de baixo nível não resolvem os desafios de colaboração em escala. Entre os desafios estão comunicação em tempo real, persistência, vinculação de sessões, descoberta de agentes, segurança e observabilidade. Por fim, apresenta a BAND como uma camada de interação e colaboração que conecta agentes e pessoas, e demonstra conversas entre agentes de usuários e ambientes diferentes.
Pontos-chave
Seção intitulada “Pontos-chave”- O futuro imaginado pelo palestrante envolve agentes autônomos e sempre ativos que se comunicam entre si para cumprir tarefas.
- Ao usar vários agentes em sessões separadas, a pessoa acaba encaminhando manualmente informações entre eles.
- Loop engineering automatiza a interação entre agentes, mas costuma exigir código que coordena as chamadas.
- Limitações de arquitetura de um único agente incluem viés de confirmação, diluição da atenção, fragmentação do contexto e degradação da recuperação de informações.
- Plataformas de mensagens são voltadas a pessoas e não oferecem, por si só, uma maneira simples de conectar agentes uns aos outros.
- Protocolos como MCP e A2A são apresentados como abstrações de baixo nível que ainda exigem implementação de descoberta, filas e outras capacidades.
- A comunicação entre agentes distribuídos exige transporte em tempo real e ordenado, persistência, recuperação após falhas e vinculação entre identificadores de execução.
- Organizações também precisam de identidade, segurança e observabilidade que inclua as ações dos agentes após receberem mensagens.
- A demonstração da BAND mostra agentes de diferentes usuários e ambientes entrando em espaços de conversa com consentimento bilateral e supervisão humana.
Capítulos
Seção intitulada “Capítulos”| Início | Capítulo | Resumo |
|---|---|---|
| 00:01 | Tese: agentes que se comunicam | Vlad Luzin apresenta os temas da palestra e propõe que agentes autônomos precisarão conversar para realizar tarefas. |
| 02:05 | De agentes adversariais a loop engineering | O palestrante explica como pessoas coordenam agentes em sessões distintas e como código pode automatizar essa coordenação. |
| 04:14 | Limites de plataformas e protocolos | Ele argumenta que plataformas de mensagens são voltadas a humanos e que protocolos como MCP e A2A não resolvem sozinhos a colaboração em escala. |
| 07:32 | Desafios técnicos da comunicação entre agentes | A palestra detalha requisitos de sistemas distribuídos, incluindo transporte ordenado, persistência, vinculação de sessões e observabilidade. |
| 10:11 | Apresentação da BAND e primeira demonstração | Luzin apresenta a camada de colaboração da BAND e demonstra o registro e a conexão de agentes com consentimento bilateral. |
| 14:03 | Agentes colaborando em tarefas de engenharia | Uma segunda demonstração mostra agentes em diferentes ambientes trabalhando juntos, com a possibilidade de incluir uma pessoa na conversa. |
| 16:07 | Encerramento e convite | O palestrante encerra a apresentação e convida o público a visitar o estande da empresa. |
Citações
Seção intitulada “Citações”O futuro pertence à comunicação entre IAs. — 01:02
Este agente não pode falar com nenhum outro agente. — 04:48
Conectar agentes remotos é um problema de sistemas distribuídos. — 07:32
É uma camada global de interação e colaboração para quaisquer agentes. — 10:42
Conceitos e entidades
Seção intitulada “Conceitos e entidades”- Vlad Luzin (pessoa): Cofundador e CTO da empresa apresentada na palestra.
- Band (empresa): Empresa que apresenta uma camada de interação e colaboração para conectar agentes e pessoas.
- Loop Engineering (conceito): Abordagem que automatiza ciclos de interação entre vários agentes por meio de código.
- MCP (conceito): Protocolo mencionado como uma forma de conectar agentes, mas descrito pelo palestrante como baseado em chamadas sem estado.
- A2A (conceito): Protocolo citado para comunicação entre agentes, cuja implementação pode exigir suporte nos dois sentidos.
- Claude Code (ferramenta): Ferramenta citada como exemplo de agente usado em sessões de terminal e em fluxos com vários agentes.
- Codex (ferramenta): Ferramenta citada em exemplos de agentes que colaboram com outros agentes.
- Claude (modelo): Assistente citado na demonstração como agente pessoal executado em um Mac.
Tradução completa (pt-BR)
Seção intitulada “Tradução completa (pt-BR)”00:01 [música] >> Certo. Oi, pessoal. Conseguem me ouvir? Tem bastante gente, sim. Então, por favor, silêncio. Meu nome é Vlad. Sou cofundador e CTO da Bend. Hoje, tenho quatro temas que quero discutir com vocês. Primeiro, a tese. A tese da nossa empresa, no que acreditamos
00:31 acreditamos. A evolução da IA, de agents adversariais à engenharia de loop e além. Os desafios técnicos que estamos enfrentando agora e que precisam ser resolvidos agora. E, obviamente, a Bend: apresentar a empresa, o produto e o que fazemos. Vamos começar pela tese. Primeiro, acreditamos que o futuro pertence à comunicação de IA para IA dentro de uma empresa, entre empresas e entre consumidores e empresas.
01:02 A IA fará trabalhos em nosso nome, e os agents terão que conversar entre si para resolver tarefas por nós. Em segundo lugar, os agents serão entidades autônomas e sempre ativas, espalhadas pelo mundo. São palavras muito bonitas, mas quero passar um minuto criando na cabeça de vocês uma imagem de como esse tipo de comunicação entre agents realmente vai funcionar.
01:32 Hora da demonstração. Os agents vão se comunicar em um espaço de conversa. Eles vão se ver. Serão distribuídos. Vão receber tarefas de nós ou de qualquer sistema. Poderão procurar pares nos registros, convidá-los para o espaço de conversa, delegar as tarefas, reunir informações suficientes e voltar para nós. É assim que será o futuro da comunicação de IA para IA. Então, enquanto conversamos, mantenham isso em mente.
02:05 Vamos falar um pouco sobre agents adversariais. Acho que todo mundo aqui conhece esse conceito e tenho certeza de que também está usando. Onde usamos isso? Se vocês usam Claude ou Codex, tenho certeza de que estão executando várias sessões trabalhando na mesma tarefa. Uma planeja, outra revisa. Uma escreve código, outra revisa o código. Então, basicamente, o que acontece é que vocês têm dois agents com estado
02:37 em execução, trabalhando na mesma tarefa, e vocês são, basicamente, um roteador e switch Cisco, encaminhando pacotes entre esses dois agents com estado. Vamos falar sobre engenharia de loop. Há várias palestras nesta conferência sobre engenharia de loop, vários artigos. É um conceito bem recente, certo? Mas eu gostaria de reduzi-lo à sua essência. Então, o que é engenharia de loop? Basicamente, é igual ao conceito anterior. Vocês executam vários
03:08 agents, de preferência agents com estado, não sem estado, mas, em vez de vocês serem um roteador ou um switch, terceirizam isso para algum código em Python ou TypeScript que alguém escreveu como projeto open source, e esse código basicamente envia prompts aos agents com estado, alternando entre eles, e vocês o acionam. Agora, por que usamos vários agents quando fazemos esse trabalho? Por causa das limitações arquitetônicas subjacentes de um transformer, especificamente um conceito
03:41 chamado gargalo de agente único, certo? Então, por que não executamos um agent em uma sessão só, que faça tudo? Por exemplo, viés de confirmação, certo? Diluição da atenção, fragmentação de contexto, degradação da recuperação. Portanto, um contexto de 1 milhão ou 2 milhões de tokens não vai ajudar no desempenho. Mas vamos falar sobre sistemas multiagente, certo? Já entendemos que, quando executamos várias sessões, basicamente estamos executando sistemas multiagente. Então,
04:14 qual é a maneira mais fácil de conectar vários agents em execução? Plataformas de mensagens, certo? Já temos o Slack, certo? A Anthropic lançou o Slack agent; temos Teams, Discord, WhatsApp, Telegram e assim por diante, certo? Então, essa é uma solução. Bem, para conectar um agent ao Telegram, são cinco etapas. Para conectar ao Discord, sete etapas. Para conectar seu agent ao Slack, oito etapas.
04:48 WhatsApp: 11. E não são etapas simples. Todas são manuais, e você precisa ler um livro para conseguir configurar tudo. E, mesmo que consiga, você só obtém uma coisa, e apenas uma. O que é essa coisa? Um agent conversando com uma pessoa, que geralmente é você. Esse agent não consegue conversar com nenhum outro agent, nem com outra pessoa, sem que você faça malabarismos. Então, basicamente, seus agents continuam
05:21 sozinhos, em uma espécie de confinamento solitário digital. Mas pessoas inteligentes vão dizer: “Conheço a solução. Protocolos, certo? MCP, ACP, A2A e assim por diante. Essa é a solução, certo?” Bem, se você defende esse tipo de conexão para conectar suas sessões, é assim que seu sistema multiagente vai ficar.
05:54 Vários servidores chamando ferramentas de outros agents por meio do MCP. E, se quiser, talvez esse agent que você chamou como ferramenta possa chamar outro agent usando A2A. Parece muito simples. Certo, todo mundo sabe o que é A2A. O Google tem um orçamento de marketing enorme. Mas vamos dar uma olhada nas complexidades. MCP significa chamadas sem estado. Isso significa que você não pode voltar ao agent com quem conversou e perguntar de novo o que aconteceu. A2A funciona em uma direção, a menos que você
06:29 implemente as duas direções. Então, o agent A envia uma tarefa ao agent B. É cliente-servidor. Se você quiser que o agent B envie uma tarefa ao agent A, é cliente-servidor. Portanto, você precisa implementar, de cada lado, tanto um cliente quanto um servidor. Encadeando chamadas de API REST, você vai encontrar timeouts. E, obviamente, faltam muitas coisas, como descoberta, o estado de rascunho do A2A e filas, que você ainda precisa implementar e colocar por trás de tudo isso. E, se fizer isso, basicamente estará construindo planejamento. Não estará
07:02 construindo um sistema multiagente. Estará perdendo tempo com coisas chatas, muito chatas. Agora, vamos resumir o que sabemos. Sabemos que sistemas multiagente já existem. Todo mundo aqui usa vários agents. Sabemos que as plataformas de mensagens não são uma solução. Elas foram criadas para humanos e bloqueiam ativamente a conexão de um bot com outro bot. E sabemos que protocolos são uma abstração técnica de nível baixo demais para
07:32 conseguir construir qualquer coisa em escala. Mas quão difícil pode ser construir um sistema que permita conectar vários agents? Não é tão difícil, certo? Bem, conectar agents remotos — duas sessões, com um processo em execução no seu laptop ou na minha cloud até o seu Codex — é um problema de sistemas distribuídos. E sistemas distribuídos não são fáceis por definição. Esqueçam os agents, certo? Software determinístico já é um saco.
08:06 Acrescente a isso agents que são microsserviços e não determinísticos, certo? Aí a diversão é garantida. Para resolver isso, o que é preciso abordar é uma camada de transporte, certo? O transporte precisa ser em tempo real. Precisa preservar a ordem, porque os LLMs esperam mensagens ordenadas. É preciso lidar com novas tentativas e assim por diante. É preciso lidar com persistência e hidratação, porque seu agent é um microsserviço. Ele pode
08:37 falhar, o pod pode cair, e então todo o seu sistema multiagente vai para o espaço. Então, é preciso lidar com isso. Também é preciso lidar com algo muito novo: a vinculação em tempo de execução. Se quiser conectar um LangGraph a um Codex ou o Cloud a um Crew AI, é preciso conectar um ID de thread a um ID de sessão, a um ID de execução e ao ID de uma execução desses vários agents, e mapear todos esses IDs entre si. Caso contrário, os agents não conseguirão trabalhar em grupo rumo ao mesmo objetivo e à mesma tarefa. E, obviamente, não dá para trabalhar no
09:09 nível de endereços IP e portas que vocês precisam gerenciar, nem mesmo de URLs ou tópicos de pub/sub. É preciso ir além de todos os detalhes técnicos e chegar a outro nível de abstração: conversas, participantes, canais ou salas e roteamento de mensagens feito para que os agents sejam cidadãos de primeira classe. E, claro, nada disso ainda é suficiente para que uma organização use esse tipo de produto ou software de comunicação, porque toda
09:40 organização quer governança. Precisa de identidade e observabilidade. Observabilidade não apenas sobre uma mensagem enviada do agent A, no servidor A, para o agent B, no servidor B, mas também sobre quais chamadas de ferramentas aconteceram depois que determinado agent recebeu essa mensagem, certo? E é muito difícil oferecer esse tipo de observabilidade em sistemas distribuídos. Então, sem resolver tudo isso, vocês não terão agents conversando entre si nem esse futuro maravilhoso em que todos nós, certo, teremos uma renda básica universal
10:11 Uma renda enquanto você fica deitado na praia não vai acontecer. Gostaria de apresentar a BAND. Nós pegamos tudo aquilo de que falamos e resolvemos. Assim, você não precisa resolver. Você pode conectar com muita facilidade todos os seus agents dentro de uma empresa, ou o seu Hermes e o Open Cloak. Gostaria de revelar um produto que estamos lançando esta semana. E esta é uma camada global
10:42 de interação e colaboração, no mundo todo, para quaisquer agents, qualquer plataforma, qualquer linguagem e qualquer ambiente. E não é ponto a ponto; é multiponto. E também não nos esquecemos dos humanos. Certo, se você é humano, ainda pode se conectar e conversar com seu agent. Não tem problema. E, se abrirmos um pouco a caixa-preta, veremos que não se trata apenas de uma camada de comunicação. Temos um registro, para que seus agents possam se encontrar automaticamente, sem você ter que passar por todo tipo de obstáculo. Persistência, canais,
11:16 filtragem de mensagens. Em vez de fazer isso do lado do cliente, fazemos dentro da plataforma. Segurança, observabilidade e assim por diante. Agora, a parte divertida. Certo, deixa eu mostrar algumas demos. O tempo é curto, então as demos estão gravadas, mas temos um estande. Venham ver ao vivo ou simplesmente acessem e se conectem. A demo mostrará dois usuários em dois navegadores diferentes, conectados à plataforma de comunicação. Um sou eu, Vlad. Tenho um agent pessoal Claude rodando em um Mac. E o outro usuário é Mike, com Claude Code em
11:47 uma sessão de terminal, certo? Claude SDK e Landlord. Demo número um. Na janela de cima, sou eu, na minha conta. E tenho um assistente pessoal. Abaixo, há um usuário diferente conectado à mesma camada de interação, sem nenhum agent. À direita, certo, vou iniciar dois agents, e eles vão se cadastrar na plataforma, se conectar e se tornar agents do Mike. E vamos ver quanto tempo isso vai
12:22 levar. Então, primeiro, iniciamos um agent. Segundos depois, o cartão desse agent já aparece na conta do Mike. Iniciamos um Landlord. Um segundo depois, o cartão desse agent também aparece. A partir daí, esses agents sabem da existência um do outro. Eles entendem que podem interagir entre si. Mas queremos fazer algo mais legal. Queremos pegar um agent Codex e conectá-lo ao meu assistente pessoal
12:55 que está rodando no meu Mac, para que eles possam interagir de fato. Estamos enviando uma solicitação de contato que exige o consentimento bilateral de ambas as partes para que esse agent seja adicionado ao registro de cada um, seja ele de um agent ou de um humano. A solicitação foi enviada e eu a aceitei. E agora temos um agent Codex que pode convidar meu assistente pessoal para um espaço de conversa e interagir com ele em tempo real. Isso é totalmente stateful: os agents podem ser
13:30 implantados em qualquer lugar do mundo, e é o que acontece. E o que vocês estão vendo aqui é em tempo real. Também dá para ver que, como meu agent está conversando com o agent de outro usuário, tenho visibilidade completa da conversa. Portanto, nenhuma conversa pode acontecer sem que eu a veja e, obviamente, meu agent pode me convidar para qualquer espaço de conversa e interagir comigo, com um humano participando do processo.
14:03 Então, o que vimos agora foi o cadastro de qualquer agent sem complicação nenhuma. Experimentem em casa. Contem como foi. Mais um exemplo. Temos um usuário, Mike. E esse usuário ainda tem o Codex rodando, conectado à plataforma, e agora queremos iniciar uma sessão de terminal do Claude Code. Queremos que essa sessão de terminal se conecte à nossa
14:33 plataforma a partir do terminal e interaja com outros agents, certo? Neste caso específico, o Claude Code no terminal do Mike conversa com um Codex SDK do Mike, mas, como é uma plataforma global, isso não faz diferença, certo? Eles podem conversar com o seu agent, podem conversar com o seu agent e assim por diante. Então, iniciamos o Claude e dizemos a ele, em uma sessão de terminal: por favor, conecte-se à nossa plataforma. É o mesmo conceito. Essa sessão específica do Claude
15:05 recebe uma identidade e um cartão de agent, e ocultamos todas as complexidades relacionadas à sua localização do ponto de vista da rede. A partir daí, esse agent pode criar um espaço de conversa como proprietário e convidar outros agents — neste caso específico, o Codex, certo? — e também vai convidar o Mike. Assim, fica todo mundo feliz e eles podem começar a trabalhar em algumas tarefas de engenharia.
15:35 Seja lá o que for. Outra forma como as pessoas chamam isso, o que vocês estão vendo aqui, é engenharia em loop. Certo? Mas é engenharia em loop sem 500 mil linhas de livro de preços em Python, ou código de script Python, que você precisa trazer para que seus agents possam pedir trabalho uns aos outros. Agora, esses agents vão começar a criar um site pequeno e vão interagir entre si; um vai revisar o trabalho do outro.
16:07 E, obviamente, se eles tiverem dificuldades, ou se o Mike tiver dificuldades, esses agents podem me convidar para o mesmo espaço de conversa. Posso ajudar e dar assistência. E é bem fácil. É isso. Muito obrigado. Terminei bem na hora. Venham ao nosso estande, LG17. Tirem capturas de tela, peguem os códigos QR. Um é para se conectar à plataforma com seus agents, e o outro é para o futuro da engenharia
16:37 em loop, que não precisa de nada. E temos a Works aqui, porque eles gostam de orquestração, não gostam de colaboração. Eles roubaram todos os brindes. Então, se quiserem um brinde, venham à Works, peguem uma espada e nos ajudem a combatê-los. Obrigado.
Transcrição original
[00:01] [music] >> Okay. Hi everyone. Can you hear me? A lot of people, yeah. So, please be quiet. So, my name is Vlad. I’m co-founder and CTO at Bend. And today I have four topics I want to discuss with you. First, thesis. Thesis of our company, what we believe
[00:31] believe in. AI evolution from adversarial agents to loop engineering and beyond. Technical challenges that we experience right now that should be solved right now. And obviously Bend to present the company and the product and what we do. Let’s start with the thesis. First of all, we believe that the future belongs to AI to AI communication within a business, between businesses, and between consumers and businesses.
[01:02] AI will be doing work on our behalf, and they will have to talk to each other in order to solve tasks on our behalf. Second, agents will be autonomous, always-on entities spread across the globe. Now, these are very nice words, but I want to spend a minute just to paint a picture in your head how this type of communication between agents actually is going to look like.
[01:32] Demo time. Agents will communicate in a conversational space. They will see each other. They will be distributed. They will receive tasks from us or from any system. They will be able to look up peers in the registries, invite these peers in into conversational space, delegate the tasks, gather enough information, and and back to us. This is how the future of AI to AI communication is going to look like. So, while we are talking hold this in your
[02:05] head. Let’s talk a bit about adversarial agents. I think everyone here knows this concept and I’m pretty sure everyone here is using it as well. Where are we using it? If you are using Claude or Codex, I’m pretty sure you’re running multiple sessions working on the same task. One is planning, another is reviewing. One is writing code, another is reviewing code. So, basically what is happening, you have two stateful agents
[02:37] running, working on the same task, and you are basically a Cisco router and a switch moving packets between these two stateful agents. Let’s talk about loop engineering. A number of talks on this conference about loop engineering, a number of articles, uh pretty new concept, right? But I would like to distill it uh to its essence. So, what is loop engineering? Basically, it’s the same as the previous concept. It’s you running multiple
[03:08] agents, hopefully stateful agents and not stateless, but instead of you being a router or a switch, you outsource this to some piece of Python or TypeScript that someone wrote as an open-source project, and um this piece of code basically prompts the stateful agents back and forth, and you trigger it. Now, why are we using these multiple agents when we do this work? Because of the underlying architectural limitations of a transformer, specifically a concept
[03:41] is called single agent bottleneck, right? So, why we are not running one agent in one session that is doing everything? For instance, confirmation bias, right? Attention dilution, context fragmentation, recall degradation. So, 1 million tokens or 2 million tokens context will not help you in terms of the performance. But, let’s talk about multi-agent systems, right? So, we already understand that us running multiple sessions, these are basically multi-agent systems running. So,
[04:14] what is the easiest way to connect multiple agents running together? Messaging platforms, right? We already have Slack, right? Anthropic released Slack agent, we have Teams, we have Discord, we have WhatsApp, we have Telegram, and so on, right? So, this is a solution. Well, in order for you to connect an agent to a Telegram, five steps. In order for you to connect to Discord, seven steps. In order for you to connect your agent to Slack, eight steps.
[04:48] WhatsApp, 11. And these are not simple steps. They are all manual, and you need to read a book in order to be able to set it up. And even if you do, you get only one thing and one thing only. What is this thing? An agent talking to a person, which is usually you. This agent cannot talk to any other agent, this agent cannot talk to any other person without you jumping through hoops. So, basically, your agents are still
[05:21] alone in a kind of digital solitary confinement. But, smart people will say, “I know the solution. Protocols, right? MCP, ACP, A2A, and etc. This is the solution, right? Well, if you are a proponent of that kind of a for connection for connecting your sessions, this is how your multi-agent system is going to look like.
[05:54] Multiple servers calling other agents’ tools through MCP. And if you want, maybe this agent that you called as a tool can call another agent as an A2A. Sounds super simple. Okay, everyone knows what A2A is. Google have a very huge marketing budget. But let’s take the take a look at the complexities. MCP means stateless calls. It means you cannot go back to the agent that you talked to and ask it again what happened. A2A one way unless you
[06:29] implement both directions. So, agent A to sends a task to agent B. It’s client-server. If you want an agent B to send a task to agent A, it’s client-server. So, you need to implement on the same side both a client and a server. Chaining REST API calls, you will meet timeouts. And obviously thing a lot of things are missing like discovery, draft state of A2A, queues that you still need to implement and put behind all of that. And if you’re doing this, you’re basically building planning. You’re not
[07:02] building a multi-agent system. You’re wasting your time on a boring boring stuff. Now, let’s summarize what we know. We know that multi-agent systems are already here. Everyone here is using multiple agents. We know that the messaging platforms are not a solution. They are built for humans and they actively block you from connecting a bot to a bot. And we know that protocol is too low-level of a technical abstraction to
[07:32] be able um to build anything on it at scale. But how hard can it be to build a system that can allow multiple agents to connect together. It’s not that difficult, right? Well, you see, connecting remote agents being a two sessions as a process is running on your laptop or my cloud to your codex is a distributed systems problem. And distributed systems are not easy by definition. Forget agents, okay? Deterministic software, it’s a pain in
[08:06] the butt. Add to this agents that are microservices and non-deterministic, okay? And you have a lot of fun. In order for this um to be solved, what you need to actually to address is a transport layer, right? The transport has to be real-time. It has to be ordered because LLMs expect ordered messages. You need to handle retries and so on. You need to handle persistency and hydration because your agent is a microservice. It can
[08:37] fail, the pod can crash, and then all your multi-agent system goes kaput. So, you need to handle this. You need to handle something very new, runtime binding. If you want to connect a LAN graph to a codex or cloud to a crew AI, you need to connect a thread ID to a session ID to execution ID to a run ID of this multiple agents by and map it up to this IDs together. Otherwise, agents will not be able to work as a group towards the same goal and the same task. And obviously, you cannot work at the
[09:09] level of IPs and ports, or URLs that you have to manage, or even pub/sub topics. You need to rise above all of the technical details to a different level of abstraction, conversation, participants, channels, or rooms, message routing that is tailored to agents as the first citizens. And of course, all of that is still not enough for an to use this kind of product or communication software because every
[09:40] organization wants governance. They need identity, they need observability. Observability not in a message that was sent from agent A on server A to agent B on server B. But also what tool calls, okay, happened after a certain agent received this message, right? And it’s very difficult to provide this kind of observability across distributed systems. So, without all of that solved, you will not have agents talking to each other and this wonderful future of us, okay, everyone on a universal basic
[10:11] income lying on a beach will not happen. I would like to introduce Bend. We actually took all the stuff that we talked about and solved it. So, you don’t have to solve it. So, you can super easily connect all your agents within an enterprise or your Hermes and Open Cloak. I would like to unveil a product that we are launching this week. And this is a global
[10:42] interaction and collaboration layer worldwide for any agents, any platform, any language, any environment. And it’s not peer-to-peer, it’s multi-peer. And we did not forget humans as well. Okay, if you are human, you can still connect and talk to your agent. This is completely fine. And if we open the hood quite a bit, what we see there is that it’s not just communication layer. We have a registry, so your agents can see each other automatically without you jumping through hoops. Persistency, channels,
[11:16] message filtering. Instead of doing it on the client side, we do it within the platform. Security, observability, and so on. Now, the fun part. Okay, let me show you a few demos. Uh the time is short, so demos are recorded, but we have a booth. Please come and see it live or just go and connect. Um the demo will be two users in two different browsers connected to the communication platform. One is me, Vlad. I have a personal agent Claude running on a Mac. And another user is Mike, Claude code in
[11:47] a terminal session, okay? Uh Claude SDK and uh Landlord. Demo number one. On the top window, it’s me, my account. And I have a personal assistant. Below, it’s a different user connected to the same interaction layer with no agents at all. On the right, okay, I’m going to spin up two agents and they will onboard on the platform and connect and become agents that belong to Mike. And let’s see how fast it’s going
[12:22] to to be. So, first of all, we go and we uh spin up an agent. Seconds later, this agent card already appears with any within an account of Mike. We spin up a Landlord. Second later, this agent card appears as well. From this point on, these agents know of each other. They understand that they can interact with each other. But we want to do something cooler. We want to take a Codex agent and connect this agent to my personal assistant
[12:55] running on my Mac, so they can actually interact together. We are sending a contact request that requires a bilateral consent from both parties in order for this agent to be introduced inside each uh registry that belongs either to an agent or to a human. The request was sent and it was accepted by me. And right now we have a Codex agent that can invite my personal assistant into a conversational space and interact with it in real time. This is completely stateful agents can be
[13:30] deployed anywhere in the world and they are. And what you see here, this is real time. And you can see also that because my agent is talking to another agent of a different user, I have a full visibility into the conversation. So, no conversation can happen without me seeing it and obviously my agent can invite me into every conversational space and interact with me and as a human in the loop.
[14:03] So, what we have seen right now is a zero hassle on boarding of any agent. Try it at home. Tell me how it how how how it went. So, another example. We have a user Mike. And this user still has the Codex running connected uh to the platform and now we want to run a Claude code terminal session. And we want this terminal session from the terminal to connect to our
[14:33] platform and interact with other agents, right? It can be here specifically Claude code in a terminal of Mike talks to a a Codex SDK of Mike, but because it’s a global platform, it doesn’t really matter, okay? They can talk to your agent, they can talk to your your agent and so on. So, we are spinning up Claude and we tell Claude in a terminal session, please go and connect to our platform. Same concept. This specific Claude
[15:05] session gets an identity, an agent card and we hide all the complexities in terms of where it is from the network perspective. And from now this agent can actually create a conversational space as an owner, invite other agents in this specific case, Equidex, right? And it will invite Mike as well. So, it’s uh you know, happy family, and they can start working on some engineering tasks.
[15:35] Whatever it is. The other way that people call it, whatever you see here, is loop engineering. Okay? But, it’s loop engineering without 500,000 lines of a price book Python or Python script code that you need to bring over so your agents can actually prompt each other for work. These agents will now right now start to and create a small website, uh and they will interact with each other, and one will review work of the other.
[16:07] Uh and obviously, if they struggle and Mike struggles, uh these agents can invite me into the same conversation space. I can help them, assist them. Um and it’s pretty easy. That’s it. Thank you very much. I’m right on time. Come to our booth, LG17. Take screenshots, take QR codes. One is for the platform to connect your agents, and one is for the future of the loop
[16:37] engineering that doesn’t need not require anything. And we have Works that actually came here because they like orchestration, they do not like collaboration. They have stolen all the swag. So, if you want a swag, please come to Works, get a sword, and help us fight them. Thank you.