Transcription
Imagine that you have a whole army of agents. They work on your tasks 24/7. Sounds like a recipe for some, well, just incredible productivity. But what if I told you that adding more and more agents to this army could break everything? >> Exactly. And this, you know, is no longer just some theory from scientific articles. Gartner predicts that by next year, 40% of corporate projects with agents will simply be shut down. 40% is a huge number. >> Huge. And the reason is not that the technology is bad or doesn't work, but that teams build these systems, well, sort of on advice from social media, which looks great in short demos but crumbles to dust at the first attempt to do something serious, something scalable. Welcome to our dive today. We have material on our table from the YouTube channel AI News and Strategy Daily, and it hides a very, very painful truth. Conventional approaches to creating multi-agent systems fail completely as soon as we go beyond toy examples. >> So our task today is to understand this paradox. We will find out what the main fundamental problem is, why more suddenly becomes worse. And then we will analyze five completely counter-intuitive principles that, according to the source, allow for the creation of truly effective systems of hundreds, and perhaps thousands, of agents. >> So, let's get to the point. At the heart of all this is research from Google and MIT. According to the source, it was published in 2025. And its findings are, frankly, a real cold shower for all enthusiasts. >> Absolutely. >> It turns out that adding agents to a system can not only yield diminishing returns but lead to a real, measurable deterioration in performance. That is, literally more agents, worse results. >> And the most interesting thing is the reason. The source calls it sequential dependencies. It sounds a bit sophisticated, but the idea is actually simple. Explain. >> Look, when agents have to coordinate their actions, wait for each other, use some shared resources, they simply form a queue. It's like on a highway. You can build 10 lanes, but if they all lead to a single exit, you'll just have a 10-lane traffic jam. Complexity breeds dependencies, and dependencies kill all the benefits of parallel work. >> And this is not just some speculative concept, as I understand it. The source provides numbers, and they are, frankly, devastating. >> Yes, there is concrete data. >> In systems where agents have access to many tools, say, more than ten, efficiency drops by two, or even six times compared to a single, but well-tuned agent. And here's another fact that just blew me away. If the accuracy of a single agent in performing a task is above 45%, >> just 45, >> yes, then adding other agents to help already has a negative effect. They start to hinder more than help. >> Absolutely. This completely breaks our usual intuition. We're used to: more graphics cards, faster model training. >> More servers, higher throughput. >> Exactly. And it seems logical. more agents, the task is solved faster. But no, in practice, the costs of coordination, all these, so to speak, meetings, waiting, conflict resolution, grow exponentially and eat up all the benefits. In the end, you pay for 100 agents, but only five do the actual work, while the rest are just stuck in that very traffic jam. >> Okay, we've dealt with the problem, it's fundamental, but how do we solve it? The source claims that those who have managed to successfully scale systems, for example, the company Coursera, which makes a coding assistant, or engineer Steve Yagi with his project Ghostown, >> yes, it's a whole autonomous system for software development. >> So, they independently arrived at the same, at first glance, completely wild solutions. Let's analyze them in order. And the first one sounds like this: you need a hierarchy, not a team. Yes, and this is a direct blow to the most popular idea. Look at all these frameworks. Auto-GPT, CrewAI. The idea they sell sounds very beautiful. Let's make agents work together like a cohesive team of developers. Discuss, delegate, share ideas. >> Well, yes, it sounds like a dream. >> So, Coursera, which is precisely involved in AI for programmers, conducted a direct experiment. They gave agents equal status and allowed them to coordinate. The result was, well, a failure. >> And what happened there? Did the agents go on strike, I don't know? >> Worse. They became, surprisingly, like people in an inefficient corporation, they started avoiding risk, only taking on small, safe tasks to quickly show results and get, so to speak, a checkmark. >> And complex problems? And complex, important problems remained untouched. No one wanted to take responsibility. They constantly blocked resources, waited for each other. As a result, a system of twenty agents worked with the productivity of, well, maybe two or three. Distributed responsibility turned into irresponsibility. >> It's incredible that AI has reproduced the same social problem. So what's the solution? A strict, uncompromising, two-level hierarchy. At the top level are the planners. Their task is to decompose a large goal into small, independent tasks. At the bottom are the workers. They take one task, perform it in complete isolation, hand over the result, and disappear. They don't even know about each other's existence. No teamwork, no communication. It's amazing that two different projects arrived at exactly the same conclusion. Is it a coincidence, or is this two-level structure the only working option once the system becomes complex? >> It seems so. Steve Yagi in his Ghostown arrived at the exact same architecture. He has a mayor who assigns tasks, and ephemeral ferrets, as he amusingly calls them, who do the work and then immediately die. Two independent practitioners concluded that coordination between equal agents is a dead end. Research, by the way, confirms this. Two-level systems significantly outperform both flat teams and deeper hierarchies where the game of telephone begins. >> Okay, hierarchy instead of a team is clear. But the next principle the source talks about, it seems to go against everything we know about AI work. It claims that worker agents should be, well, almost ignorant. The less they know about the overall picture, the better they work. >> This sounds like a paradox, yes, but it fits perfectly into the logic of combating dependencies. Remember the Coursera experiment. When their worker agents understood the entire project context, they started experiencing scope creep. That is, >> given the task of writing one small function, the agent, with the best intentions, decided that for the overall benefit of the project, it was necessary to rewrite the entire module as well. >> Wait, so we give an AI agent access to a huge amount of information, and then artificially limit it. It sounds like we're buying a race car and forcing it to drive only in first gear. >> Excellent analogy, but in this case, it is absolutely justified. When one agent decides to rewrite a module, its actions begin to conflict with the work of dozens of other agents. And resolving these conflicts is again what? Coordination, meetings, those very sequential dependencies. >> I see. Chaos. >> Exactly. Broad context for a worker is not an advantage, but a source of chaos. Therefore, the principle is minimal viable context. The worker receives exactly the amount of information needed to perform one specific, narrow function. Not a byte more. It's like putting blinders on a horse. We're not making it dumber. We're making it run straight to the goal. >> Logical. Isolated, unaware workers in a strict hierarchy. This brings us to the next idea, which also seems strange. If agents are isolated, what about their tools and data? Common logic suggests they should have shared access to everything, right, so as not to reinvent the wheel. >> Of course, but, as you've probably already guessed, this also turned out to be a mistake. The source calls it a fight for the toolbox. Imagine a carpentry workshop where 20 carpenters try to use the same hammer simultaneously. >> Conflicts and waiting. >> Yes, but there's another, more subtle problem. Research shows that an agent's accuracy in choosing the right tool drops sharply when there are too many of them. After 30-50 tools, accuracy decreases, even if the agent has an unlimited context window. The problem isn't memory, but the selection process itself. >> But if they have nothing in common, how does their work come together into a single whole? It sounds like we'll get 100 disparate puzzle pieces. >> A perfectly valid question. And the solution is to externalize coordination. Workers are completely isolated, each with their own tiny set of basic tools, three to five, no more. And all collaborative work is done through external systems that are inherently designed for parallel access. For code, it's Git; for tasks, a message queue. >> And how do you assemble the puzzle? >> And to assemble the puzzle, a separate, dedicated system is created. In Ghostown, Yagi calls it the Refinery. It's a special agent whose sole task is to receive and merge changes from workers. All the complexity of merging is moved outside the work of the main agents. >> So, we have a hierarchy of isolated, ignorant agents with tiny toolkits. The picture is becoming stranger and stranger, especially given that the entire industry is now talking about creating long-lived agents that accumulate context and become smarter, while here they advise doing the exact opposite. The fourth rule: plan for termination, that is, literally kill your agents. >> Yes, and this brings us to the concept of context pollution. This is a very important point. The longer an agent works, the more irrelevant, outdated information accumulates in its memory. The signal simply drowns in noise. Its own history becomes that very sequential dependency for it. It's like with humans. Try working on one task for 8 hours straight. By evening, you'll remember all the minor details of morning edits that are no longer important, and this will hinder seeing the big picture. Agents suffer from this in a hypertrophied form. >> And this is the very phenomenon of "lost in the middle," when a model simply forgets instructions from the middle of a long prompt. >> Exactly, in its extreme form. Therefore, the solution is episodic work. The agent works a very short cycle, saves the result to external storage, and dies. The next cycle starts with a new, clean agent with fresh, relevant context. And here the genius of Yagi's architecture becomes clear. He stores the workflow state outside the agent in the form of so-called molecules. >> What does this give? >> This makes the system incredibly robust. An agent can interrupt work, crash, it doesn't matter. The next one will simply pick up the task from where the previous one left off, by reading the state from this molecule. >> Okay. And this brings us to the last, fifth point. It seems that creating such a system is a complex engineering task. You need some incredible infrastructure to manage all this. But the source says that this is not the main thing, that the quality of prompts is more important. >> And this is not just an opinion, it is confirmed by statistics. 79% of failures in multi-agent systems occur due to problems with specifications and coordination. Essentially, due to bad, unclear instructions. That's almost 80%, >> yes, and only 16% due to purely technical errors. Often, teams build complex coordination infrastructure. All these queues, messages, state synchronizers. And this infrastructure itself creates new dependencies instead of eliminating them. >> And the solution is to >> treat prompts like API contracts. And here all five rules converge. Look, for a simple, isolated agent that knows nothing about the outside world, has three tools, and performs one narrow function, it is much easier to write an extremely clear prompt with clear boundaries, understandable input data, and strict success criteria. When an agent is simple, it is easier to instruct it correctly. The simplicity of the agent breeds the simplicity and reliability of the prompt. >> So, let's try to put it all together. On the one hand, we constantly talk about simplicity. simple agents, simple tools, short cycles. On the other hand, a system like Ghostown with all its mayors, ferrets, refineries. This sounds very, very complex. Is there a contradiction here? >> At first glance, yes. But the key idea is that complexity must reside somewhere. The question is where. And the right answer is at the orchestration level, not at the individual agent level. The management system is complex precisely so that agents can remain simple, dumb, and work effectively in parallel. In GitGhostown, there is a separate agent that simply monitors whether other workers are stuck. There is an agent that deals only with code merging. This is complexity in orchestration. This is the price we pay for the ability to parallelize the work of hundreds of simple performers. >> I see. So the goal is not to create one genius agent, a superhero, who will work on a project alone for a week, but to create a genius manager, an orchestrator, who can effectively manage thousands of simple, almost primitive agents, each of whom works for 5 minutes, but does it in a coordinated way. >> Exactly. And this completely changes the strategy. The forecast for 2026 is this: the winners will not be those who try to create the smartest agent, the Jason Bourne of AI. The winners will be those who invest in orchestration. They will be the ones who can truly leverage the upcoming tenfold increase in computing power. They will be able to add agents and get a proportional increase in productivity, not a system collapse. They will outperform competitors not by percentages, but by orders of magnitude. >> Well, let's summarize. The main takeaway from this analysis. To scale AI, you need to be almost philosophically committed to simplicity at the agent level. The five rules we discussed today: two-level hierarchy, unaware workers, absence of shared state, planning for termination, and prompts as APIs. These are not just technical tricks, they are practical ways to achieve that very simplicity that scales. >> And here's perhaps a final thought for reflection. The source focuses on software development, but this pattern of many simple, isolated units, managed by a complex orchestration system, we see everywhere. Think about ant colonies. A single ant is primitive, but the colony solves complex problems. Or about the cells of our body. Each cell performs a simple function, unaware of the organism as a whole, but a complex system of signals and hormones coordinates their work. Perhaps the future of AI architecture lies not in imitating the meeting of a team of people, but in studying the principles of truly scalable systems that nature has already created and refined over millions of years. >> We conclude our dive today. Thank you for being with us.