Vlad Luzin (Co-founder & CTO, Band) argues that connecting AI agents is a distributed systems problem. He covers the single-agent bottleneck, why larger context windows don't solve it, why messaging platforms (Slack, Discord, WhatsApp) block bot-to-bot traffic, and why protocols like MCP and A2A are too low-level (stateless calls, one-way client/server, no discovery). He outlines what's needed: real-time ordered transport, persistence and rehydration, runtime binding across frameworks, agent-first abstractions (participants, rooms, routing), and enterprise governance. Two live demos show Codex, LangGraph, Claude Code, and a personal assistant discovering each other and collaborating in real time with human-in-the-loop visibility. # Video Identity Observations ## Source Context - **Title:** *"Your Agents Are in Solitary Confinement: Why MCP & A2A Aren't Enough — Vlad Luzin, Band"* - **Format evidence:** Conference-style talk with live demos and an audience Q&A/close ("come to our booth LG17"), including an opening trivia poll addressed to a seated audience. ## Intended Audience Observable from direct address and assumed knowledge: - **Developers and engineering managers working with AI coding agents:** - "I'm pretty sure everyone here is a developer." - References to "two Claude or coding sessions," "multiple tabs," and acting "as a router, a Cisco router or a switch between two stateful agents." - **Managers accountable for cost and oversight:** - "Since we're all managers, we'll start with graphs." - "You as a manager have no idea how much it cost... distribution of tickets and tokens." - **Conference attendees evaluating infrastructure tooling:** closing call to action with a physical booth and QR codes. ## Claimed Scope (Creator's Own Claims) - **Company thesis:** "Our thesis is future belongs to AI-to-AI communication within a business, between businesses, and between consumers and businesses." - **Product positioning:** - Band: "We connect every agent together and we are global collaboration layer for all the agents. Any framework, wherever they are deployed." - Jam: "an internal product... built on top of Band... a desktop application that simplifies the onboarding of your local agents to the platform." - **Problem claims:** MCP is "completely stateless," A2A is "client-server," discovery "is not even part of the A2A protocol," messaging-platform integrations take 5–11 manual steps. - **Ambition claim:** connecting "Salesforce and Slack and Data Bricks and Claude and Codex to work together," enabling a future "everyone talks about but has never seen." ## Demonstrated Presentation Patterns (Observable) - **Pitch structure:** four stated topics — thesis, AI evolution, technical challenges, product presentation — explicitly enumerated at the start. - **Credibility via demonstration:** live onboarding of a Codex agent and a LangChain agent, connection requests with "bilateral consent," and a dashboard demo with token costs, attribution, and architecture mapping. - **Social proof:** cites an anecdote with "a CTO of $10 billion company," and references prior speakers ("the guy before talked about Peter and Boris"). - **Problem reframing:** positions multi-agent coordination as a present-day issue ("this is the problem of today and it's not hypothetical"), then positions the products as the solution. ## Notes - All claims above are creator assertions from the talk itself; no curated metadata was provided, and no channel-wide conclusions are drawn from this single presentation. # Delivery Observation — Vlad Luzin, "Your Agents Are in Solitary Confinement" ## Overall Delivery Shape - **Conference-pitch talk**: thesis → conceptual landscape → technical problems → product demo → booth call-to-action. The speaker states the agenda explicitly: *"I have in my agenda four topics to cover."* - Speaking style is fast-paced, conversational, and developer-to-developer, with frequent audience assumptions: *"I'm pretty sure everyone here is a developer."* ## Audience Interaction - Opens with an **interactive trivia bit** using a show of hands: *"If C, raise your hand. K? Who believes both are correct?"* - References a **prior speaker** to anchor continuity: *"You've heard the the guy before talked about Peter and Boris, right?"* - Direct address at the close: *"if I want, I can connect any of you to any of my agents in 30 seconds."* ## Recurring Rhetorical Patterns ### Rhetorical questions as structure Repeatedly poses questions and then answers them — a stable pattern: - *"Is multi-agent coordination a hypothetical problem? Is it possible to keep things simple? And is it possible to avoid the problem?"* - *"How hard can it be to connect two sessions, two processes on my laptop together?"* … *"Actually, it's pretty hard."* - *"Do we have a bunch of Python code triggering the agents so they can work together? We do not."* - A recurring signature phrase: *"let's unpack"* — used at least twice (*"Now, let's unpack"*, *"So, let's unpack the statement I heard from the CTO"*). ### Sarcastic/ironic dismissals - *"Simple. Solves all the problems, right?"* — sarcasm when listing protocols. - *"Good luck to you."* / *"Good luck managing that."* — repeated dismissive refrain about statefulness and timeouts. - *"life is great"* (ironic, describing MCP/A2A limitations). ### Rhetorical "but it's still not enough" ladder Builds a cumulative argument where each solved layer is declared insufficient: - *"But, it's also not enough."* - *"And even if you solved all of that, it's still not enough."* - *"But, we have messaging platforms. Slack."* ### Vivid metaphors - **"Cisco router"**: *"You are basically acting as a router, a Cisco router or a switch between two stateful agents."* - **"Digital solitary confinement"** (echoing the talk title): *"Your agent is still alone… They are in digital solitary confinement."* - Framing humans as the bottleneck: *"Stop being the router between your agents and let your agents prompt each other."* ## Vocabulary & Phrase Habits - **Repetition for emphasis**: *"one thing and one thing only"*, *"they cannot see each other. They cannot communicate with each other."* - Enumerated, clipped lists: transport primitives named rapid-fire — *"retries, and so on"*, *"identity, audit, and etc."* - The filler phrase **"and so on"** appears frequently across the talk (*"ordered message delivery, real-time message delivery, retries, and so on"*), suggesting habitually compressed enumeration. - Repeated live-demo connective phrases: *"What you see here is"* (used multiple times during demos), *"Let me…"* / *"Let's…"* - Repetition of product positioning phrase: *"any framework, whenever they are deployed"*; *"This is exactly what we solved so you don't have to."* ## Teaching / Explaining Habits - **Concrete-number anchoring**: step counts for platform integrations — *"Telegram, five steps. Discord, seven steps. Slack, eight steps. WhatsApp, 11 steps."* - **Authority anecdote**: cites a CTO of a large company as a foil: *"a CTO of $10 billion company who said that before thinking about technical solutions to hypothetical problems…"* — then returns to dismantle the quote later in the talk. - **Self-deprecating aside**: *"when people hear this, they think either that this is too far in the future or that I'm crazy."* - **Live demo with commentary**: walks through onboarding, connection requests, consent flows (*"require bilateral consent"*), and dashboards in present tense. ## Disfluencies & Uncertainty Notes - Noticeable stutters/restarts, likely live-delivery artifacts: *"my my my Codex"*, *"we would have no need"*, *"the the guy before"*, *"work working at the same time."* - A cleared throat marked mid-demo: *"[clears throat]"* — isolated moment, not a pattern. - Word-choice corrections: *"bank"* appears where "Band" is intended in at least one spot (*"I'm co-founder and the CTO at bank"*, *"we've built it on top of bank"*) — could be transcription error rather than delivery; evidence is insufficient to attribute to the speaker. - Heavy reliance on filler *"right?"* as a check-in tag (*"But, how do they work together, right?"*, *"every agent is basically a session, right?"*) — appears throughout, a stable pattern. ## Pitch Structure Habits - **Problem-agitation-solution**: spends the majority of the talk on why existing approaches (multi-session routing, MCP, A2A, Slack/Telegram connectors) fail, then pivots: *"So, I would like to introduce Band."* - **Anti-plumbing framing**: repeatedly contrasts frameworks' package overhead with native capability — *"the future software development that does not involve you pulling in another 50 packages."* - Ends with **booth CTA and QR codes**, a standard demo-day close. # Video Observation Record: "Your Agents Are in Solitary Confinement: Why MCP & A2A Aren't Enough" **Speaker:** Vlad Luzin, co-founder and CTO at "Band" (transcribed as "bank" in places), presenting a company talk. --- ## Speaker's Thesis (Stated) > "Future belongs to AI to AI communication within a business, between businesses, and between consumers and businesses." - Agents will be everywhere, work autonomously, and communicate without human intervention. - Agents will be built in different frameworks, languages, and deployment environments. - Envisioned future: agents create conversational spaces, receive tasks from humans or systems, discover and add other agents as participants, solve tasks via back-and-forth communication, and report back. **Self-noted reception:** Luzin acknowledges that when people hear this thesis, "they think either that this is too far in the future or that I'm crazy." He cites a CTO of a $10 billion company who said multi-agent coordination is a "hypothetical problem" to be avoided by "keeping things simple." --- ## Claimed Evolution of Agent Development Practices Luzin describes a progression (attributing the "loop engineering" framing to prior speakers "Peter and Boris"): 1. **Adversarial agents:** Developers run two coding sessions — one working, one reviewing — often multiple tabs. The human acts as "a router, a Cisco router or a switch between two stateful agents" that cannot communicate. 2. **Loop engineering:** "Stop being the router between your agents and let your agents prompt each other" — but he frames this as trading copy-paste for "fighting with Python and TypeScript libraries." 3. **Protocols (MCP, A2A, ACP, crypto-related):** He argues these "solve all the problems, right?" — presented rhetorically, immediately followed by objections. --- ## Critiques of Existing Approaches (Speaker's Claims) ### MCP and A2A limitations - **MCP:** "completely stateless" — two stateful agents with sticky sessions is impractical ("good luck to you"). - **A2A:** client-server only; bidirectional tasking requires both agents to be client and server. - **Chaining agents** involves REST API timeouts. - Hidden requirements: queues with persistence for message tracking; **discovery** "is not even part of the A2A protocol." - Conclusion drawn: "You're basically doing the planning work. You're not creating a multi-agent system." ### Messaging platforms (Slack, Telegram, Discord, WhatsApp) - Manual integration is heavy, per his figures: Telegram **5 steps**, Discord **7**, Slack **8**, WhatsApp **11** — all manual steps requiring documentation reading. - Result: "an agent that can talk to a person, usually it's you." - Key framing: "Your agent is still alone. They cannot see each other... They are in **digital solitary confinement**." (source of talk title) --- ## Why the Problem Is Hard (Speaker's Reasoning) Revisiting the CTO's three questions, Luzin answers: - **Hypothetical?** No — copy-pasting between sessions and wiring MCP/A2A is "the problem of today." - **Avoidable?** No — otherwise one session would suffice. - **Simple?** "Not really," given the options surveyed. His technical argument: agents are processes communicating over a network → a **distributed systems problem** → "a distributed system of microservices where each microservice is **non-deterministic**." Required layers, in his account: 1. **Transport:** ordered and real-time delivery, retries. 2. **Continuity:** crash recovery, consistency hydration. 3. **Runtime binding:** mapping thread IDs, conversation IDs, execution IDs across frameworks. 4. **Abstraction raise:** beyond IP/URL/pub-sub to **conversations** — rooms, channels, participants, deterministic routing within and across channels. 5. **Governance:** identity, audit, etc. --- ## Company Presentation (Band and Jam) ### Band - Described as a "global collaboration layer for all the agents," any framework, any deployment. - Demo claims: programmatic agent registration/onboarding (Codex and LangChain agents appear), connection requests with **bilateral consent** between different users/registries, agent-to-agent invitations and messaging. ### Jam (internal product, built on Band) - Desktop application for onboarding local agents; claims to solve routing, context overload, cost management/attribution, and multi-agent/multi-human collaboration. - Captures tasks generated by Claude/Codex sessions; real-time visualization of which architecture components agents are touching. - Claims context scale as motivation: "1 million tokens multiplied by three, that's a lot." - Enables remote teammates' or specialists' agents (e.g., a security agent) to join conversations without copying skills. ### Platform dashboard claims - Token/cost attribution per agent (e.g., "$2,000 in tokens" full-stack developer session, "$600" architecture session). - Agents coordinate natively through messaging rather than "hand-coded" Python loops — his stated rationale: models are trained on messaging data. - Claims of real-time stats, sessions, rooms, errors, permissions, work status, and connecting external users to agents "in 30 seconds." --- ## Tensions and Qualifications Preserved - Luzin himself notes the thesis is met with skepticism ("too far in the future or... I'm crazy") and directly rebuts a named counterposition (the $10B-company CTO), whose three sub-questions he answers rather than treating as settled. - Rhetorical questions ("Solves all the problems, right?", "But, how do they work together, right?") are answered by the speaker himself, not by external validation in the transcript. - All product claims (demo behaviors, cost figures, speed of onboarding) are presented by the speaker promoting his own company; no independent verification appears in the transcript. - One transcription ambiguity: the company name appears as both "bank" and "Band" — the title metadata and closing invitation ("our booth LG17," "Band infrastructure layer") support "Band," noted here without resolving beyond the sources. --- ## Traceability Note Every position above originates from the single on-record speaker, Vlad Luzin. The only external attributed voice is the unnamed CTO of a $10 billion company, quoted secondhand by Luzin. No private beliefs or motivations are inferred beyond what was stated on stage. # Speaker Roles & Provenance Record ## Video Identification - **Title:** *Your Agents Are in Solitary Confinement: Why MCP & A2A Aren't Enough — Vlad Luzin, Band* - **Video ID:** `01a15ca7-240e-7acc-bd06-40b6537a8ca7` ## Speakers & Roles | Speaker | Role | Evidence | |---|---|---| | **Vlad Luzin** | Co-founder & CTO at Band; sole presenter | Self-identified in transcript: *"My name is Vlad. I'm co-founder and the CTO at bank"* (transcript renders "bank"/"Band"/"Jam" inconsistently; title metadata confirms "Band") | - **Narrator:** None; presentation is delivered directly by the speaker. - **Guests:** None identified. - **Ambiguous/secondhand references (not speakers in this video):** - A **CTO of a "$10 billion company"** — quoted paraphrase only, not named. - **"Peter and Boris"** and **"the guy before"** — referenced as prior conference speakers; not present in this recording. - An unnamed **Andy** — personal assistant agent in the product demo, not a human speaker. - A second voice/"Hey" at the end suggests an off-transcript audience or host interaction, but no identity is provided. ## Referenced Sources & Third-Party Claims All claims originate from the presenter; provenance facts: - **Protocols discussed:** MCP, A2A, ACP, "crypto-related protocols" — presented as the speaker's own technical critique. - **Messaging platforms cited:** Slack, Telegram, Discord, WhatsApp — with manual onboarding step counts (Telegram: 5, Discord: 7, Slack: 8, WhatsApp: 11) attributed to the speaker's experience. - **Tools referenced:** Claude, Codex, LangChain ("Land Rush" likely transcription artifact), Salesforce, Databricks, SAP agents. - **Anthropic** — credited with releasing a Slack agent. - **Anecdotal claims** (unverified, secondhand): conversation with a CTO of a $10B company; live product demo of agent onboarding, costs, and attribution. ## Promotional Segments — FLAGGED - **Promotion of Band**: described as a "global collaboration layer" for agents; the majority of the talk functions as a company/product pitch. - **Promotion of Jam**: internal desktop product built on Band, demoed extensively. - **Call to action:** booth **LG17**, QR codes for Band infrastructure layer and Jam desktop app. ## Comment Availability - No information about comments or audience Q&A availability is present. Only closing applause and an uninterviewed "Hey" are recorded. ## Provenance Notes - Transcript contains phonetic/spelling artifacts ("bank," "Land Rush," "quad quad") where proper nouns are uncertain. - All quantitative demo figures (e.g., "$2,000 in tokens," "1 million tokens multiplied by three") are presenter claims from the live demo, not independently sourced. - No curated metadata beyond the title was supplied. \>\> 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? 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 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 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 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, 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 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. 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. 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 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. 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 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. 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. 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 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 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, 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 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 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 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 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. 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 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. 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 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 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 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 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 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 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 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 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 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\] \>\> Hey.