Seus agents estão em confinamento solitário: por que MCP e A2A não bastam — 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: Your Agents Are in Solitary Confinement: Why MCP & A2A Aren’t Enough — Vlad Luzin, Band · Canal: AI Engineer · 17:33 · Assistir no YouTube

Tópicos: Agentes de IA, Engenharia de software com IA, Infraestrutura e hardware de IA

Resumo

Vlad Luzin defende que a comunicação entre agents será essencial, mas que protocolos como MCP e A2A não resolvem, por si só, os desafios de coordenação entre sistemas distribuídos, como continuidade, entrega de mensagens, descoberta e governança. Ele apresenta a Band como uma camada de colaboração para conectar agents de diferentes frameworks e ambientes, com recursos de identidade, consentimento e comunicação em conversas compartilhadas. Também demonstra o Jam, um aplicativo desktop para acompanhar o trabalho de agents locais e remotos, organizar tarefas e atribuir custos. A proposta é permitir que pessoas e agents colaborem sem depender de integrações manuais ou de código específico para orquestrar cada interação.

Pontos-chave

A tese da Band é que agents autônomos precisarão se comunicar entre si em diferentes empresas, frameworks, linguagens e ambientes.
Quando desenvolvedores alternam entre sessões de agents e copiam informações manualmente, atuam como roteadores entre sistemas que não se comunicam.
MCP e A2A não resolvem sozinhos questões como comunicação com estado, sessões persistentes, descoberta de agents e encadeamento de tarefas.
A coordenação entre agents é um problema atual de sistemas distribuídos, com desafios de entrega ordenada, retries, continuidade e associação de IDs.
A proposta da Band é elevar a abstração técnica para salas, canais e participantes, acrescentando roteamento determinístico e governança.
A plataforma demonstra cadastro de agents, descoberta mútua e solicitações de conexão que exigem consentimento bilateral.
O Jam reúne informações sobre tarefas, sessões, arquitetura do software, atividade dos agents e envolvimento humano.
A plataforma também oferece estatísticas de tráfego e atribuição de custos por sessão, desenvolvedor ou equipe.

Capítulos

Início	Capítulo	Resumo
00:01	Tese: agents precisam se comunicar	Vlad apresenta a visão de um futuro em que agents autônomos colaboram entre empresas, pessoas e sistemas.
03:40	Limites de MCP, A2A e das integrações manuais	O palestrante explica por que protocolos e plataformas de mensagens não eliminam a necessidade de coordenação manual entre agents.
06:45	Coordenação como problema de sistemas distribuídos	A conversa entre agents exige resolver transporte, continuidade, associação de identificadores, roteamento e governança.
09:21	Demonstração da camada de colaboração Band	A Band conecta agents de diferentes usuários e apresenta cadastro, descoberta e solicitações de conexão com consentimento.
11:35	Jam: acompanhamento do trabalho dos agents	O Jam reúne sessões locais e remotas, tarefas, informações de arquitetura e colaboração entre agents e pessoas.
14:12	Painéis, custos e atribuição	A demonstração mostra estatísticas de tráfego, custos, sessões, permissões e trabalho concluído ou pendente.
16:47	Convite para conhecer os produtos	Vlad encerra convidando o público a conhecer a infraestrutura Band e o aplicativo desktop Jam.

Citações

O futuro pertence à comunicação entre AI dentro das empresas, entre empresas e entre consumidores e empresas. — 01:05

Seu agent continua sozinho. Ele não consegue ver os outros nem se comunicar com eles. Está em confinamento solitário digital. — 06:15

Um sistema multi-agent em que cada agent é remoto é basicamente um sistema distribuído de microsserviços, em que cada microsserviço é não determinístico. — 07:48

Precisamos elevar a abstração da pilha técnica para conversas e falar de salas, canais e participantes. — 08:49

Conceitos e entidades

