Transcription
Hello everyone. This is Anton Morev. And today I would like to tell you about the theoretical part of how our work with creating MCP servers happens. Well, rather, we create our own AI agents that use MCP servers under the hood. I have been working on this topic for a long time, I have launched a lot of agents for myself and for our clients. And I have formed a certain picture in my head about how this can work in cloud, uh, GPTs, and, well, similar systems locally on my own graphics cards, since we have launched both types. I will give a brief overview of how this can be done, and first I will give a large theoretical explanation of how it works under the hood in principle. Who is an AI agent? When I was a child and watched the movie Iron Man, I was filled with some kind of wild delight. What I saw in the context of an AI agent. It's Tony Stark's personal assistant, Jarvis, with whom he talks by voice and says things like: "I don't know, Jarvis, assemble the suit, Jarvis, do this, do that." And Jarvis understood him and obediently carried it out. It really filled me with delight then. I thought, damn, I want that too. It was eighth grade, I was, well, 13-14 years old. As a result, when I, well, got older in university, I started trying to make my own AI agents based on Google's Speech Recognition. And in the end, well, it wasn't artificial intelligence at all. This is, in principle, a small lyrical digression, which, well, just kind of makes it clear that I have been interested in this for quite a long time. But let's not talk about AI agents now. Let's first go back a couple of steps, how artificial intelligence itself works. Disclaimer: this will be a very simplified form. This is not theoretical information from books. That is, this is not something to consider for a future diploma thesis. That is, do not rely on this. I am explaining in simple terms to people who may have some basic understanding of mathematics. Let's return to mathematics. Let's recall mathematics, seventh, eighth grade, when we used to draw these beautiful graphs. We have the X-axis, the Y-axis. And on this graph, we plot X². This is a parabola. Everyone perfectly understands how it works. That is, we know that for point one, it's one, for point two, it's four. And these curved lines diverge in different directions. This is simply f(x) = x². Let's now think differently. Let's imagine that we have some kind of graph. Well, for example, let's write the graph 2x + 5, which looks something like this. From the number 5 on the Y-axis, a line emerges with a slope of 2 upwards and to the right. And let's try to assume that this function is unknown to us. We don't know what specific sequence of numbers and digits should occur in the format of a formula for which x corresponds to which y. That is, we don't know this, but we have been given a task, we have to guess. We only know that there is some kind of function of the form ax + b. And we need to figure out what a is and what b is. Well, let's try to go this way. We choose a = 1, b = 2. A small digression. I am now explaining how a neural network works under the hood, only based on a very basic, simple example. Well, let's say, a = 1, b = 2. We draw the line and see that it is, to put it mildly, completely different from what we would like to get. We calculate the quadratic deviations. That is, we calculate how exactly at each point it deviates from our target function, we understand, we build a function of this deviation construction, and we look for the minimum and try to minimize this deviation. That is, some transformations happen under the hood. Using derivatives and integrals, we understand that, well, the next values of one and a half and three will bring us closer to our goal. We draw the next line and see that, oh, okay, it has visually become closer. We calculate the mathematical deviations, again, we minimize them in the same way. And as a result, we gradually, gradually, gradually, gradually arrive at the point where our function becomes as similar as possible to what we initially want to get. Now let's imagine that this function might not be a small function with one parameter x, but our speech, text speech. That is, "Hello, how are you?" Only it will be a function with billions of parameters, not just one. That is, these are precisely those billions of parameters by which we have recently become accustomed to measuring the genius of our neural network. And we want to choose these parameters and continue this function. That is, "Hello, how are you?" to continue in the form of a similar line that will contain "Well, and how are you?" as we usually reply. That is, if we send such a request to ChatGPT now, we will see a similar dialogue. That is, we ask how it is, it says: "Everything is great, thank you, how are you?" That is, specifically under the hood, the following happens: text is converted into tokens or vector, well, vector representations. Then this vector representation is essentially just extended under the hood. That is, well, under the hood, text is converted into tokens, tokens, vector representations. That is, well, we translate our text into such a line, only it is not two-dimensional, not three-dimensional, we cannot visualize it, it is multi-billion dimensional. That is, it is a space that is very, well, difficult to imagine, but for a computer, it is not a problem to imagine and not a problem to extend it. And as a result, it extends it. If we talk about representation in vector form, it is called building embeddings. A difficult word. I, well, my diction sometimes has problems when I pronounce this word. But precisely, different models, probably all these cloud-based ChatGPTs, GigaChat, and Gemнай or Gem, I don't know how to pronounce it correctly, they have, well, the ability to create an embedding for their text. That is, it shares how it vectorizes the text that comes to you. Then, for example, these embeddings can be used for a vector database, so that you can search for information within your database by meaning. And as a result, we get that, and let's forget about AI agents for now - it's something that turns the content that comes in into the content that goes out. The content can be text, images, I don't know, just a set of bytes and bits. If the neural network was previously trained to interpret this information and process it, then it will process it. That is, if it gets an image from an image or text from text, it doesn't matter. That is, its main task is to continue the content. And as a result, if we are talking about AI and AI agents, it is something where you can build a dialogue in such a way. I write some text as input, and it gives me some text as output, which it considers most suitable for the question or for the text that I wrote to it. I don't know, if we take the simplest AI, it's your T9 on your phone, when you write, well, messages on your phone, it suggests that, for example, "Hello," and it immediately, I don't know, puts the next punctuation mark and writes "how are you?" That is, it simply understands that you have written "Hello, how are you?" ten times before. But it suggests that you immediately write it yourself. In the same way, artificial intelligence, well, helps you, extends your text. Now let's return to our Tony Stark, his Jarvis. Who is an AI agent? How does an AI agent differ from artificial intelligence? This is what I beautifully crossed out. Let's remove this crossing out. Let's now imagine that I tell him in text format: "Buddy, I'm going to throw text at you, and you need to extract tasks from it, but only write JSON." And here, yes, the screenshot says that I'm sending him: "Write a report for the last week, consider payment details." And it even gives JSON, which has task details, and you could say it works. An AI agent is launched. We can pass this mechanism, this prompt, to our system, which will send this request directly to ChatGPT or any other GPT system. And this GPT system will give us JSON, which our system will parse. In short, it already looks like it can work. And we, as it were, recall this story with the graph, we tell him that, dude, if anything, when continuing this graph, create JSON where it is appropriate, and where it is not appropriate, then not JSON. And as a result, we say to create tasks. It continues this text in the format that here we have a task, it has a title. And if we want to say who an agent is, it's someone with whom you can have a dialogue in the format of asking for something to be done. It then receives this request, interprets it somehow, understands if it has enough information to process the request. That is, if it understands that I am asking it, I don't know, to create a new user in the database, then it understands that it doesn't have enough information, it wants, for example, me to tell it the user's name, their year of birth, then it will find out this information further, that is, it writes text messages to our person, that is, to me or another user. That is, "Buddy, what do you want to name this user?" Or any other question that would be appropriate in the context of the task we set. If it has enough information, then it passes the task to another system. Like, "Dude, here, please, run this command." And as a result, our system begins to implement this command. And in our graph, where we were drawing how we communicate with AI, we still have me, artificial intelligence, and we communicate with it. Only now we have a third participant - the system, let's call it. This is something to which the AI agent can pass some useful information. For example, "Do something." And this system does something, some specific task related to the external world. And then the AI says: "User, buddy, your task has been completed." I don't know, the user was added, everything was done well, we are all great here. How does an AI agent differ from ordinary artificial intelligence? With each request, we tell the agent that in principle it can instruct our system to do things. If there is enough information in the context, it performs the task. If something is missing, then a request is generated, like, "Dude, give me more information." And, well, then we find out what the user wants in the form of a dialogue. And then we can implement it. We can have a direct dialogue, we can ask it to create a new user, then extract the logs that were in the context of this user creation, and see, for example, how much space we have left after creating the user. Just an example from the top of my head. What are the ways to implement AI agents? There are different tools. Over the course of artificial intelligence development, there was a sharp jump since 2022, there have been different methods. And, well, I will share them with you now. First is to specify the format. That is, we write: "Dude, please, respond in JSON, and nothing else, don't respond at all, so that I can parse this JSON." And sometimes artifacts like this came out: "Of course, here is your JSON, please take it. Only if we give this string to our parser, our parser will break." Simply because this "Of course, here is your JSON" is not acceptable. Of course, you can generate it several times, spend tokens until it gives exactly JSON. The next method is intimidation. We can say even more: "Dude, you will be fired, we will delete all your code, delete the entire database, delete your model, if you don't give us JSON." But in the end, it says: "Yes, okay, I got scared. Here is your JSON." Well, that is, we are faced with the problem that it is still a text model that scientifically produces text. Yes, we can give it various restrictions, but it is a little similar to a person in this regard. It can still interpret it in its own way. Well. The next method is structured output. This is when, along with the text, we also specify the format, the structure of the response, what we expect from it. That is, what fields, what should be there, and nothing else. As a result, yes, we get our agent behavior, that we are guaranteed to receive the same JSON that we would like to get, but it has a small drawback, that we ultimately have to build the entire dialogue in this format. We get extra tokens, because we need to understand that artificial intelligence has interpreted and given us some task, or is it still finding out something else? That is, we will have to invent some kind of custom structure in order to maintain communication and to be able to receive tasks from artificial intelligence. And the next option is tool calling or function calling. They are called differently in different GPT system providers. This is precisely the way to combine both and get an excellent result. We write ordinary text, that is, just as ordinary as we wrote before. And next to each request, we pass an array of tools that can be called. That is, well, for example, as in the example on the screen, we can build a graph and say that, buddy, if the person sends you the task: "Build a graph of such and such a function," then pass, as a separate array, as tools to be called, the function itself to be called. And the fact that the function needs to be called. It is clear that this sounds a bit redundant, but the meaning is as follows. The agent will now respond to us along with the ordinary text, as well as the tools that need to be called on our system's side. If we compare structured output and function calling, then function calling has many advantages that make structured output simply useless for agent tasks. Structured output is convenient where we want something specific, just one thing, and absolutely nothing else. That is, we want to call artificial intelligence with certain parameters and get those parameters as output. Yes, this situation might be more suitable, but personally, in my practice, I have stopped at the point where we use function calling everywhere. And structured output is used by us only in tasks like parsing an image and extracting, for example, the calorie content of a dish from the image. Well, just as an experiment, I did it. In this case, functions are not suitable, because, well, we don't need different interpretations of what we want. We need everything to be specific. We gave the image as input, and we want JSON with the calorie, protein, fat, and carbohydrate content of the dish we prepared as output. Here, yes, structured output is suitable. But if we are talking about agent tasks, where we want to talk to AI and want it to extract something from it, then, of course, function calling comes into play here. Before we move on to MCP servers and generally to all implementations of these AI agents, I wanted to discuss a few misconceptions that arise in people's minds, including in my mind when I first encountered the mechanics of AI agents. The first misconception is that artificial intelligence does everything itself. That is, I assumed that it would be something like this. There is me, there is my laptop, from which I give some commands. The laptop then sends this request directly to our LLM system. And the system under the hood somehow smartly, wisely makes a request to an external service. This external service somehow processes all this, gives an answer back to the LLM. The LLM perceives this, understands what was wanted, what the person wanted, what the system did, and then answers the person, like, yes, your entire task has been completed. But then I had a perfectly reasonable question: how does this happen, considering that the models themselves are trained to, well, live within themselves? That is, specifically, input content is given, output content is received. And in the end, it turned out that it works a little differently. Let's consider an example of creating a user named Vasya, whom we want to add to our system. We tell our computer, well, a laptop is a phone, it doesn't matter, anything, that, buddy, we need to add user Vasya. This computer, under the hood, forms a request to the LLM, which will contain our text request "create user Vasya." And next to it, there will be a list of tools, among which there is a tool for creating a user, for which, for example, name and year of birth are needed. Then all this information goes to the LLM. The LLM sees that in our text request there is the name Vasya, but not a word about age. The LLM gives a text response. It doesn't yet tell our computer to call any commands, but it directly transmits the text response to the person through the computer. "Okay, I understood about Vasya, but I didn't understand about the year of birth. Please tell me, what is the year of birth?" Then the person says, for example, the year of birth is ninety-four. This information, along with the entire conversation history. That is, another request is sent to our LLM system, which contains this old conversation, that "creating user Vasya, LLM replied okay, created, year of birth." And we pass it again. Now we pass the information about user Vasya, about the year of birth. And again, the list of all functions that we can, in principle, call. We pass it. And then the system under the hood understands: "Okay, we received the year, we received the name, we have the name, we have the age, we can create it." It gives the computer, well, or server, information that, buddy, now we need to create user Vasya of such and such a year of birth. As a result, after this, we created everything. The computer sends further information to the LLM and says: "Yes, I created it, everything is fine." And the LLM writes, like, "user created," and we thank it directly for that. That is, it works a little differently, right? As you understood, there is a third participant, there is me, there is the LLM, and there is the system between us, which directly executes commands from the LLM, and the LLM only tries to interpret them and give commands for execution. The next misconception is that agents are just some cool LLM with some cool prompt. Well, we've already talked about this at the stage when I was talking about JSON. Well, let's discuss a small block on the topic of creating, say, tea. We tell our AI agent: "Make tea," like Tony Stark in Iron Man. The information comes to our LLM. And, for example, we set up such a prompt: if I ask you to make tea, then make tea. If not, then don't make tea. And as a result, well, our message comes, and this additional prompt, and then artificial intelligence under the hood understands that, okay, I need to make tea, I'm going to make tea. That is, in general, this could have been done in the form of some long, long prompt, where we describe everything approximately the same. But as I said earlier, artificial intelligence has its own artifacts. It can interpret different tasks in its own way. And as a result, it turns out to be a system that cannot work stably. And if it's a system that cannot work stably, then it's not a system that can be relied upon and for which you can ultimately get money. Therefore, agents are not just prompts, they are a whole system built on correct requests and prompts. And also the use of tool calling or function calling. These are synonyms, just called differently by different providers. Next misconception is that the LLM itself decides when and how to call tools. On the one hand, yes, let's return to our example, tea, but not entirely, because we can have several subspaces, that is, we can throw in a block of tasks related to tea, a block of tasks related to the user database. And as a result, the LLM may not know that the system can generally perform some function if we don't specifically tell the LLM about it. That is, we need to pass absolutely all possible tasks that the LLM can currently interpret in absolutely every request. Because we can throw in: "Make tea," and under the hood, we can throw in options for tasks, only like "add user" or "delete log from our database." Well, that's approximately it. And then the LLM itself cannot decide anything. And the next misconception is that the LLM remembers the entire context like a database. If we communicate with it incorrectly, if we write to the LLM, for example, again our example about this Vasya. "Create user Vasya." It's "Okay. What year of birth?" And we simply write "94th year." And if we don't pass the entire conversation history, which needs to be passed with all the called functions, with all the functions that need to be called, which can be called, in short, the context develops, tokens accumulate, and the cost increases. If we don't send it the entire history, then it will say, like, "What are you talking about?" Like, "What? Why? Why are you sending me the ninety-fourth year? I don't know at all what we were talking about before, so, well, here's the ninety-fourth year for you. I can't do anything more with it." The next misconception is that tool calling is something like plugins in ChatGPT that allow ChatGPT to be smarter and cooler. This misconception is formed against the background that there is also Google's or Anthropic's, I don't remember, Google's Gemini, which can connect to MCP under the hood, and it looks like it's just some kind of add-on, some plugin working with our neural network. And sometimes this is confused with the Open GPTs product, where you can pre-configure, based on a pre-made prompt, add a couple of buttons, and you can really create some kind of smart assistant for yourself that will interact with you a bit smarter, but in reality, no. It's not like that. Open GPTs is just another product that can use MCP servers under the hood. It might be implemented as an AI agent, but it's not something we took and developed ourselves, it's just a ready-made product that, depending on how it's configured, how it's implemented, can be used. The next misconception is that MCP makes LLMs smarter. And now we finally get to the MCP servers themselves in order to dispel this myth that MCP makes them smarter. Where does this myth come from? Well, why did it arise in my mind? Because if we open YouTube or any other social network where video content is made, we see that a lot of people, a lot of bloggers, write about AI, make videos like: "This MCP will make a very cool, powerful personal AI agent for you." It will upgrade your AI and so on, create your smart assistant in a couple of minutes, a couple of clicks, using MCP servers. Around March of this year, MCP technology appeared, which stirred up people who try to make money on this content. And as a result, we have, well, a slightly incorrect understanding. Let's now move on to what MCP is. MCP is Model Context Protocol. It is, I believe, the developers who created their own neural network, they came to the conclusion that, guys, why are we reinventing the wheel every time? Why does everyone come up with their own way to make calls to external systems? Why don't we create some kind of standard that will work like Swagger? That is, each system that wants artificial intelligence to be able to give it commands and instructions can describe in its own way how it can be worked with. And then, artificial intelligence, understanding this standard, understanding the list of tasks that can be done according to this standard, will then directly send commands to this system under the hood, and this system will interpret and execute them normally. That is, we will create a kind of Swagger for products so that artificial intelligence can work with them. And as a result, we can have a lot of different MCP servers that simply describe how exactly they can be called and how they can work, what parameters are received as input, what parameters are received as output. Does this remind you of anything? For me, as soon as I started reading about MCP, I was like: "Oh, so this is Swagger." Here is an example of Swagger, which is used to
This would allow describing the work of a rest-api. We have post methods, for example, a post to create a new uhh creature in our store. Here's the body that we receive as input to create the creature. There's a get for retrieving these creatures, which we want to, well, somehow get, interpret, and show. We pass its ID as input. We get such a JSON as output. So, exactly the same thing is implemented under the hood in MCP servers. Let's return to our animations. We want a person named Vasya to be created. Let me quickly scroll through this animation that I've already shown you. And here, under the hood, another participant is added. This is an MCP server. So, we have our computer or server that communicates with the MCP server and queries it upon startup, saying, "Hey, friend, what can you actually do so that I can call you later?" Along with any command, with any text request, a list of tools available within our MCP servers, which are connected to our system, is passed to the LLM. And in the end, the LLM then chooses the most suitable function from these available options, passes it to our server, saying, "Call this command in this MCP server," and whatever the MCP server returns in response, please return it to me so that I can somehow interpret it and tell the user information about it, or perhaps give you a command to call another MCP server. Everything is okay. This entire communication procedure happens approximately in this manner. And everyone remains satisfied. And here, in this purple MCP server, we can insert anything. That is, it could be an MCP server that was written by completely different open-source developers, like, you know, how all these NPM libraries and so on are made, developers share in open source. There are probably hundreds, or maybe even thousands, of ready-made MCP servers. Various integrations with Google Calendar, integration with Yandex APIs, integration with APIs of absolutely any other systems. So, imagination just runs wild here. There's even an MCP for working with your browser. You can launch a browser and run SP servers alongside it, which will control your browser, I don't know, go to different websites for you, search for something, or, for example, launch some system on the web, test it, observe it. That is, an MCP server can already do anything. It's just a small add-on. Or, in other words, MCP is an attempt at standardization. Moreover, I must say that it's a quite successful attempt, because standards have truly entered our lives. We have already sold several agents to clients based on MCP servers, launched them, and they are working successfully. It's very well supported, works great. And the main thing is that many things have already been done before us. We can simply take what's ready, configure it, and use it, just as we have been doing for the past few years, using open source. Let's see how, for example, a tool is registered within our MCP server. We have the name of our command, which the artificial intelligence can call, or rather, which the artificial intelligence can pass to our server for it to call in the MCP server. There are input parameters that are needed for this handler to work, and the handler itself. So, everything, within, uh, how many lines, maybe 20 lines, you can create the first tool that will process input parameters and output something. And in the end, we connect this server to our artificial intelligence, well, not directly to it, but to systems that integrate with artificial intelligence, and in the end, our artificial intelligence immediately turns into an AI agent. Well, of course, I understand the disclaimer that it's not the AI that turns into an AI agent, it's just our entire system under the hood, using AI under the hood, again, yes, well, it becomes a tautology, turns into an AI agent that can call different functions. These functions can be absolutely anything, limited only by your imagination and time and laziness to write various integrations. And now let's look at what types of MCP there are. There are MCPs that we made for user management. There are MCPs for analytics, report generation, identifying weak spots. There's an MCP that's a really cool thing, it works. I used it under the hood. We have Grafana, we have Loki, and you can retrieve information about the latest logs, for example, about the latest errors, from Loki upon request, and, for example, interpret it somehow. You can connect an MCP server for GitLab or GitHub, and it will go to your repositories, look at merge requests, and can even leave comments. So, there's already a ready-made MCP server that can perform some basic or non-basic integrations with your Git repository. All of this is implemented in the form of MCP servers. So, they can be different. Different AI agents have different sets of MCP servers. They can be juggled, they can be connected. There's even an MCP that determines which MCP to call. It receives a bunch of available MCPs as input. And in the end, it's a bit of a two-tiered system because we first write a request to the LLM, the LLM chooses which MCP server is most suitable for us. Then the request is sent to the LLM again, and only then are all the things that the chosen MCP server can do passed. This is done so that we don't pass thousands of tools with every request and waste tokens unnecessarily. And in the end, we get a whole aggregated MCP system. You can communicate with MCP servers in several ways. For example, here's our excellent product that we want to integrate with artificial intelligence and using MCP servers. It can implement its MCP server in the format of, for example, STDIN. This is the simplest way to communicate directly. These are personal agents. If we run it on our computer, we can simply directly pass whatever the LLM is running, it immediately executes a command through this STDIN, passes information there, processes it, and gets it back. No need to bother with HTTP, no need to bother with making it public. Everything works locally on one computer or one server. You can publish an MCP in HTTP format, you can publish it in WebSocket format if real-time very active interaction is needed. There can also be gRPC, there are already ready-made connectors for this, or maybe anything at all, I don't know, you could make pigeon post, so that, I don't know, the LLM prints on paper, a robot automatically attaches it to some pigeon. The pigeon takes the paper, flies to the other end of the earth, the paper flies into a scanner, is parsed, and executed. In short, here you can limit yourself to nothing, use it however you want, implement it however you want. Well, we most often use the STDIN approach because a regular API is run alongside the connector with artificial intelligence. But if you need to separate microservices and so on, then WebSockets, gRPC, HTTP, whatever is already in the project, we use that. So, STDIN works this way. And then, upon startup, we get a list of tools. And now, when we send this list of tools directly to the LLM, we convert them into the format required by the current LLM. Because Olam, VLM, Gigachat, ChatGPT, Gemini, Claude, each has its own API, there might be some changes, fields might be named differently, they don't differ much, but still, we directly convert what comes from the MCP server for a specific provider. We write integrations with these providers once, and then we reuse them everywhere. Then these functions are passed directly into the request, yes, this is an example of a request to this OpenAI. And in the end, the dialogue is built as follows. We create a user named Vasya, send him these arguments, he returns the create_user function with these arguments. We call it, and in the end, the create_user function is called. Everything is good, everything is great and wonderful. In the end, what does MCP provide? It gives us standards. We can finally stop worrying and focus on the product, rather than on how exactly this product will communicate. And of course, standards again. Standards again. What is needed to start our AI agent? A prototype for interacting with artificial intelligence is needed. In our case, we use one of two options. It's either the console version, which I showed you a little earlier, or through a Telegram bot. So, exactly the same thing, since we need something that can receive text as input and output text, we have created a large system in the form of CLI and Telegram. Under the hood, we need to integrate with OpenAI, Gigachat, or any other system. Under the hood, we have integration with Olam VLM to be able to run on our own video cards. A couple of example stubs so that developers can further develop this thing. And in our case, easy launch in TypeScript. And our entire architecture is built approximately as follows. There's a chat processor that receives all messages as input. And we simply understand that this is the session ID, that this is the user, and this is the text request from them. There are, for example, somewhere behind seven seals, behind seven locks, several connectors with several GPT providers. And we send the request through the connector. The connector itself queries the MCP server about what interaction options are available. So, let's add an MCP here. And we, the chat processor, communicate with the MCP. The MCP provides all available tools, and the chat processor simply passes all the tool options that can be called through the connector. And in the end, everything turns out perfectly. And the connector, if needed, on its side, because each GPT provider system has its own format for storing sessions, or rather, its own format for providing message history. Therefore, at the connector level, we save the entire correspondence history so that this correspondence history can be maintained and developed further. And the connector, in turn, sends the entire correspondence, the result of function processing, and all functions that can be called. And in the end, it becomes a combined mechanism that works very complexly and can maintain correspondence. If we have a context of 32 MB, it can be a correspondence, I don't know, for weeks with a chatbot and experience no problems at all in this regard, because the context doesn't expand that much when working with text. The problem only arises when we overload it too much with MCP servers, get a large list of tools that we want to send. In such a case, yes, the context can expand, but then you have to encounter this problem to solve it somehow. So, here everything is variable, and there's a solution for each case. Let's wrap up and move on to examples and agents. The first is user management. I've already shown it, it's analysis of incident logs during incidents. A cool thing. We are trying to launch it ourselves. It works in some places, not in others. Based on the context of the logs, it can understand what exactly broke. That is, we can understand that something external broke. For example, some external service failed or access to the database failed. Since this information appears exhaustively in the logs. We see it with our eyes, we understand it with our eyes. Therefore, artificial intelligence can also parse this information with its eyes. Initial MR review is to check if the developer is not using some suboptimal algorithms, if they are not leaking credentials anywhere. In short, it's a kind of initial inspection so that it can be passed on to a person. Music control is an experimental format, where you can write commands for music control in text format. This immediately brings to mind integrations with Alice. These are those voice commands, like play music, pause, or turn on the light. This is also essentially an AI agent, implemented under the hood in a similar way. Well, I probably don't want to be definitive, because I am not an employee of Yandex, but I have this assumption. We also had ideas to control a Dubai taxi fleet. Our client, we are automating his business of transporting people in Dubai. There are different providers, different ways of getting information about where and how each driver is. And artificial intelligence, based on JSON and the representation of information about where everyone is and how they are currently located, can perfectly understand where everyone is working. That is, this JSON is perfectly fed to it, it parses it and can give recommendations. We tried this as an experiment and offered it to the client, but the client has not yet implemented this solution. However, the mechanism as a whole is working. It worked in draft format. And where it is also actively used is in the analysis of financial statements. We can provide information about cash flows. We have clients who trade on stock markets. We can provide all this information there. It can analyze and make recommendations. Again, this is not about creating a personal assistant to help you get rich. No, we don't do that. Moreover, I don't believe in it at all. It's more of an analysis of how things are currently going in the team, how the company that is directly involved in finance is doing. And the simplest, perhaps most frequently used example is a generator of invoices and documents. We have implemented it under the hood. That is, to quickly get a draft, we can say, "Create an invoice." It then queries what invoice parameters we have, and in the end, it outputs a file that can be further edited, brought to the desired state. But getting draft documents greatly optimizes this. That is, we quickly get them, and then we work with them. How can it be launched right here and now? That is, you, for example, listened to everything, thought, "Great, cool, we want to do our own." We have several ways to work with our artificial intelligence providers. We can connect to OpenAI and Gigachat. This is quite fast. In the case of OpenAI, it's a bit more complicated for us because we'll need to get a foreign card or buy tokens through some intermediaries. It's fast, it's paid, but it's risky because you're giving some information to a third-party service, you become dependent on it. And in some cases, in our case, we have projects with government customers, and there, of course, you can't use this. It's simply, well, dangerously risky, because it violates the law. If we're talking about local launch, then we launch Olam or VLM. If we're talking about Olam, it's more for personal use. That is, Olam runs on my computer, it works great, it loads and unloads models under the hood, everything works great. But sometimes it happens that one model loads onto another and it ends up in the computer's RAM, and that's it. Olam turns from a fast-working product into a very slow-working, incomprehensible thing. Therefore, Olam can only be used for personal purposes, and for production launch, you need to use VLM, because there you can fine-tune everything so that one model unloads and it always stays in memory. So, there's much more control, but it's not very suitable for a quick launch and play. It's quite slow. If we're talking about video cards, there will be a whole slide about it a bit later, and it will work much slower than any cloud provider. It will be conditionally free. Well, it's about 150 times cheaper than running on a cloud provider, because when converting tokens to rubles, if we consider kilowatt-hours of energy, in our office a kilowatt is bought for about eight rubles, it turns out to be 150 times cheaper than buying the same tokens from Olam or Gigachat or OpenAI. It's safe, everything runs within your system. So, in general, I ordered an external video card for my laptop. I want to try connecting it as an experiment. That is, it connects via Type-C, an external video card. And in the end, I can get this information, access to this knowledge base embedded in the LLM that is running, completely without the internet, without anything. For example, GPT OS. It's quite versatile, smart, it can do a lot and covers many of my needs for artificial intelligence requests. So, it will be possible, I don't know, to go somewhere into the taiga and run it from a power bank or a generator without the internet, without anything. You can use artificial intelligence and not worry about data leaking somewhere. Or you can rent a VPS with video cards. Normal GPU servers cost from 20,000 rubles per month. These are simple video cards, well, like, well, 4070, 4080, so video cards that can work fast, but they won't have enough memory, but you can already run quite fast solutions. It will be very expensive, yes, as you can see, 20,000 rubles per month is not budget-friendly at all, but it will be sufficiently safe. Yes, of course, you can say that the provider has access to your server, can get anything there. But in my opinion, this is already a risk that can be ignored. But money cannot be ignored. If we take this symbol pie of choosing, how to say it, optimal paths, then we say, here's the fast option, which I talked about, cloud-based, there's the safe option, which is when we run it locally ourselves, and it's usually expensive. If it's fast and safe, then it's expensive. And there's the option of free launches on a server. If it's safe and free, then it's slow. And if it's free and fast, then it's stupid. That is, we run something locally ourselves, and we run a very simple model that will, to put it mildly, disappoint you. Now let's talk about resources for local launch. I decided to dedicate a small block to this, because we are increasingly using local models. And I only turn to cloud GPT for coding, when I need specific advice, to get some ideas from it, because, well, it's trained on cutting-edge data, it's quite fast, smart, and it's free, because, well, it runs as a regular chat. But when we talk about different agents, then under the hood, of course, everything runs locally. If your local video card has less than 8 GB, then, most likely, you should abandon this idea, I would like to tell you. These are usually GTX series video cards, and we can run models like Gemma 4B or DeepSeek R1 7B. It will work, including slowly. It will work painfully, terribly, and it's better to abandon this idea altogether. Well, you can launch it as an experiment, but you'll just launch it and see that, well, it works slowly and outputs some nonsense. You'll just be disappointed again. Therefore, it's better not to get upset again. With 8 GB of RAM, it's better to go to the cloud or wait until you have a video card with more memory. Here's the next tier, less than 16 GB of memory. This is already an RTX 360 series video card. I used one like that for 2 years. I ran a 4B model locally. It worked, well, quite fast, you know, just like ChatGPT. It's certainly a bit dumb, I won't say anything, but it could look at photos. It could interpret those photos somehow, and you could record some local things for yourself as an experiment. 27B worked, it at least launched on an RTX 360, but it worked incredibly slowly. But again, when we run something locally, you can tolerate it for a while, but you'll have to tolerate it quite painfully. And we move to the next tier. This is less than 32 GB of RAM. This is, for example, an RTX 3090 video card. I absolutely love this card. I have this video card in my computer. It's in our servers, it's used. In short, it's an awesome video card. It's optimal in terms of price-quality ratio. On the secondary market, it costs about 50-60 thousand, and it covers almost all AI launch use cases. It handles all of this excellently. Models like 4B work very fast. GPT OS Gemma 27B works fast. Everything works perfectly fast. Moreover, even if we launch VLM, you can even load it. There, 20-30 people can work with it simultaneously and not even notice that they are working simultaneously. Everything under the hood will work very optimally and fast. In short, I highly recommend the 3090. I know there are also people who run on Macs, on processors. Honestly, I don't know. I know that these processors, like Apple Silicon, they have M3, M4, in short, I don't even know their names, but since I don't even know their names, you understand the extent of my expertise, I believe I don't have the right to even give my opinion on this matter. Therefore, I only talk about video cards, since I only have experience running on video cards. If you have a different opinion, I'd be happy to read it in the comments, to hear it. In general, please, I'd be happy to see other ways of running neural networks. Let's move on to useful links. First, if we're talking about MCP servers, these are open-source servers that you can clone, launch right now, and they will work for you. This is a huge collection of MCPs shared by the community. In general, I highly recommend it. At least, you know, like, appetite comes with eating, when you scroll through this list of MCP servers, you'll realize, wow, how many cool things you can do for yourself. In general, I highly recommend it. The next material is my article on Habr about launching AI agents in TypeScript. Yes, I showed you code snippets from TypeScript today. And there's also a separate video that I uploaded to Vladilen Minin's channel, where I do everything I've told you about today in a live coding format. So, within this content, you've received the entire theoretical part to be able to launch, and within this article or that video, you can see the internals, how it all launches, how it all works, everything from start to finish, how to create your own Telegram bot that will work as an AI agent, how to create your own console bot. In short, study, watch, I'd also be happy with any feedback. That's all. Thank you very much for your attention. This was Anton Morev, and this was the Galera Moreva project. See you next time. y