Transcription
Hello, my name is. If you have always been interested in neural networks and how they can be applied in business, how new features can be used, which ones are not used, then come to my Telegram channel, I post my latest findings, lectures, life hacks, links, and so on there. This is an exciting time for hardware innovation. At this conference, dedicated to agents, I will talk about the Eljant agent from our lab in Toronto. This agent models a sophomore student in computational chemistry. You can ask it, for example, about the activation energy of caffeine. The agent uses a hierarchy of LLMs organized in a tree structure, where each instance is fine-tuned to perform specific tasks. It calculates molecular geometry, launches computations via Slurm, and processes results to provide answers. Let's discuss the infrastructure needed to run agent models. Deep learning is based on three elements: algorithms, data, and hardware. Algorithms were developed in the 1980s. Data appeared in the early 2000s. The key component was the advent of fast hardware capable of training large models, such as Alexnet, which trained for about 2 weeks on a pair of farm GPUs. Over the past decade, the number of floating-point operations required to train state-of-the-art models has increased 10 million times. Initially, models for image analysis increased threefold per year, but after the publication of the "Attention Is All You Need" paper in 2017, the growth of transformer models accelerated to sixteenfold per year. We, as the primary hardware provider for these models, consider it our duty to improve its performance to meet this demand. This graph illustrates the development of Nvidia hardware over the past 12 years. The Blackwell generation achieved 20,000 equivalent teraoperations per second. Starting from a generation designed for graphics and scientific computing, we have adapted GPUs for AI tasks. Although not created for this, analysis showed AI potential. In subsequent generations, we introduced support for 16-bit operations and dot product instructions, important for deep learning efficiency. The Volta generation further improved performance by adding matrix multiplication. In the Turing generation, we introduced instructions for integer matrix multiplication. The Ampere generation added sparsity, and Hopper introduced FP8 and Blackwell FP4. Performance in the CPU era was based on Moore's Law, and with the end of Dennard Scaling around 2005, it yielded only a threefold improvement from Kepler to Blackwell out of a total increase of 4,000 times. The main performance improvements are related to number representations from FP32 in Kepler to FP4 in Blackwell, which provided a thirty-twofold improvement. The introduction of INT8 to FP8 scaling provided another 16x. These improvements are quadratic because multiplication generates many partial products. Complex instructions also affect performance. For example, fused multiply-add in half precision consumes about 1 picojoule of energy, but loading and decoding requires about 30 picojoules, making the operation inefficient. Using dot products, we reduce overhead from twentyfold to fivefold, and half-precision matrix multiplication reduces it to about 22%. Modern GPUs achieve around 11%, providing a significant efficiency boost. These improvements lead to a cumulative growth of almost 400 times when combining number representation optimization and complex instructions, while the process technology yields only a threefold change, from 28 to 4 nm. The Ampere generation introduced sparsity implementation to double performance, and Blackwell doubles it by combining 2 GPUs. The demand for training models has been met by GPU improvements, and parallelism has provided a 10,000x increase by using more GPUs. This includes splitting training data across multiple GPUs and model parallelism. Thus, training workloads have evolved from using a pair of GPUs for Alexnet to 100,000 GPUs for modern tasks. Software development is required to optimize the utility of the matrix multiplier. In the video, we demonstrate the software stack, starting with CUDA and then Tensor RT for model layer optimization. Vertical domains such as self-driving cars, robotics, and computer vision are also highlighted. Software can improve performance over time, and fine-tuning is important. MLP Perf serves as a reliable benchmark for performance evaluation, showing that even on the same hardware, a 2.5x increase can be achieved through software improvements, emphasizing its quality. When discussing future directions, we explore where energy is directed. Most of it is consumed by mathematical computations, as seen in our NPD research accelerator diagram. For improvement, better number representations and the use of sparsity, both in weights and activations, are needed. Attention must be paid to memory and data movement. It is important to match data representation to the dataset. Many choose to represent the entire range of numbers, which leads to high quantization losses but without fragmentation. Alternatively, narrowing the range reduces quantization but leads to fragmentation, creating a balance to minimize errors. We can achieve the same mean squared error with fewer bits through optimal fragmentation. In terms of LLM inference, there are two phases: pre-processing, which handles the entire prompt with high parallelism, and decoding, which requires reading the entire model for each token, being sensitive to latency and throughput. Different phases require different hardware, considering these differences. Models are constantly evolving, and innovations like Mixture of Experts optimize attention, requiring programmable architectures for adaptation. Deep learning became possible due to hardware improvements, where GPUs provided the necessary impetus for the current AI revolution. Since then, we have progressed through increasingly powerful hardware to train larger models on more data. They require ten times more resources in 10 years, and the performance of a single GPU has increased 1,000 times in 10 years and 4,000 times in 12 years due to number representations and complex operations with minimal role of process technologies. Software is key to efficiently utilizing hardware. I share resource optimization strategies such as optimal fragmentation and vector scaling, considering sparsity. Current challenges include managing split inference and the decoding phase, which load hardware in terms of latency and throughput. Cooperative and tree-of-thought models increase computational and throughput requirements. For example, to infer 100 tokens per second, hardware capable of processing 1,000 tokens per second is needed. We must adapt quickly in a constantly changing landscape with new models and attention techniques. I am a lead engineer at Red Hat. I was previously an engineering lead at Neural Magic, which Red Hat acquired last year. We have been developing VLM for over a year and a half, focusing on performance, engineering, and optimization. I want to discuss the importance of VLM for LM inference, its implementation, and significance for agents. The goal of VLM is simple: to create the fastest and easiest-to-use open-source engine for LM inference and serving. Before diving deeper, it's worth clarifying the problem VLM solves. It targets large data volumes and is designed for use on data center hardware, such as expensive H200 and B200, unlike smaller models for personal laptops. Efficient request management during forward passes at scale is extremely important, as with web servers or databases. We must consider the computational and memory needs of LM inference, especially large caches for long contexts, which agents prefer. LM inference is a complex task as it requires predicting the next token in a sequence. Each request may require multiple forward passes to generate tokens. Efficient batch processing is critical, but static batching is often inefficient due to varying request lengths. Continuous batching allows new requests to be added to the current static batch, optimizing resource utilization. The problem with KV cache. Storing key and value vectors for each token consumes a lot of memory, which can exceed model parameters in large-scale scenarios. VLM introduced Page Attention, based on virtual memory principles. To efficiently manage this, a block table is used, creating the illusion of continuous memory while storing data dispersedly, allowing efficient memory usage when processing requests. VLM has gained significant attention with over 50,000 stars on GitHub and a thousand contributors. This has facilitated optimizations like pre-loading and distributed understanding, supporting over a hundred model architectures, allowing hardware manufacturers to use this abstract software layer. Let's dive in. One of the key optimizations now is automatic prefix caching. This elegant idea stems from page attention, allowing efficient reuse of KV blocks in multi-turn dialogues or in retrieval-augmented generation tasks. This improves time to first token and throughput as cache hit rates increase, also applying to multimodal data. One of the main directions is quantization, known from other projects focusing on weight quantization. We also focus on activation quantization, allowing both weights and activations to be quantized, using lower precision kernels for increased performance and throughput. We compare unquantized models with 4-bit weight-only quantization and 8-bit activation quantization. As requests per second or users increase, we achieve lower latencies and serve more users with these quantization methods. Additionally, KV cache quantization reduces the cache, allowing for more request batching and more efficient inference. The next step is speculative decoding, which involves generating multiple cheap candidate tokens and processing them in parallel in the model to speed up predictions. This approach reduces latency, increases tokens per user per second, and is critical for agents that require fast responses. VLM combines several optimizations to provide cumulative benefits. It includes tensor, pipeline, expert, and data parallelism for various workloads. For example, tensor and pipeline parallelism are suitable for dense models like Lama 405B, while data parallelism is preferred for sparse models. Serving separation allows pre-filling to be separated from the decoding operation. Pre-filling depends on compute power, while decoding is more memory-bound. I hope this overview was helpful. The project has over 1,300 contributors, and I encourage you to check it out on GitHub and join our community. For AI. As enterprises strive to deploy agents across various platforms, data scientists often require multiple large language models and endpoints, leading to significant total cost of ownership. IT departments face complexities in managing security risks and costs. To address budget and complexity challenges, our strategy is to simplify operations within a unified enterprise architecture using open solutions like PostgreSQL with vector databases. We aim to reduce costs and simplify deployment by collaborating with our CIO to create a secure and efficient internal infrastructure for AI systems. I will conclude with a few important non-functional aspects of designing systems in AI. Especially in Nutanix and similar enterprises, three key dimensions are important: people, technology, and processes. While technology is the main focus at this conference and in Silicon Valley, the adoption of AI agents in businesses, such as banks, hospitals, and retail, highlights the need for employee training in working with AI. Autonomous agents will be important in the future, but their widespread adoption is still far off. Current enterprise processes are often rigid. Discussions on multi-agent systems do not consider the practical aspects of their deployment. We need to think about how to demonstrate return on investment. For example, if we invest a million dollars in agents, can we expect a five million dollar return? In regulated industries, IT and legal departments impose restrictions on where and how AI models can be applied, complicating their integration. I often participate in meetings with IT lawyers and AI teams, trying to implement process changes and satisfy all parties. It is necessary to ensure ROI and implement appropriate technologies, focusing not only on hardware but also on people and processes in computer science. This area can be widely applied across these dimensions. Ultimately, multi-agent systems will evolve gradually, requiring careful infrastructure design and management. When creating them, long-term use and maintenance should be considered. With this approach, attention should be paid not only to technology but also to people and processes. We are discussing authorization for generative AI. Azero is an authentication and authorization platform that integrates with applications via API or SDK. We have been in the industry for over 12 years, mainly for developers. With the growing popularity of generative AI applications, we have found important use cases where agent applications need secure access to APIs or data sources. This led to the creation of authorization for Gen AI at zero.comai. We will discuss its significance, show a demonstration, and share resources. A typical generative AI agent application has a user prompt, output generation, LLM output, agent planning, and tool calls to third-party APIs for secure data access, allowing for context-rich responses. Sometimes these applications require human approval for transactions. There are four main requirements for authentication and authorization. The agent must authenticate the user. It needs to call APIs on behalf of the user. For example, a fitness trainer application accessing user data from Google Fit or Strava. Asynchronous interactions for human approval are needed when the agent requires user validation. Authorization models will be needed so that agents only have access to permitted data, such as filtering internal company data. To meet these needs, we created for Geni. I will show how to call APIs on behalf of the user. For detailed documentation and quick start, visit Oto Zeroi.I. We provide integration instructions with services like Google Calendar or GitHub, supporting frameworks like Vercel, Langchain, and others. Now I will talk about the playground I created. After logging in through OT Zero, I enter a chat interface powered by OpenAI. I have linked various third-party applications to this agent application Playground. For example, I can request information about opportunities in Salesforce, where O Zero manages the token for Salesforce access. I will also show connecting Hubspot. After linking accounts, OT Zero redirects me to the Hubspot developer portal to connect the application. There was a small issue during the demonstration, but linking the account was successful. Perhaps the callback URL was misconfigured. After logging into HubSpot, the account was successfully linked to the application. For setup, we configure social connections that allow obtaining tokens on behalf of developers. I have configured a connection with Hubspot and others, such as Google and GitHub. This involves using the authorization URL from HubSpot documentation, specifying token scopes, client ID, and client secret. Enabling token storage allows A0 to manage access and refresh tokens for users. The Playground application uses the Vercel AI SDK with chat, routes, models, and tools. Configuration includes .env files for settings. One of the tools, list HubSpot contacts, retrieves contacts from HubSpot by obtaining an access token from 0, allowing calls to the HubSpot API to get contact or deal details. These connections facilitate user credential requests. Overall, this configuration allows for the creation of agent applications to securely call third-party APIs on behalf of users. All examples and samples are available on GitHub, including various SDKs for different frameworks. For integration with frameworks like NextJS or Fast API, we offer specialized SDKs for AI. Now Christian will demonstrate the setup using our SDKs for Christian Suarez, thank you. We provide specialized SDKs for AI to help developers build agent applications, addressing authentication, API calls, and authorization challenges. The AI SDK offers various tools to simplify these processes and creates unique integrations for a unified authentication system for GenAI. I will show an example similar to what Khan demonstrated, but focused on Google. We are also developing an AI Python SDK to address similar tasks with a unified interface for Llama Index and Langchain. Now I will demonstrate a NextJS application using the AI SDK to check user calendars. We will obtain an access token for this connection. I will briefly cover the installation and initialization of the Vercel AI SDK, which includes A0 for tool requests, allowing specification of scopes for Google API calls and managing token requests seamlessly across various frameworks, including Express and FastAPI for Python. You need a method to get a refresh token for the AutoLay SDK using the Token Bolt function. I will save this file and continue. However, I forgot to install the dependency for the Google Calendar tool, namely Google Apps. We will update this tool to use the newly initialized Autoayi SDK library. I will copy and paste the code, paying attention to the differences. Previously, we called NextJS Autolow to get an access token for the connection. Now, we use a wrapper initialized with the Autoi SDK, directly obtaining the access token. When a user interacts with the Shindig application with requests like events for tomorrow, and it recognizes the need to call this tool, the wrapper checks the user's access level and determines if token exchange is needed. If the user does not have access to Google API, it triggers an interruption. A term we are introducing with Autol AISDK, in line with common API frameworks. This interruption prompts the user to authorize the tool with Google to obtain an access token. Then, we need to update our React NextJS application so it can interpret this error. We have created React components and will install the necessary dependencies. We will update our chat component to handle interruptions returned by AI after tool execution. In the chat component, we import from AI Versel SDK and wrap the chat from Versel AI with a handler to manage error interruptions. Then, we pass this interruption to the message component, which we will also update. We are creating a modal. Ensure API access using Autolayi components to display an authorization modal for the user. Additionally, we need to update our route to return errors from tools, passing the tool and triggering the interruption. After saving the files, we run it. Upon logging into Google, I notice that initially no scopes were requested. Autolis SDK requests permission only when necessary. For example, if I ask if I am free tomorrow at 4:00 PM, the tool will return an interruption asking for access permission. I will select my Google account, review the privacy policy, and grant specific permissions. After authorization, the AI gains access to my Google account, checks availability, and responds accordingly. Thus, we aim to solve four use cases related to user authentication in AI applications. Examples are available in the Outsnall ISDK repository for various integrations. With this, my demonstration concludes, and I hand over to Karen. We simplify user authentication for agent application developers, enabling secure API and third-party calls without token management. The other two use cases we did not demonstrate, but which are documented with SDKs and examples, involve agents needing to asynchronously request user authorization via push notifications or email, as well as authorization for RAG. These are the four use cases we aim to address. If you are developing an agent application for this hackathon and require secure access to KV or AP, visit /I. Check out the documentation and quick starts to address these use cases, as well as the guides and SDK lists that Christian mentioned. Thank you for attending the AGA Summit. I want to introduce you to a new open-source project that is pushing the boundaries of collaborative AI. Its first minimum viable product was released just a week ago. It is a system scaling project with multiple agents working in parallel, sharing intelligence, and improving their results. We draw inspiration from recent breakthroughs like Grok Heavy and Gemini Deep Think. Our goal is to create co-evolving agents through collaboration. Many of you know my Auton framework, created in 2003, which focuses on conversations between agents. However, challenges remain, especially with new technologies. In April, I wrote about misinterpretations of logical reasoning, noting that it is more complex than it appears. We usually think intuitively and then justify our thoughts, which makes clear communication difficult. Collaborative thinking has shown promise at both theoretical and practical levels. For example, Graph's performance on a complex test far surpassed traditional models, demonstrating the advantage of a multi-agent architecture. If you don't have access to expensive subscriptions, good news. With CGEN, you can use any existing API keys for models. You can conduct a multi-agent scaling experiment using a single model with different configurations or multiple models and agents. MASGEN Accelerator distributes user requests among multiple agents working in parallel. The collaboration hub allows agents to share real-time updates, create designs, critique, and refine results. If an agent finishes its work while others update data, it can restart, ensuring consensus and improving quality. Clone the repository, install minimal dependencies, and configure API keys to get started. Use CRI for computations and interact by asking simple questions or engaging in discussions. In a demonstration with three agents, I asked about reports for the 2005 Berkeley Audi Summit. The system started with three agents. One with GPT40, another with 4.0 Mini, and a third with Grok 3 Mini. Some used web search tools. After voting, the 4.0 agent presented the final answer based on the information from all agents. We reviewed the processes, noting how agents used web search and adapted after analyzing each other's responses. You can ask different questions, from finding the winner of AMO 2025 to creating stories or solving complex problems. Numerical experiments show how agent collaboration yields more accurate answers by integrating different perspectives and improving initial responses. Using multiple AIs simulates cross-checking answers for reliability, improving the final outcome. The project is in its early stages of development. Our goal is recursive scaling, adding agents to improve overall performance. Many challenges lie ahead, including achieving consensus, shared context, and interoperability. This introduction is a foundation for further exploration of the project. Visit GitHub, start a discussion, and build together. A new version will be released soon, likely over the weekend. I will try it and leave feedback. Thank you. It seems I still have time for questions. Excellent question. The coding agent is an important capability that I want to integrate into this system. Why is coding important? It's a meta-skill. An agent that can modify its own software is capable of self-improvement, learning, and creating sub-agents. Currently, powerful coding systems like Cloud Code and Gem operate in isolation. Integrating them into a multi-agent paradigm of work will significantly enhance their capabilities. There is a question about how to ensure simultaneous ticket booking by multiple agents without overflow. How can we ensure comprehensive error checking of tasks? This highlights the problem. Since agent work does not always scale easily, although agents are already capable of more than just answering questions, we must ensure they can handle conflicts in the same environment. Thank you for the interesting presentation. Question: If agents generate low-quality examples, how can we prevent this from slowing down overall progress? In the demonstration, two agents initially gave bad answers, only one found the correct one. Each agent must be able to evaluate and consistently recognize the best answers. This assumes that the base models are sufficiently advanced, which also needs to be verified. Good morning, I'm Jay, a developer at NVIDIA specializing in LLM applications. Today, I'm excited to discuss building agent workflows using NVIDIA GPUs. We've had LLMs with single-turn calls for a long time, and in 2024, RAG introduced vector queries for up-to-date information. This year marked the rise of agents, with multiple LLM calls and tool applications creating autonomous processes. The true power lies in agent collaboration within an enterprise ecosystem, leading to challenges like architectural complexity and reliability. To address these issues, we released the NIM Agent Toolkit, designed to integrate existing processes through universal descriptors. It transforms agent tools or memory into function calls, allowing easy integration into various frameworks. For example, imagine enterprises with HR, finance, and IT teams, each using different frameworks. By unifying these agents under the guidance of a super-agent built with graph, we leverage the NIM Agent Toolkit, which is monitored by Phoenix, an observability tool. A GPU-accelerated vector database workflow on MILWUS executes LLM and embedding models on NVIDIA GPUs. To configure workflows, simply modify a YAML file that lists the tools. After a query about parental leave policy, the super-agent identifies it as an HR request and routes it accordingly. Phoenix tracks every step of the interaction. In conclusion, the future of advanced AI lies in multi-agent collaboration, and the NIM Agent Toolkit enables this with real-time GPU acceleration. If you want to learn more about our tools and stay updated, scan the QR code to join the developer program. This workshop is open for questions, as many of you may not need basic knowledge of authentication or AI, but their intersection is important. I want to thank Gus, Winsurf, Claude, and the agents involved in the demo. It is often said that AI will change professions, but we understand that technology evolves, and AI will certainly bring changes. The conversation will be about digital identities and interactions. We all create workshops with tedious instructions and steps. Our goal is to simplify the process by highlighting four key challenges. In our work with tools like GR and Microsoft, we want a more user-friendly experience, not confusing interfaces. With AI, instead of interacting directly with applications, you can use tools like ChatGPT or Gemini to communicate on our behalf. But this creates new access control challenges because agents request actions. We have rebuilt the entire architecture, and in this workshop, we will show how to create a standard structure with a native application and server. I will switch slides and want to understand how many of you want to code along, and who prefers just a demonstration. My architecture includes a frontend application, previously called Stock Trade, now Trade Demo Pro. In it, you can log in, manage your portfolio, and place orders for fictional stocks. For those who want to replicate, the applications and API servers are available on Workshopout101.def my GitHub Simsreck. The server is simple, using Drizzle for standard routes. WN is an API connected to resource servers, as in our theme. We will create a second application for our agent, without tools for now. This is NextJS, written in native. For convenience, I have moved some code into tokt.ts, the entire repository is Terraform so you can create outsnall and run everything immediately without extra steps. First, I will add basic tools for the agent to search and get stock prices. For example, I can ask for the price of Vein stock, but I encountered a bug. I will go directly to the working state and add authentication. Public tools initially allow the agent to call APIs without credentials, but it cannot act on your behalf yet. Many agents work this way, but it's important not to pass access tokens to LLMs or grant too many permissions. This often leads to security issues and leaks. For enhanced security, we recommend delegating authorization and token management outside of tool calls. Outsnoll supports various identity providers and issues user credentials, simplifying the process of obtaining delegated access. The stock application is in a separate account from the agent. We have configured an external identity provider WA so that the agent can securely obtain tokens for the API. Now, when the agent requests the portfolio, it receives an access token that allows it to interact with the stock API with a limited set of permissions. This ensures that the agent cannot access the API without authorization. In practice, if an agent monitors a stock and needs to make trades, suspicious operations may require human approval. This is implemented through different types of permissions, ensuring process security. Overall integration with Token Wol ensures secure token management, preventing credential exposure. As we showed with the portfolio tools example, even if a token expires, AF0 can refresh it, maintaining data security. This approach is also applicable to multi-cloud platforms MCP, where the MCP server can securely delegate actions. This ensures continuous authorization and necessary checks. Apologies for the technical glitches during the demonstration. Let's move on to questions to use time more effectively. If I understood correctly, you have your own MCP server that you want to protect, or an MCP server with a Backend API. If we have an API key, we can program a custom MCP server and store it in a container or in the cloud. But what are the risks there? Are you talking about local or remote MCP? Do you use SDI or HTTP for connection? MCP can connect via a child process or an HTTP request. Running in Docker is different from public environments like mcp.github.com. I have a ber API key that I have written into my MCP server in the cloud for public access. How does the server determine who to grant access to? I believe different roles should be assigned to users, but how does the server identify them? You mentioned that you can give each person a separate container. This is a solution, although it is not managed through OUTOUT. The MCP protocol supports custom transport protocols, allowing for a managed system with isolated containers. In enterprise environments, there are two types of MCP clients: user applications with an Identity Provider, such as Okta or Ager, and third-party clients like VS Code. For both situations, it is recommended to use an internal MCP Gateway, a proxy server that hides access to the main MCP server. If the Identity Provider issues tokens for MCP access, you can restrict third-party clients to only access the MCP Gateway. For example, when an AI like Clod requests access to GRA, its credentials are only valid for the MCP Gateway, which then communicates with Gira. A new standard, OOUT client Client ID metadata, has emerged, allowing agents to register their credentials. This enhances security by controlling which agents can access your resources. You said that credentials should not be shared with anyone, including AI. Are there ways to pass encrypted credentials to an AI agent so that the interacting API can decrypt them? One simple method is to use MCP servers. This is a new technology that requires a secure metadata endpoint according to OO. It hosts a document with trusted subjects and keys, where Jason Webys are stored. This way, you can easily use an encrypted JVT beer token by accessing the public key. Limiting information through MCP is more complex than simply cutting data. For example, if confidential sales figures were shown at a meeting, a salesperson might hide the exact numbers but convey a general positive sentiment, which an AI might interpret differently due to its data-centric nature. When transferring sensitive information between controlled systems, it is advisable to use Jason Web Encryption to prevent leaks. Upon receiving data from MCP, minimizing context is important. You should use tools that reveal minimal information, such as one-way hashes, rather than full profiles. For very sensitive data, such as medical records, it is not advisable to send information to an Infencestack without full control. Different types of sensitive data require different handling. Point authorization, as in Zнbar or FGA, can be considered to restrict access to documents. But hiding information within paragraphs is difficult. When developing tools, do not simply forward API data directly. Since first-tier clients may reveal more information than necessary. New tools should help limit data leakage, but once information is out, it is difficult to get it back. Within a company, for example, Entropic uses an MCP Proxy with an MCP library to securely manage OOO credentials, hiding them from developers. For instance, when connecting to Jira, an internal library helps do this without revealing sensitive details. Platforms that exchange sensitive information using such an architecture work similarly. Zaper connects various services without exposing tokens. Various MCP wrappers exist for managing tokens and API requests, but their development needs attention. For example, ChatGPT or Cloud call APIs, storing access tokens on their servers, which reduces the risk of compromise if a device is lost and simplifies re-authentication. From a security perspective, this approach reduces the attack surface in case of leaks. For example, if an attacker steals a refresh or access token, their actions will differ from normal ChatGPT operation, as the token is stored outside the untrusted client. I apologize for the system issues, but I am ready to discuss topics like Ota and Aft0. We are launching several products, including Toen Wol, which I briefly showed. I would like to talk about the challenges you face when developing applications, especially when agents need to access data or perform important operations, such as stock trading, which requires human consent. The complexities will grow as agents increasingly interact with different software. Currently, there are 79 remote MCP servers and about 6,000 local ones, requiring APIs and keys. By next year, there may be 6,000 remote HTTP servers, expanding the possibilities for service communication. Each MCP server can connect to others and act as an inference client, opening up extensive nesting possibilities. It would be interesting to know if you are developing similar applications and how we can help. That's all I have for today. [music] larang [music]