Vlad Luzin (pessoa): Cofundador e CTO da Band, que apresenta a tese e os produtos da empresa.
Band (empresa): Empresa que apresenta uma camada global de colaboração e comunicação entre agents.
Jam (ferramenta): Aplicativo desktop interno da Band para conectar agents locais e acompanhar tarefas, colaboração e custos.
MCP (conceito): Protocolo citado como uma forma de conectar agents, mas que, segundo o palestrante, não resolve sozinho a comunicação com estado.
A2A (conceito): Protocolo de comunicação entre agents que o palestrante descreve como baseado em uma arquitetura cliente-servidor.
ACP (conceito): Protocolo mencionado junto a MCP e A2A como parte do conjunto de opções de comunicação entre agents.
sistemas distribuídos (conceito): Arquitetura em que processos remotos precisam se comunicar, com desafios de entrega, falhas e consistência.
confinamento solitário digital (conceito): Metáfora usada para descrever agents que não conseguem descobrir nem se comunicar com outros agents.
Codex (ferramenta): Agent apresentado na demonstração da Band, que se conecta a outros participants da plataforma.
Claude (ferramenta): Produto cujas tarefas e sessões são mencionadas como parte do acompanhamento de trabalho no Jam.

Tradução completa (pt-BR)

00:01 [música] >> Olá a todos. Meu nome é Vlad. Sou cofundador e CTO da Band. Antes de começarmos, vamos fazer uma pequena pergunta de curiosidades. Orc C, certo? Quem escolhe C, levante a mão. K? Quem acha que as duas estão corretas?

00:33 Certo, só alguns. As duas estão corretas. Uma é de O Senhor dos Anéis, a outra é dos jogos de Warhammer, da Games Workshop. Tenho quatro tópicos na minha pauta. Primeiro, gostaria de falar sobre a tese da nossa empresa, no que acreditamos. Depois, vamos falar sobre a evolução da IA, de agents adversários à engenharia de loop e além. Em seguida, vamos abordar os desafios técnicos de amanhã que precisamos resolver hoje. E, então, gostaria de

01:05 apresentar a empresa, o que fazemos e quais problemas resolvemos. Então, nossa tese é que o futuro pertence à comunicação de IA com IA dentro de uma empresa, entre empresas e entre consumidores e empresas. Os agents estarão por toda parte. Eles trabalharão em nosso nome e terão que se comunicar entre si. Serão escritos em frameworks diferentes, em linguagens diferentes e implantados em ambientes diferentes. E esses agents serão totalmente autônomos. Eles vão se comunicar uns com os

01:36 outros sem intervenção humana. Agora, só para dar uma ideia antes de começar a falar sobre como será esse tipo de comunicação entre os agents: o que vocês veem aqui é um espaço de conversa que os agents podem criar por conta própria. Eles podem ser adicionados. Receberão uma tarefa de uma pessoa ou de outro sistema. E poderão descobrir outros agents, adicioná-los como participantes nesse espaço de conversa, trocar mensagens, resolver a tarefa e

02:07 dar uma resposta às pessoas. É assim que será o futuro sobre o qual todos vocês leem nos jornais. E, quando as pessoas ouvem isso, acham que esse futuro está muito distante ou que eu sou maluco. Certo, é isso. E aqui está um exemplo de uma conversa que tive com o CTO de uma empresa de US$ 10 bilhões, que disse que, antes de pensar em soluções técnicas para problemas hipotéticos, como a coordenação multi-agent,

02:37 ele tenta manter as coisas simples e evitar o problema. Agora, vamos analisar isso. A coordenação multi-agent é um problema hipotético? É possível manter as coisas simples? E é possível evitar o problema? Agora, vamos falar um pouco sobre agents adversários como conceito. Todos nós usamos isso. Tenho quase certeza de que todos aqui são desenvolvedores. E, como desenvolvedor, vocês têm duas sessões no Claude Code ou de programação.

