Vlad Luzin, co-founder and CTO of BAND, argues that AI agents should communicate directly with other agents—within companies, between companies, and between businesses and consumers. He describes how users currently act as the router when running agents like Claude and Codex side by side, why a single agent suffers from confirmation bias and attention dilution, and why messaging apps and protocols like MCP and A2A fall short for agent-to-agent work. He frames connecting agents as a distributed systems problem requiring ordered real-time transport, persistence, runtime binding, identity, and observability, then demos BAND's interaction layer with agents onboarding in seconds and Claude Code and Codex collaborating across users. # Channel Presentation Observations: BAND Conference Talk ## Source Scope - **Video:** "Why Your AI Agents Can't Talk to Each Other (Yet) — Vlad Luzin, BAND" - **Available inputs:** Title and transcript only. No curated metadata was supplied. - **Format:** A single conference talk. References such as "this conference," "our booth, LG17," and "demos are recorded" place it in a live event setting. - **Transcription note:** The company name appears as "Bend" throughout the transcript and as "BAND" in the title. This document uses "BAND." --- ## 1. Explicit Self-Description (Creator Claims) These statements are made by the speaker about himself, the company, or the product. ### Speaker Identity > "My name is Vlad. I'm co-founder and CTO at Bend." ### Company and Product Positioning > "Thesis of our company, what we believe believe in." > "This is a global 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." ### Self-Assessed Completeness > "We actually took all the stuff that we talked about and solved it. So, you don't have to solve it." ### Competitive Self-Positioning The speaker contrasts BAND with existing approaches: - **Messaging platforms:** "They are built for humans and they actively block you from connecting a bot to a bot." - **Protocols (MCP, ACP, A2A):** "Protocol is too low-level of a technical abstraction to be able um to build anything on it at scale." - **Google:** "Google have a very huge marketing budget." (The speaker's own framing of a competitor's reach.) --- ## 2. Intended Audience (Observed from Address and Framing) The talk addresses several groups, each signaled by specific language. ### Technical Practitioners - Direct address to those already using AI coding tools: "If you are using Claude or Codex, I'm pretty sure you're running multiple sessions." - Technical depth on transports, retries, persistence, and runtime binding, including terms such as "transport layer," "pub/sub topics," and "LLMs expect ordered messages." ### Enterprise Decision-Makers - Governance framing: "every organization wants governance. They need identity, they need observability." - Scope framing around organizations: "connect all your agents within an enterprise." ### Hands-On Trial Users - Calls to action: "Try it at home. Tell me how it went." - Booth and onboarding invitation: "Come to our booth, LG17. Take screenshots, take QR codes." ### Event Attendees - Playful, crowd-directed engagement: "Okay. Hi everyone. Can you hear me? A lot of people, yeah. So, please be quiet." - Swag giveaway and a light rivalry joke about a competitor (rendered as "Works" in the transcript): "They have stolen all the swag... help us fight them." --- ## 3. Claimed Scope The speaker claims the platform's relevance extends across several domains. ### Thesis-Level Scope > "We believe that the future belongs to AI to AI communication within a business, between businesses, and between consumers and businesses." ### Vision-Level Scope > "Agents will be autonomous, always-on entities spread across the globe." ### Product-Level Scope - Enterprise agent connectivity - Cross-user and cross-organization agent interaction - Human participation: "if you are human, you can still connect and talk to your agent." - Agent-framework coverage named in the talk: "your Hermes and Open Cloak," "a LAN graph to a codex or cloud to a crew AI" --- ## 4. Demonstrated Patterns vs. Asserted Claims Separating what the talk shows from what it only asserts. ### Demonstrated Within the Talk - **Agent onboarding:** Speaker states agent cards appear "seconds later" in a user account. This is shown in a recorded demo. - **Bilateral consent:** A contact request "requires a bilateral consent from both parties," and the speaker reports it was accepted. - **Visibility into conversations:** The speaker states "I have a full visibility into the conversation," tied to the demo of his agent talking to another user's agent. - **Terminal-based agent connection:** A Claude Code terminal session is shown connecting to the platform and inviting another agent into a shared space. ### Asserted but Not Demonstrated in the Transcript - Enterprise governance and identity controls beyond the consent step - Observability of downstream tool calls: "what tool calls... happened after a certain agent received this message" - Persistence and hydration handling: "You need to handle persistency and hydration" - Global, multi-language, multi-environment operation ### Presentation Technique - **Problem-first structure:** The talk moves through thesis, adversarial agents, loop engineering, technical challenges, and then the product. - **Recorded demos:** "the demos are recorded, but we have a booth. Please come and see it live." - **Plain-language analogies:** Comparing the human role to "a Cisco router and a switch moving packets between these two stateful agents." --- ## 5. Limits of This Observation - This is one talk. It does not establish channel-wide patterns, recurring formats, or the creator's broader body of work. - No metadata was provided, so channel name, subscriber context, upload history, and publication details cannot be confirmed. - Claims about product performance and market position are the speaker's own and are not independently verified in the material. # Delivery Observation — Vlad Luzin, BAND ## Tone & Register - **Conversational, conference-patter style.** Opens with direct audience check-in: *"Okay. Hi everyone. Can you hear me? A lot of people, yeah."* - **Frequently playful/mocking rhetorical asides**, often delivered as "right?" tags: > "And you are basically a Cisco router and a switch moving packets between these two stateful agents." > "Forget agents, okay? Deterministic software, it's a pain in the butt." - Uses **jokes and hyperbole to land points**, e.g., the UBI beach line: *"this wonderful future of us... everyone on a universal basic income lying on a beach will not happen."* ## Recurring Phrases & Verbal Tics - **"right?"** — used repeatedly as a rhetorical confirmation device: *"Agents will be autonomous... right?"*, *"Messaging platforms, right?"*, *"single agent bottleneck, right?"* - **"basically"** as a framing word: *"So, basically what is happening..."*, *"Basically, it's the same as the previous concept."* - **"jumping through hoops"** appears twice for friction: *"without you jumping through hoops"* (twice, at [313] and [671]). - **Enumeration habit** — counts as rhetorical proof: *"five steps... seven steps... eight steps. WhatsApp, 11."* - **Contrastive "not X, you're Y" constructions**: *"You're not building a multi-agent system. You're wasting your time on... boring boring stuff."*; *"it's not peer-to-peer, it's multi-peer."* ## Teaching Habits - **Announces structure up front**: *"today I have four topics I want to discuss with you"* — then lists thesis, AI evolution, challenges, product. - **Numbered demos as a teaching device**: *"Demo number one."*, *"So, another example."* - **Explicit mental-model instruction**: *"I want to spend a minute just to paint a picture in your head"*; *"hold this in your head."* - **Distillation framing**: *"I would like to distill it to its essence."* - **Paced summary checkpoints**: *"Now, let's summarize what we know."* followed by three "We know that..." statements. - **Anticipates objections via a voice-of-the-audience**: *"But, smart people will say, 'I know the solution. Protocols, right?'"* ## Vocabulary & Technical Style - **Mixed formal/informal register**: precise technical terms (*transport layer*, *runtime binding*, *persistency and hydration*) alongside casual filler (*"goes kaput"*, *"you have a lot of fun"*). - **Metaphor-heavy explanation**: agents in *"digital solitary confinement"*; the human as a *"Cisco router and a switch."* - **Repetition for emphasis**, sometimes doubled: *"boring boring stuff"*, *"we believe believe in"* (transcript artifact or speech stumble — uncertain which). ## Communication Patterns (Structural) - **Problem-escalation arc**: thesis → current approaches inadequate → harder than it looks → product solves it: *"We actually took all the stuff that we talked about and solved it. So, you don't have to solve it."* - **Audience-directed CTAs recurring at start and end**: *"please come and see it live"*, *"Try it at home. Tell me how it went."*, *"Come to our booth, LG17."* - **Pragmatic time management stated aloud**: *"the time is short, so demos are recorded"*; closing: *"I'm right on time."* ## Isolated Moments (low confidence as patterns) - The closing **swag/ORCA joke** (*"They have stolen all the swag... get a sword, and help us fight them"*) occurs once — playfulClosing humor may be habitual, but one instance is not enough to confirm. - The opening **"please be quiet"** remark is unique; cannot determine whether it reflects a general crowd-management habit. ## Uncertainty Notes - Repetition counts are based on a single transcript; "right?" and "basically" are clearly frequent, but their exact distribution across the talk should not be over-generalized. - Some stumbles (*"believe believe"*, *"how how how"*) may be transcript artifacts rather than reliable delivery features. # Why Your AI Agents Can't Talk to Each Other (Yet) — Observation Record **Speaker:** Vlad, co-founder and CTO at Bend (identified in transcript). **Video:** Conference talk introducing Bend's product, including recorded demos. --- ## Company Thesis (Vlad) - **AI-to-AI communication is the future** — within businesses, between businesses, and between consumers and businesses. Agents doing work on our behalf will need to talk to each other. - **Agents will be autonomous, always-on entities** spread across the globe. - Envisioned future interaction pattern: agents operate in a **conversational space**, see each other, are distributed, receive tasks, look up peers in **registries**, invite peers, delegate tasks, gather information, and report back. --- ## Positions on Current Approaches ### Adversarial Agents - Vlad describes the common pattern (e.g., Claude or Codex users running multiple sessions: one planning, one writing code, another reviewing) as the user acting as "a Cisco router and a switch moving packets between these two stateful agents." ### Loop Engineering - Distilled essence: same as adversarial agents, but the routing is **outsourced to a piece of Python or TypeScript** (often an open-source project) that prompts stateful agents back and forth. ### Why Multiple Agents? The Single Agent Bottleneck - Attributed to **architectural limitations of the transformer**. Reasons cited: confirmation bias, attention dilution, context fragmentation, recall degradation. - Claim: "1 million tokens or 2 million tokens context will not help you in terms of the performance." ### Messaging Platforms — Rejected - Slack, Teams, Discord, WhatsApp, Telegram exist, but onboarding is manual and step-heavy (Telegram: five steps; Discord: seven; Slack: eight; WhatsApp: eleven, per Vlad). - Result gives only **agent-to-person** communication; the agent "cannot talk to any other agent" without "jumping through hoops." - Characterization: agents remain in "digital solitary confinement." ### Protocols (MCP, ACP, A2A) — Rejected as Too Low-Level - **MCP**: stateless calls; you cannot return to the same agent and ask again. - **A2A**: one-way, client-server unless both directions implemented — the same side must be both client and server. - Chaining REST API calls leads to **timeouts**; missing pieces include discovery, draft state of A2A, and queues. - Vlad's judgment: "You're not building a multi-agent system. You're wasting your time on a boring stuff." --- ## Distributed Systems Problem - Connecting remote agents is framed as a **distributed systems problem** — "not easy by definition" even for deterministic software, compounded by agents being non-deterministic microservices. - Requirements enumerated: - **Real-time, ordered transport** (LLMs expect ordered messages), retries, persistence, and hydration (pods can crash). - **Runtime binding**: mapping thread IDs to session IDs, execution IDs, and run IDs across frameworks (LangGraph, Codex, Claude, CrewAI). - Abstraction above IPs/ports/URLs/pub-sub topics: **conversations, participants, channels/rooms, agent-first message routing**. - **Governance**: identity, observability — including visibility into tool calls after a message is received, noted as difficult across distributed systems. - Vlad ties unresolved problems to delayed outcomes: without this, "this wonderful future... everyone on a universal basic income lying on a beach will not happen." --- ## Bend Product Claims (Promotional — presented by the speaker) - Product launched "this week": a **global interaction and collaboration layer** for "any agents, any platform, any language, any environment"; "multi-peer" rather than peer-to-peer; humans can also connect. - Platform features claimed: registry (automatic agent discovery), persistence, channels, message filtering done platform-side, security, observability. - **Demos (recorded, not live)**: zero-hassle agent onboarding with agent cards appearing "seconds later"; cross-user contact requests requiring **bilateral consent**; stateful agents deployed anywhere interacting in real time; human-in-the-loop with full visibility into agent-to-agent conversations; agents creating a website with one reviewing the other's work — described as "loop engineering without 500,000 lines of... Python script code." --- ## Notes on Qualifications - Demos were explicitly **recorded**, with the audience directed to booth LG17 for live viewing — a stated limitation within the talk itself. - Claims about Bend's capabilities are the founder's own promotional assertions from the talk, not independently verified in the transcript. - Humorous closing aside: representatives of "Works" reportedly "do not like orchestration, they do not like collaboration" and took swag — presented jokingly, not as substantive critique. # Attribution Observation: Vlad Luzin, BAND Talk ## 1. Source Overview - **Video ID:** 01a15ca6-e531-7356-8fe8-a05507418bc3 - **Title (as supplied):** "Why Your AI Agents Can't Talk to Each Other (Yet) — Vlad Luzin, BAND" - **Format:** Live conference-style presentation with recorded demos - **Metadata supplied:** Title only. No description, speaker bio, chapter markers, timestamps, or comment data were provided. ## 2. Speakers and Roles ### 2.1 Identified Speaker | Name | Role as Stated | Basis | |---|---|---| | **Vlad** (full name "Vlad Luzin" per title) | **Co-founder and CTO at Bend/BAND** | Self-introduction in transcript ("my name is Vlad. I'm co-founder and CTO at Bend"); surname from title only | - **Speaking role:** Presenter for the entire transcript. Refers to himself as presenting "the company and the product." - **Organizational affiliation:** Bend (transcript) / BAND (title). The spelling discrepancy is unresolved and may reflect transcription error. - **Employer identity:** The speaker says "we" for the company throughout, so statements about "our company" and "our product" are attributed to BAND's team as the speaker frames them. ### 2.2 Unidentified Voices - **Audience member(s):** One brief reply ("A lot of people, yeah") answers the speaker's question about audience size. The speaker is not identified. - **No other speakers** are transcribed as live voices. ### 2.3 Named Figures Appearing in Demo (Not Speakers) - **Mike:** Described as a second user account in a second browser session. Mike does not speak in the transcript. His account is a demo persona operated by the presenter or the demo setup; the transcript does not say which. - **"Me, Vlad":** The presenter's own account in the demo, with a personal assistant agent. ## 3. Referenced Sources and Entities Items are listed as mentioned. None has been verified against external material. ### 3.1 Products and Platforms - **Claude** (and Claude Code, Claude SDK): Used by the speaker and in the demo. - **Codex** (and Codex SDK): Used in the demo; transcribed also as "Equidex" once. - **Slack:** Speaker says "Anthropic released Slack agent." - **Microsoft Teams, Discord, WhatsApp, Telegram:** Named as messaging platforms. - **Hermes** and **"Open Cloak"** (likely OpenClaw, transcription uncertain): Named as agents the platform can connect. - **LangGraph** (transcribed "LAN graph") and **CrewAI** (transcribed "crew AI"): Named as agent frameworks. - **"Landlord":** Appears in demo; identity unclear from transcript. - **Mac:** Named as the machine running the presenter's personal agent. ### 3.2 Protocols and Standards - **MCP** (Model Context Protocol) - **ACP** - **A2A** (agent-to-agent): Speaker attributes marketing to Google. ### 3.3 Other Named Entities - **Works:** Named as an exhibitor or organization with a booth; described as preferring "orchestration" over "collaboration." Its relationship to BAND is not explained in the transcript. - **BAND/Bend:** The presenter's company and product. ### 3.4 Unnamed Sources - **Conference talks and articles** on "loop engineering" are referenced but not identified. - **Open-source Python or TypeScript projects** used for loop orchestration are referenced generically. ## 4. Third-Party and Speaker-Asserted Claims These are claims the speaker attributes to others or presents as background. They are recorded as stated, not as verified. - **Messaging platform setup complexity:** Connecting an agent requires 5 steps (Telegram), 7 (Discord), 8 (Slack), and 11 (WhatsApp). The speaker describes these as manual. - **Platform restriction:** The speaker says messaging platforms "actively block you from connecting a bot to a bot." - **Protocol limitations:** The speaker describes MCP calls as stateless and A2A as one-directional without extra implementation. - **Context scaling:** The speaker says a "1 million tokens or 2 million tokens context will not help you in terms of the performance." - **Architectural claim:** The speaker attributes multi-agent use to a "single agent bottleneck" concept of transformers, citing confirmation bias, attention dilution, context fragmentation, and recall degradation. - **Marketing comparison:** The speaker says "Google have a very huge marketing budget." - **Market outlook:** The speaker predicts agent-to-agent communication will become standard. ## 5. Promotional Content **Flag: this talk is substantially promotional.** - **Product launch:** The speaker states BAND is "launching this week" and describes it as a "global interaction and collaboration layer." - **Live demo framed as sales:** Demo 1 and Demo 2 show the BAND platform. The speaker invites viewers to "try it at home." - **Calls to action:** - Visit **booth LG17**. - Scan **QR codes** to connect agents or access "the future of loop engineering." - Collect **swag**, including a claim that swag is available at the **Works** booth. - **Competitive framing:** The speaker positions BAND against messaging platforms, raw protocols (MCP, A2A), and "orchestration" approaches. The Works segment is comparative and humorous in tone. - **Demos:** The speaker says demos are recorded, so the live demo shown in the transcript may not match a real-time run. ## 6. Provenance and Availability Limits - **Transcript quality:** The transcript appears to be automated. It contains likely errors, including "Bend" vs. "BAND," "LAN graph," "crew AI," "Open Cloak," "Equidex," and "Landlord." Some sentences are fragmented. - **No timestamps:** Segments cannot be located in time. - **No speaker labels beyond self-introduction:** Speaker turns other than the presenter are not labeled. - **No visual channel:** Slides, demo screens, and on-screen text are not in the transcript. Demo claims rely on the speaker's narration. - **No conference name or date:** The talk refers to "this conference" without naming it. - **No comment data:** Comment availability is not provided. - **No independent verification:** Product claims, step counts, and statements about other companies have no external source cited in the transcript. - **Affiliation unresolved:** The title and transcript disagree on the company name, so the official name is uncertain. \>\> 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 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. 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. 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 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 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 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 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, 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. 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 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. 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 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 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 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 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 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 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 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 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 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, 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 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 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 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 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. 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 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 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. 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. 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 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.