Transcription
Today on the internet, people are talking non-stop about AI agents. Claude Code, with each new release, is replacing more and more developers. OpenClaude is taking away jobs by performing any task on a computer instead of people. The demand for RAM and Mac minis is skyrocketing, but most people don't even understand what AI agents are and how they differ from regular ChatGPT. Therefore, in this video, we will try to understand all types of agents. We will delve into how it works, what limitations and architectures exist, and what they can actually be used for right now. Hello, my name is Oleg. In my everyday life, I am a developer, but on this channel, I am more of a vibe coder. Here I test neural networks and tools, build micro-projects and automations. I see what really works and what doesn't. Every day, millions of people use ChatGPT. It entered our lives quite a while ago, changing some habits and approaches to work. Although, in fact, talking with AI is just predicting the next words based on the previous text. It's just that during training and at the system prompt level, neural networks were tuned to respond precisely in this dialogue format, creating the illusion that someone is talking to us. But what if we ask models to generate text in a different format, for example, to transform data from one structure to another or to classify incoming text? Such an approach is quite workable and widely used in automations. From several LLM nodes, you can already build something interesting. For example, in n8n, I built this pipeline. How does it work? A message comes in from Telegram. The model determines what type of content we want to generate: an image, video, or text, and then, depending on the choice, it processes the original message differently through the LLM, getting a prompt for content generation. Then it generates an image, video, or immediately sends the text. Here is an example of how it works. I will ask it to generate an image, and I get the result. Here, the LLM essentially has the ability to improve our ideas and influence the result. However, the model cannot make any non-standard decisions or take actions outside the given framework. It cannot generate two images instead of one or choose a different text-to-image model unless we manually refine the pipeline. This workflow is usually called a deterministic workflow with AI elements. The neural network here only does two things: it makes local decisions, choosing one from a limited set of options, plus it transforms data from one format to another. The LLM cannot fundamentally change the message processing scenario. There are some tools present here, but essentially, the system is not agentic. By the way, if you are building heavily loaded production automations, training and fine-tuning models, or rendering videos, I recommend checking out Immerscloud. It is a specialized GPU cloud. They have the largest selection of Tesla and RTX video cards in Russia. There are thirteen different models, including H100, H200, and RTX 5090. For really heavy tasks, there is NVLink to combine multiple cards and get truly serious power. You can pay for the hardware by the second. You spin up a machine, run your task, and shut it down. Money is debited only during use. This is ideal for experiments and one-off tasks. But if you need a server permanently, you can get hardware with a discount of up to fifty percent or more for long-term rental with monthly payment. Plus, Immerscloud already has ready-made server images with a configured environment for AI: drivers, CUDA, libraries – everything will be in place. You won't have to waste time on configuration and installation before launching anything. Using the Immerscloud link in the description, you will get an additional twenty percent to your first deposit. Register and use AI without limits. And now, let's continue. But then what is an AI agent at all? Let's look it up on Google. An agent is a system that can set goals, plan actions, and use tools, browsers, APIs, CRMs to solve multi-step tasks without constant human control. Unlike regular chatbots, they don't just answer, they perform actions. Our current bot is not allowed to not answer us and cannot really plan much. Let's give it this freedom of will. This workflow in n8n already works differently. Here I used the AI agent node and connected tools for working with generation and sending materials to Telegram. As you can see, there is no clear sequence of nodes here, only one LLM module that makes decisions, and tools located at the same level relative to each other. Now the agent is not obliged to answer us at all, but at the same time, it can answer us more than once. It can perform several actions in response to one message. For example, I can ask it to generate an image and a video at once, or three images at a time. This works much more flexibly. The agent can now truly solve and act as an independent entity. However, our bot remembers nothing. It is unaware of what was said earlier. Its memory is limited to one processing cycle of the message sent by the user. Let's add a basic memory module, Simple Memory, to our bot and ask if the agent remembers previous messages. Great. Now its memory looks back five messages, as we set the memory key plus the memory size equal to five. This chat history storage is very simple to implement and works fine in short chat sessions where the user wants the agent to perform some small task that fits within the model's context. Context is something like the LLM's RAM. How much information the model can process per call. Let's see what tools our agent uses at all. To generate images and videos, I gave it the FileAI tools. In them, I pre-defined models and some parameters. I did this to simplify calls and minimize errors, as each model has its own mandatory fields, sometimes in its unique formats. Simply put, when an error is received from an n8n tool, the agent usually crashes and interrupts task execution. Fixing this problem is quite hacky, so let's move to another system that, in my opinion, will be more powerful and flexible than n8n. Let's take Codex CLI. This is a terminal agent utility for writing code from OpenAI. It can edit and read files, run commands in the terminal, and can work with a ChatGPT subscription with good limits. However, you can only choose OpenAI models with it, but lately, this is not a problem, as their models have become quite powerful. I will launch VSCode, create a folder for the project, open it, open the terminal in it, and run Codex in it. As the model, I will set the latest GPT-5 Turbo Codex with Extra High Thinking mode via the slash module. And purely for the demo, I will ask it to create a simple browser program for cropping and scaling images. As you can see, during execution, our agent starts calling various tools, thinking, and sometimes commenting. Here in the work log, we see how it changed files, added code to them. It is also visible that it tried to call the Playwright tool but failed with an error, and, as you can see, it did not stop working on the task. In this aspect, Codex is much more reliable than n8n. Then at some point, it asked for manual approval of the command it wants to execute. This is a cool feature that is present out of the box in all coding agents. Within the project or globally, we can save a list of tools whose calls we consider safe enough for the agent to make without our knowledge. For example, reading files in the current project, and we can allow other dangerous commands to be executed only if we confirm them ourselves. In normal agent systems, such a manual approval stage will be present in the necessary critical places, but absent where there is no great risk and where agents already cope well without a person. Okay, let's see what our coding agent did. Let's open the file. Oh, the program works. The display of the selected area is, of course, super non-standard, but at the same time, the program is functional, images are cropped, scaled, there is even a choice of the output file format and quality level. Cool! Let's do something cooler, since we have such a powerful model and an indestructible system. Let's create a Chrome extension that analyzes recommendations on YouTube and marks low-quality content with a specific thumbnail so as not to waste time watching them. Here I asked it to build not only the extension itself but also its backend and a landing page with instructions and a download button. Plus, deploy the backend and landing page on my Qualify server. Before starting, I will set up the necessary in .env, specifying my API key for Polza AI, Base URL, and model. Polza AI is a Russian aggregator of LLM neural networks that allows you to connect absolutely any text models with one API key. Everything works for rubles without VPN and restrictions. The API formats are 100% compatible with the OpenAI standard, so integrating the API code is super easy. All agents know this format. Integrating into any AI project is not a problem. You only need three things: for requests to go to Polza, not to OpenAI itself, which is what I am specifying the Base URL for. I also generate an API key in their interface and copy the ID of the model I want to use in this integration. For our purposes, we need a cheap, fast, and at the same time smart LLM. For these requirements, the recent Gemini 3 Flash is ideal. I tested it, and it was super cool for the price. In general, let's copy its name and specify it in our .env file. Done. I will also initialize my Rules project and now let's start development and wait. After 40 minutes, the agent finished its work, it sorted everything out and deployed it. Indeed, the landing page and backend are working. But how did it do it? To deploy the program on my server, it used the MCP server Qualify. MCP is a protocol by which you can connect different tools to an AI agent. There is already a detailed video about MCP on my channel, you can watch it here. And Qualify is a control panel for deploying applications on my server. I vibe-coded my MCP and connected it to Codex with my API key. And that's it. Now my agent can deploy various applications at my request. And by the way, the same applies to GitHub MCP. There I limited the scope so that the agent can create private repositories and create pull requests. However, let's look at the work of our extension. It installs successfully, but in fact, it does not affect the content on YouTube. Uh-huh, there are a lot of errors in the browser logs. It is clear that there are problems with YouTube blocking. Let's ask the agent to fix it, to use some bypass or API. After a couple of such fixes, we managed to create a working version. Some videos are indeed marked with thumbnails. Cool! It considers all video clips to be junk. Sorry, Varlamov. And it also marked Lonkov. Okay, let's test the feedback system. Let's write that I love Korean history. Okay, uh-huh. And my prompt for filtering based on preferences has indeed been updated. Cool! Everything works. A good starter kit in general, to test the functionality yourself and then refine it into a product if needed. However, let's look at the console. If you observe the agent's work on such complex tasks, you can notice that the percentage showing free space in the context, i.e., 100% minus the size of the current chat, divided by the maximum size that the model can take as input in percent, tends to zero, then reaches a number close to zero, and then grows again to about 70%. How does this work? It's simple. Our chat is compressed using LLM-based summarization. At some point, when the chat approaches the threshold, a special summarization prompt is called plus the history of this entire chat, and at the output, our chat becomes smaller, containing only the most important things, according to the model. This trick allows you to work in the same session and not get stuck in a deadlock with a large chat. However, this can also lead to the loss of really important information. Plus, on super long multi-hour sessions, on gigantic tasks, it simply won't cope, as often during history compression, it is impossible to predict in advance what current information will be truly useful in the future, since we may not know the entire scope of the task and all future problems in advance, and, accordingly, on large sessions, summarization will occur many times, and at some point, nothing will remain of the initial task at the input. It will be diluted, turning into a homeopathic prompt. The current project the agent implemented by compacting about four to five times. In general, in my case, nothing terrible happened from this. However, after a couple of prompts, it no longer remembered that it needed to deploy new corrected versions of the application on my Qualify server. I had to push it manually. And as alternative solutions to the problem of limited context, trimming should be mentioned. This is when we, for example, limit the number of messages that go into the model to a certain fixed number. Then we will always consider only the N last messages, and the context will not run out, but information about old discussions will be strictly lost. This is a rather crude method. It is used, for example, in the previously mentioned n8n Simple Memory node. And one more method is rewind or undo, i.e., returning to some past checkpoints of the dialogue and continuing anew from that point. This method does not solve the problem of finite context, but it can help to roll back to some errors or hallucinations. But you can also combine approaches. For example, in my micro-project Fanfics Studio for generating really long stories, both summarization of old chapters with fact extraction and trimming, which skips full texts of only the latest chapters, are used. And the user can roll back and regenerate chapters if something goes wrong. However, in its pure form, the chat history memory scheme is effective only in short chat sessions where the user wants to do some small task or project. For performing large tasks, there is a more elegant solution to memory limitations – the use of sub-agents. For demonstration, let's switch to Claude Code. This is an alternative terminal agent from Anthropic. It can also work on a subscription basis, albeit with slightly more modest limits. Working with sub-agents is much more convenient in it. Let's launch it in an empty project and create our sub-agents. Sub-agents in Claude Code are subordinate coding agents with separate contexts, access to tools, and their own system prompts, like roles. They also usually have a prompt describing when exactly they should be called for task delegation. For example, let's create frontend and backend developers. Go to /agents, click "Create." Claude asks for the agent's role. I won't bother too much this time. Ideally, these roles should specifically indicate which approaches to use, which tools and commands to call. The role prompt allows customizing the system prompt for sub-agent tasks. Here are the prompts that Claude generated automatically. And let's also create deploy agents to deploy our project to the server. Here I will write the prompt manually so that it clearly uses my Coolify tool. For testing, I suggest creating a micro-application for generating looped videos. It will generate images based on a prompt, and based on the images – a video with correctly set start and end frames so that the resulting video is looped. Here is the prompt that resulted. For generating accurate prompts, I again use the Polza AI LLM provider. The same Gemini 3 Flash model, the same key. For images, VALL-E AI. Here is the .env file with configs I prepared. I launch it, and after some time, I see the backend and frontend developer sub-agents start working, and then the deployer activates, deploying the project to my Coolify server. Great. After a couple of fixes, the project works somehow. The videos, of course, are not generated looped as I wanted, but for now, it's OK. Now we can look closely at the logs and see how, during task execution, the main agent passed tasks to its subordinate workers. For example, it wrote in the task: create a backend for such and such a system, and the backend agent took on the implementation of this part of the program. Accordingly, the details of the code and implementation were only in the context of the backend developer. Frontend details are similarly in the context of the frontend developer, and in the context of the main agent were only general details, requirements from me, and the organization of work of all agents. This approach separates all necessary tool calls into three contexts, which can also sometimes work in parallel. We get not only increased total memory but also time savings. But what if our project is so large that it needs 10 backend developers and 10 frontend developers? Then creating 10 sub-agents manually will be quite difficult. Plus, peer-to-peer communication between workers will likely be needed, as synchronizing such a crowd with one lead will become much more difficult. To solve this problem, Claude Code has introduced agent teams. Let's see how it works. In another folder, let's ask it to create the same project, but ultra conveniently and beautifully. Plus, let's immediately check that the backend and frontend work correctly and write tests for them. Currently, agent teams are an experimental feature, so we forcibly enable it through such a variable in the config. We launch it in the TMUX terminal as recommended in the documentation, we see that the team lead created two subordinate workers: backend dev and frontend dev. I didn't describe them anywhere. The main agent itself decided who it needed and how to distribute tasks. We can also observe the work history of each subordinate agent here, see what they are doing. Agent teams are especially useful when you need to do mega tasks on a huge codebase. For example, documenting huge code by creating 10 analysts for 10 project modules. This really works well. After some time, our project will be ready and deployed, it works right away. The result is slightly higher quality than with sub-agents, but still, the videos did not turn out looped right away and with sound. Although at the very beginning, I specified the specific parameters with which the video model should be called in the prompt. How can we solve this loss of knowledge? We can use Claude Code's built-in Auto Memory to store useful facts in a project repository and retrieve them from there if needed. To activate auto-memory, enable it via this flag. Now, after restarting Claude Code, this feature is active. Let's ask Claude to remember that video generation should be without sound in this project. We see that it has read and saved this to memory. If you look into the .claude_projects folder and go into my memory project, you will find the necessary information in the memory.md file. And for verification, let's ask in a separate Claude Code session if it remembers anything. Uh-huh, yes, it remembers, everything works. In different agent systems, there are many similar tools that allow agents at some point to decide that something needs to be remembered and then somehow retrieve it. In Claude, reading Auto Memory works like this: the first 200 lines from the memory.md file are simply added to the agent's system prompt. This file can contain links to deeper hierarchies of other MD files. If the agent sees something useful for a specific task, it can dig deeper. A similar approach is used by Memory Bank, where we store project information in a specific folder. And there is also a very popular approach called RAG. In it, we store information in a vector database and search it using keywords based on their semantic vectors – embeddings. This technique is used in almost all agent systems. It is effective when searching a huge database of information, when other approaches can no longer accommodate such a volume. To test this approach in Claude Code, you can connect rag-MCP, which will open the necessary tools. Let's check. I will ask Claude to add files with my bank statements for the last few years to our RAG storage. Then, when ready, in a separate chat, I will try to ask what I spent money on in Tbilisi. You can see Claude calling the RAG tool with a search for the keyword "spending in Tbilisi" and returning the correct result. If you look into the tool-results folder in Claude, you can see the raw response from our RAG tool. It returned the top 20 results corresponding to the request. Each result is one page of the bank statement. It is visible that the top one is what we need. The sixth page, which contains spending in Lari in Tbilisi. What else is cool about terminal agents like Claude Code or Codex is that they can be called within another program with a task passed to them. Since they are purely console-based, this is super easy. And what's also cool is that such calls can also work on a subscription basis without additional API costs. For example, let's wrap our bot in a Telegram wrapper so that it's comfortable for me to talk to it about my expenses. I launch it. After a few minutes, I get the program. Now such a Telegram bot can search for the necessary information in my statements in the same way. And what's also cool is that it can do everything that a regular Claude in the terminal could do. For example, I asked it to develop and deploy Snake on my server. It did it, and it works. True, it has no memory between launches, so after restarting, I had to remind it what it did before. But then the idea arises, what if we ask it to improve itself? Let's try. We'll give it memory between restarts and reset this memory via slash start. Plus vision of photos, as now it can only read texts. Done, I restart, I check that the memory really persists after restarting. Correct, it works, and vision too. Hooray! Cool. Only now this bot resembles something. It is essentially almost identical to the hyped OpenClaude. In essence, the difference is only in the details and the number of pre-installed integrations. As you can see, creating your own universal agent analog from scratch is super easy now, but unfortunately, it's impossible to understand what the bot is doing under the hood now, as it logs absolutely nothing during its work. Therefore, I propose to fix this. Transparency and observability in agent systems are super important now. We need to understand how many tokens are used, how much context remains, and what calls were made within the session. I propose to set up some local frontend dashboard for visualization for now. Here is the prompt, and here is the dashboard that resulted. Now everything is visible. Cool. Having something like this for any agent is already a must-have, otherwise, you won't understand what it did and how much it cost you. And since our bot works in Telegram, let's add some long-term memory to it so that it remembers some basic facts about me, my preferences, and so on, so that I don't have to explain them from scratch every time. There are many solutions for implementing long-term memory. We have already talked about context manipulation, AutoMemory in Claude, and RAG systems. Therefore, let's try a slightly more advanced approach to long-term memory using graphs to store facts and their relationships. The most convenient open-source option for our case will be Mem0 or Mem Zero. It uses RAG and graphs to store relationships between facts, and an LLM is called to process facts within. Let's configure .env, specify our Polza AI credentials, Gemini 3 Flash model, as usual, and the key, plus OpenAI credentials for embeddings. Done. After implementation, let's check how it remembers my name. Let's restart the session, and you can see that it remembers my name. I also asked it to implement a memory graph preview to see how relationships are stored. Here's how it looks. It is visible that besides my name, it also saved some facts about project files and used libraries. How does it work? For each message to the bot, the user's text is first run in search mode for relevant memories using RAG and a graph structure. For graph search, facts are extracted from the text; for them, similar nodes are searched using RAG, then the nearest neighboring nodes are collected. The found facts are added to the model's context, and then the model responds to the message taking this information into account, and then adds the user's statements to Memzero, where the LLM breaks them down into facts and updates the relationship graph, plus our RAG. Also, as an alternative to Memzero, you can consider Zepp. Their system also takes into account the timestamps of facts, ranking them by relevance. It looks interesting, but unfortunately, the free version is not supported. New versions are only released as cloud solutions. And as another good option for experiments, you can consider the self-managing memory Letta. There, the model itself decides what to store, what to archive, and so on. Now our agent has decent long-term memory, but the agent sessions themselves are short-term, we cannot expand the neural network's context window, and therefore are limited by the size of tasks that we can give such an agent. Honestly, I want to have an agent to which I can give tasks of any size. For example, earn a thousand dollars or get a thousand subscribers on a Telegram channel. Something really complex and time-consuming. It seems that theoretically, this can be done by breaking the agent into a huge number of sub-agents, where each will do only a small sub-task, plus have access only to some necessary piece of information so as not to overload the context. And to implement this, I came up with this algorithm. At the input, the user gives a task, this task is evaluated by the agent. It can either take it immediately into work for the next iteration in a separate session, or break it down into sub-tasks. In sub-tasks, a similar recursive algorithm. After completing all sub-tasks, the task launches an aggregation session, i.e., collecting results into one common one, and then the evaluation stage, whether the task is completed. If not completed, the main task can add another batch of sub-tasks for the next attempt to solve it. Thus, you can try to solve some part for a long time. Plus, all tasks can be put into a "wait" status at the evaluation stage to request human input or simply wait for some time. This will be useful for long-running things like making changes to a project and waiting for metrics. Let's implement this. After a couple of dozen commits and a couple of days, I got a working mechanism. For example, here I asked it to provide me with a PDF comparing digital nomad visas in all Asian countries. The agent broke down the task into researching regions, then these regions broke down into specific countries. Also, in another branch, you can see how taxes, nature, climate, and other factors are being researched. As a result, this system carefully studied all the data, aggregated, checked, and compiled this PDF. It looks good. For comparison, GPT Pro for two hundred dollars compiled a similar file. That is, the system is at least on a more or less GPT Pro level. But it needs to be tested on even more complex and voluminous tasks where GPT Pro will stop coping. In the future, I will try to add some evolutionary self-improvement mechanism to this agent plus the addition of new tools, similar to how it is done in OpenClaude. If anything, the code for this project can be found in the description. And what else is worth noting in such complex systems: budget and limit control is definitely needed here. Without them, agents can launch wild uncontrolled processes that will devour the entire token budget. It is also important to note that if your agent can read something on the internet, it can be vulnerable to prompt injection. Someone can insert a malicious instruction into an email or website that your AI reads. How to solve such problems? Who knows. It seems impossible to guarantee complete elimination of the risk of prompt injection. Neural networks are always random. At the same time, you can limit the scope of neural networks when working with tools, not give every agent full control over the server, but only set the access necessary for its task. Then the risks of mistakes due to prompt injection are significantly reduced. In general, as a conclusion, I would say that agents are indeed starting to gain momentum lately. The latest LLMs are taking on more and more tasks, and more and more autonomous workers can be assembled from them. And now we need to learn how to manage them correctly, build processes, weave AI in where needed, learn to delegate work tasks to them, fine-tune, and build connections. All of this is already quite amazing and interesting to see what the world, the internet, and the digital sphere will look like in a year. So subscribe to the channel. Here I will continue to delve into what is happening in the industry, test everything that comes out, figure out how to use it in practice. Also, subscribe to my Telegram channel. I sometimes write something useful about AI and coding there. And, of course, join my new closed club of ultra-elite vibe coders. There is a chat, additional materials for videos, all prompts, experiment results, and so on. Soon I will post a detailed post about how much and in what way I earned from my AI micro-startups. A little later, there will be something else there. And write to me if you need a consultation or help with AI implementation. That's all from me. See you.