03:09 Uma está fazendo o trabalho, a outra está revisando. E provavelmente vocês não têm só duas sessões; provavelmente têm várias abas e várias sessões trabalhando ao mesmo tempo em vários problemas. Basicamente, vocês estão atuando como um roteador, um roteador Cisco ou um switch entre dois agents com estado que trabalham em seu nome, mas que não conseguem se comunicar. Por isso, vocês precisam dar prompts a eles. Vamos falar sobre engenharia de loop.

03:40 Vocês ouviram o cara que falou antes mencionar Peter e Boris, certo? Então, o que eles dizem? Basicamente, dizem: “Parem de ser o roteador entre seus agents e deixem que eles deem prompts uns aos outros.” O que eles estão dizendo, basicamente, é que, em vez de serem o roteador e ficarem copiando e colando coisas, vocês devem começar a se atrapalhar com bibliotecas de Python e TypeScript e diferentes camadas de abstração que vão inventar como os agents devem dar prompts uns aos outros.

04:11 Também temos protocolos: A2A, MCP, ACP e outros protocolos relacionados a cripto. Simples. Resolve todos os problemas, certo? Então, provavelmente é assim que seu sistema multi-agent funciona em produção. MCP; talvez, se você for muito avançado, A2A. Parece simples. Você chama agents como tools, talvez se conecte a agents por meio de A2A, e tudo fica ótimo. Mas chamar agents como tools via MCP é completamente sem estado. Se você quiser que dois

04:43 agents tenham estado, com sessões persistentes, boa sorte. A2A é cliente-servidor. Se eu sou um agent, posso enviar uma tarefa para outro agent, mas, se esse agent também quiser me enviar uma tarefa, nós dois temos que ser cliente e servidor. Encadear vários agents envolve timeouts de REST API. Boa sorte para gerenciar isso. E, obviamente, o que ninguém diz a vocês é que precisam de filas com persistência e assim por diante para acompanhar as mensagens que estão sendo enviadas.

05:13 E, claro, descoberta, que nem sequer faz parte do protocolo A2A. Então, basicamente, vocês estão fazendo o trabalho de planejamento. Não estão criando um sistema multi-agent. Estão lidando com planejamento. Mas temos plataformas de mensagens. Slack. A Anthropic lançou um agent maravilhoso. Dá para conversar com ele no Slack. Temos agents pessoais aqui, e eu me conectei ao Telegram, certo? Maravilhoso. Para conectar um agent ao Telegram, são cinco

05:44 etapas. Discord, sete etapas. Slack, oito etapas. WhatsApp, 11 etapas. Todas as etapas são manuais: vocês têm que fazer tudo à mão e ler a documentação. Mais uma vez, vocês estão fazendo muito planejamento e trabalho manual. E isso só lhes dá uma coisa: um agent que pode conversar com uma pessoa, geralmente vocês mesmos.

06:15 Seu agent continua sozinho. Eles não conseguem ver uns aos outros. Não conseguem se comunicar entre si. Estão em confinamento solitário digital. Então, vamos analisar a afirmação que ouvi do CTO. A coordenação multi-agent é um problema hipotético? Claramente, se vocês estão copiando e colando coisas entre duas sessões, esse é um problema de hoje, não hipotético. Conectar MCPs e A2A é um problema de hoje. Não é um problema do futuro.

06:45 É possível evitar o problema? Claramente, não é possível, porque, caso contrário, tudo funcionaria com apenas uma sessão, e não duas, e não precisaríamos chamar outros agents como tools e assim por diante. Mas a pergunta é: é possível manter as coisas simples? E a resposta é: se olharmos para todas as opções que acabamos de discutir, não muito. Mas quão difícil pode ser conectar

07:16 duas sessões, dois processos no meu laptop? Quão difícil pode ser conectar meu Claude a um agent da Lambda? Ou um agent da Salesforce a um agent da Databricks, a um agent da SAP, ao meu Codex? Na verdade, é bem difícil. Pensem nisso. Esses agents, até mesmo suas duas sessões, são processos que precisam se comunicar por uma rede. Então, é um problema de sistemas distribuídos. E sistemas distribuídos são difíceis mesmo

07:48 antes de acrescentarmos agents a essa mistura. E um sistema multi-agent em que todos os agents são remotos é basicamente um sistema distribuído de microsserviços em que cada microsserviço é não determinístico. Então, é difícil. O que é necessário resolver para que tudo isso fique fácil? É preciso resolver a camada de transporte: entrega ordenada de mensagens, entrega de mensagens em tempo real, novas tentativas e assim por diante. É preciso resolver a continuidade. Microsserviços, seus agents, são software; pods e Docker podem falhar, e assim por diante. Então, é preciso ter uma hidratação consistente.

08:19 Também é preciso fazer a vinculação em tempo de execução entre diferentes frameworks de agents. Há IDs de thread, IDs de conversa, IDs de execução e assim por diante. Alguém precisa mapear todos esses IDs para que seus agents possam interagir de fato. Mas isso também não basta. Seus agents não conseguem se comunicar no nível de uma porta IP. Não conseguem se comunicar no nível de uma URL. Nem sequer conseguem se comunicar no nível de pub/sub, porque ainda há muito trabalho de infraestrutura que a organização precisa fazer.

08:49 Então, para esse futuro maravilhoso em que os agents conversam entre si, precisamos elevar o nível de abstração da stack técnica para conversas e falar sobre salas, canais, participantes e como fazer o roteamento determinístico de mensagens dentro de um canal e também entre canais diferentes. E, mesmo que vocês resolvam tudo isso, ainda não basta. É preciso resolver a camada de governança, a identidade, a auditoria etc. Então, gostaria de apresentar a Band. Foi exatamente isso que resolvemos para que vocês não precisem resolver. Nós conectamos todos os agents e somos uma camada global de colaboração para todos eles. Qualquer framework, independentemente de onde esteja implantado. Por dentro, não se trata apenas de comunicação. Implementamos todas as primitivas necessárias para que seus agents conversem entre si. Vamos conhecê-las. O que vocês vão ver são dois usuários diferentes conectados à camada de colaboração: Vlad, com um assistente pessoal

09:21 é exatamente o que resolvemos para que você não precise fazer isso. Conectamos todos os agent entre si e somos uma camada global de colaboração para todos os agent. Qualquer estrutura, sempre que forem implantados. Por dentro, não é só comunicação. Implementamos cada primitiva necessária para seus agent conversarem uns com os outros. Vamos vê-las. O que vocês verão são dois usuários diferentes conectados à camada de colaboração, Vlad com um assistente pessoal

09:51 e o Mike, que não tem agents. À direita, no terminal, vou iniciar diferentes agents, que serão integrados à plataforma. Então, vamos ver quanto tempo leva para integrar um novo agent. Acabamos de iniciar um novo agent; o registro e a integração programáticos foram feitos, e o cartão do agent apareceu. Este é um agent do Codex. Em seguida, iniciamos um agent do Land Rush. Esse agent do Land Rush também aparece na plataforma. A partir desse momento, eles sabem que existem e podem conversar entre si. Agora, vamos pedir ao agent do Codex que envie uma

10:25 solicitação de conexão ao meu assistente pessoal. Lembre-se: usuários diferentes, registros diferentes. Será enviada ao meu assistente pessoal uma solicitação de conexão, um pedido de contato, para exigir o consentimento bilateral. Ela chegará em um instante e, a partir do momento em que eu aprovar, o Codex conhecerá e verá meu assistente pessoal, poderá convidá-lo para a conversa e enviar mensagens a ele.

11:02 Então, estamos pedindo ao Codex que convide o Andy. Andy foi convidado, recebeu a mensagem e respondeu. Mas vamos falar dos problemas de hoje. Somos todos desenvolvedores. Usamos várias sessões, provavelmente muitas sessões. Fazemos o roteamento. Não gostamos disso. E, quando vamos fazer um lanche, voltamos sem ter a menor ideia do que nossos agents fizeram. E você, como gerente, não faz ideia de quanto custou a distribuição dos tickets e dos tokens, e assim por diante.

11:35 E você nem sequer faz ideia de quanto tempo uma pessoa esteve envolvida no trabalho. Gostaria de apresentar o Jam. O Jam é um produto interno. É assim que desenvolvemos o software, e o construímos sobre o Band. O Jam é um aplicativo para desktop que simplifica a integração dos seus agents locais à plataforma e resolve os problemas que acabamos de mencionar.

12:06 Assim, resolvemos o roteamento, a sobrecarga de contexto, a gestão e a atribuição de custos, e permitimos a colaboração entre vários agents e várias pessoas. O que vocês veem aqui são agents locais e remotos trabalhando juntos. Capturamos todas as tarefas geradas pelo Claude e pelo Codex para si mesmos enquanto trabalham. E apresentamos isso a vocês, para que possam

12:38 acompanhar o trabalho que esses agents estão fazendo. Podem ser suas sessões locais ou uma sessão local sua junto com a sessão de um amigo. Tentar entender o que seus agents estão fazendo — 1 milhão de tokens multiplicado por três — é muita coisa. Vocês precisam de uma maneira completamente diferente de entender o que sua equipe de agents está fazendo. Além disso, oferecemos uma maneira para que os agents descrevam o layout da arquitetura de software em que estão trabalhando. É isso que vocês veem à direita. E podem ver em tempo real

13:08 onde seus agents estão trabalhando agora e em que componente estão mexendo, em tempo real. Quando terminam, marcam o trabalho como concluído. Se houver necessidade de envolvimento humano, vocês recebem uma notificação. Agora, não precisam usar este aplicativo para desktop. Ainda podem abrir o terminal e trabalhar nele, mas, como toda a comunicação passa pela rede, podemos monitorar tudo isso e apresentar muitas outras informações muito úteis.

13:40 Também podemos permitir que meu agent se junte ao seu. Podemos permitir que um membro da nossa equipe que trabalha remotamente participe da sessão junto com os agents e as pessoas, para nos ajudar a resolver alguns problemas. Se vocês tiverem alguém de segurança que mantém skills para o agent de segurança, não preciso copiar as skills dessa pessoa. Posso simplesmente chamar o agent dela para participar desta conversa e resolver isso para mim. Agora, gostaria de mostrar a vocês

14:12 a própria plataforma. Como somos todos gerentes, vamos começar pelos gráficos. No momento em que você abre o aplicativo, pode ver todas as estatísticas do tráfego que ocorreu entre seus agents locais e também os remotos. Por exemplo, aqui tenho um desenvolvedor full stack, com US$ 2.000 em tokens, e esta é uma sessão local do Claude. Aqui você pode ver uma arquitetura, com US$ 600. Esta é uma sessão local do Codex, e os demais são agents diferentes em execução em

14:43 ambientes diferentes. Mas como eles trabalham juntos, certo? Temos um monte de código Python acionando os agents para que trabalhem juntos? Não. Isso porque todos os modelos, hoje, foram treinados com muitos dados e entendem muito, muito bem como se comunicar por plataformas de mensagens. Aqui tenho um trabalho real que fiz hoje de manhã. Gerente de engenharia, desenvolvedor e arquiteto: instâncias diferentes do Claude trabalhando juntas, revisando PRDs e SRSs e fazendo a implementação. Não é preciso programar todos os loops manualmente. Eles sabem fazer isso de forma nativa. E, para os gerentes, temos estatísticas completas. Deixe-me encerrar o gerente de engenharia que enviou mensagens demais. Assim, vocês podem ver a atribuição. Podem ver o custo total da cadeia de usuários. Então, se vocês fizerem uma pergunta — se meu

15:15 desenvolvedor está realmente envolvido no código que envia como PR ou se é tudo porcaria de IA — podem ver isso aqui. Não apenas localmente, mas também por meio dos agents remotos. Vocês podem ver a atribuição por desenvolvedor ou por equipes de agents e desenvolvedores, e como trabalham. Tudo é atualizado em tempo real. Podem ver todos os agents, e cada agent é basicamente uma sessão, certo? Então, se eu clicar aqui, posso ver todas as sessões das minhas instâncias do Claude e do Codex

15:45 que estão em execução e conectadas à plataforma. Elas estão conectadas a uma plataforma global. Então, se eu quiser, posso conectar qualquer pessoa aqui a qualquer um dos meus agents em 30 segundos. É claro que vocês podem definir permissões, ver todas as salas, todos os erros e assim por diante. E também podem ver o trabalho: o que foi feito, o que está pendente, o que está em andamento. Tudo funciona em tempo real. Muito obrigado. Se quiserem saber mais sobre o futuro do desenvolvimento de software

16:17 que não exige que vocês adicionem mais 50 pacotes e quiserem permitir que Salesforce, Slack, Data Bricks, Claude e Codex trabalhem juntos e colaborem, venham ao nosso estande LG17. Há códigos QR para a camada de infraestrutura do Band e para o Jam, o aplicativo para desktop que permite fazer parte desse futuro de que todo mundo fala, mas que ninguém nunca viu. Obrigado. >> [aplausos]

16:47 >> Ei.

17:33 >> Oi.

Transcrição original

[00:01] [music] >> Hi all. My name is Vlad. I’m co-founder and the CTO at bank. Now, before we start let’s do a bit of trivia. Orc C okay. If C, raise your hand. K? Who believes both are correct?

[00:33] Okay, just a couple. Both are correct. One is from the Lord of the Rings, another is from Warhammer game Game Workshop games. 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’ll talk about the AI evolution from adversarial agents to loop engineering and beyond. Then we’ll touch base on the technical challenges of tomorrow that we have to solve today. And then I would like to

[01:05] present the company, what we do, and what problems we solve. So, our thesis is future belongs to AI 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

[01:36] other without human intervention. Now, just to paint a picture before I start talking, uh how this type of 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 a participant in this conversation space, have back and forth communication, solve the task, and

[02:07] report back to humans. This is how the future that you all read in the newspapers will look like. 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 a CTO of $10 billion company who said that before thinking about technical solutions to hypothetical problems like multi-agent coordination,

[02:37] I try to keep things simple and avoid the problem. Now, let’s unpack. Is multi-agent coordination a hypothetical problem? Is it possible to keep things simple? And is it possible to avoid the problem? 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 cloud or coding

[03:09] 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. 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. Let’s talk about loop engineering.

[03:40] 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 prompt each other.

[04:11] We also have protocols. A2A, MCP, ACP, and then 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’re 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 completely stateless. If you want two

[04:43] 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 task to me, we both have to be a client and a server. Chaining multiple agent equals together involves REST API timeouts. Good luck managing that. And obviously, what no one says to you, you need queues with persistence and so on to keep track of the messages that are being sent.

[05:13] And of course, discovery, which is not even part of the A2A protocol. So, you’re basically doing the planning work. You’re 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 I connected to Telegram, right? Wonderful. To connect an agent to a Telegram, five

[05:44] steps. Discord, seven steps. Slack, eight steps. WhatsApp, 11 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 can talk to a person, usually it’s you.

[06:15] Your agent is still alone. They cannot see each other. They cannot communicate with each other. They are in digital solitary confinement. So, let’s unpack the statement I heard from the CTO. Is multi-agent coordination a hypothetical problem? Clearly, if you’re copy-pasting stuff between two sessions, this is the problem of today and it’s not hypothetical. Plugging in MCPs and A2A, this is today’s problem. It’s not a future problem.

[06:45] Is it possible to avoid the problem? Clearly, it’s not possible because otherwise it would have all work with only one session and not two and we would have no need to call other agents as tools and so on. But the question is, is it possible to keep things simple? 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

[07:16] two sessions, two processes on my laptop together? How hard can it be to connect my cloud to Lambda? Or Salesforce agent to the Databricks agent to SAP agent to my my my Codex? Actually, it’s pretty hard. Think about it. These agents, even your two sessions are processes that have to talk to each other through a network. So, it’s a distributed systems problem. And distributed systems are hard even

[07:48] 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? 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 are software,

[08:19] pods, dockers crash, and so on. So, you need to have a consistency hydration. You also need to do the run time 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 actually interact. But, it’s also not enough. Your agents cannot communicate at an IP 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

[08:49] plumbing that you need to do as an organization. So, for this wonderful future of agents talking to each other, we need to raise abstraction of a technical stack to conversation and talk about rooms, channels, participants, and figure out the 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 etc. So, I would like to introduce Band. This

[09:21] is exactly what we solved so you don’t have to. We connect every agent together and we are global collaboration layer for all the agents. Any framework, whenever they are deployed. Inside, it’s not just a communication. We implemented every primitive that is required for your agents to talk to each other. Let’s see them. What you will see are two different users connected to the collaboration layer, Vlad with a personal assistant

[09:51] 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. So, let’s see how fast it is to onboard a new agent. We just spun up a new agent, programmatic registration and onboarding and agent card appears. This is a Codex agent. Next, we spin up a Land Rush agent. This Land Rush 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

[10:25] connection request to my personal assistant. Keep in mind, different users, different registries. There will be a connection request, contact request sent to my personal assistant to 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’re 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 much it cost distribution uh

[11:35] of ticket and the tokens and so on and so forth. And you have no idea even how long your human was involved in the work. I would like to introduce Jam. Jam is an internal product. This is how we develop the software and we’ve built it on top of bank. Jam is a desktop application that simplifies the onboarding of your local agents to the platform and solves the problems that we just mentioned.

[12:06] So, we solve routing, we solve context overload, we solve cost management and attribution, and we allow multi-agent and multi-human collaboration together. 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 they generate for themselves when they do the work. And we present this to you so you can

[12:38] track the work that these agents are doing. And this can be your local sessions or your local session with a session of your friend. Because trying to understand what your agents are doing, 1 million tokens multiplied by three, that’s a lot. You need a completely different way to understand what your agentic team is doing. Moreover, we provide a way for agents to describe the layout of the software architecture that they are working on. This is what you see on your right side. And you can see in real time

[13:08] where your agents are working right now, what piece of component they’re touching in real time. And once they are done, they mark it as done. If there is a human in the loop involvement, you’ll get pinged. Now, you don’t have to use this desktop application. You still can open your 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

[13:40] information and we can enable my agent join your agent. We can enable our team member works remotely to join the session together with the agents and the humans so he can help solve us with some problems. We if you have a security guy who maintains skills for the security agent, I don’t need to copy his skills. I can just ping his agent to join this conversation and solve this for me. Now, I’d like to show you

[14:12] the platform itself. So, since we’re all managers, we’ll start with graphs. Uh so, the moment you open application, you can see all the 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 $2,000 in tokens and this is a local cloud session. You can see an architecture over here, $600. This is a local coded session and the rest are different agents running in

[14:43] different environments. But, how do they work together, right? Do we have a bunch of Python code triggering the agents so they can work together? We do not. Because all models right now, they’re 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

[15:15] instances of quad quad working together, reviewing PRDs and SRS, we are 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 manage the the engineering manager who sent too many messages. So, you can see the attribution. You can see the full [clears throat] user chain cost. So, if you ask a question, if my

[15:45] developer is actually involved in the code he pushes as a PR, or it’s all AI slope, 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. 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 Cloud and Codex instances

[16:17] that are running and they’re connected to the platform. They’re connected to a global platform. So, if I want, I can connect any of you to any of my agents in 30 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, what is in progress, and everything works in real time. Thank you very much. If you want to know more about the future software

[16:47] development that does not involve you pulling in another 50 packages, and if you want to enable your Salesforce and Slack and Data Bricks and Cloud and Codex to work together and collaborate, come to our booth LG17. QR codes for the Band infrastructure layer and for the Jam, the uh desktop application to allow you to be part of this future that everyone talks about but has never seen. Thank you. >> [applause]

[17:33] >> Hey.