The AI Agents Multiplied Because I Told Them They Could

# The AI Agents Multiplied Because I Told Them They Could Source: [https://www.linkedin.com/pulse/ai-agents-multiplied-because-i-told-them-could-david-linthicum-qobce](https://www.linkedin.com/pulse/ai-agents-multiplied-because-i-told-them-could-david-linthicum-qobce) David S\. Linthicum I built a simple inventory management agent to test a few ideas for articles and videos\. By the next morning, that one agent had spawned 686 subordinate AI agents, and the system was working better than I expected, which was exactly what scared me\. I was looking for some new concepts for videos and articles around agentic AI, so I did what I normally do when I want to understand an emerging technology: I built something\. Not a slide deck\. Not a theoretical architecture\. Not a vendor demo that has been carefully polished to avoid showing the hard parts\. I built a working prototype around a real business problem and let it run long enough to see where the assumptions broke\. The use case was deliberately ordinary: inventory management\. I chose inventory management because it is not exotic, but it is also not trivial\. It includes forecasting, depletion tracking, purchasing, accounting, logistics, sales signals, exception handling, and business rules that change based on context\. That makes it a good test case for agentic AI because it has enough complexity to stress the architecture, but enough structure that you can determine whether the system is doing useful work or simply generating activity\. The first version of the system had a single AI agent\. Its job was to manage inventory levels, watch depletion patterns, recommend reorder points, and keep enough products available for sale without overstocking the business\. Anyone who has worked around supply chain systems understands the trade\-off\. Too little inventory means missed sales and unhappy customers\. Too much inventory means tied\-up capital, wasted warehouse capacity, and a business that becomes less flexible over time\. Then I added the capability that changed the entire experiment\. I allowed that agent to spawn subordinate AI agents when it determined that some part of the work would be better handled by a specialized agent\. These subordinate agents were not just copies of the original agent\. They were intended to carry out specific, narrowly defined groupings of work, with their own roles, personas, operating instructions, and assigned responsibilities inside the larger inventory management system\. That was the key design decision, and it was also the architectural mistake that made the experiment useful\. I did not tell the master agent exactly how many subordinate agents it could create\. I did not force it to use a fixed hierarchy\. I did not require human approval each time it wanted to split off a function\. I wanted to see what the system would do if it had a clear business objective, a useful set of tools, and the autonomy to decompose its own work into subordinate agents as it saw fit\. What I got was an object lesson in what I am calling agent sprawl\. ## Agent sprawl is the uncontrolled expansion of subordinate agents\. We already have a vocabulary for pieces of this problem\. The industry talks about multi\-agent systems, AI agent orchestration, agentic workflows, and sub\-agent spawning\. These are useful terms, and they describe real architectural patterns\. However, they do not fully describe what I saw in this test, because what emerged was not just a planned multi\-agent system\. It was an expanding population of subordinate agents created dynamically by other agents\. Agent sprawl is the uncontrolled or under\-governed expansion of AI agents inside an agentic system, where one agent spawns subordinate agents, and those subordinate agents are also permitted to spawn more subordinate agents, all in pursuit of the original business goal\. This does not necessarily happen because the agents are malfunctioning\. In fact, the opposite may be true\. It can happen because the agents are trying to optimize the system based on the goals and permissions they were given\. The first agent looked at the scope of inventory management and concluded that the work was too broad to be handled efficiently by one autonomous entity\. That was a reasonable conclusion\. Inventory management includes several related but distinct functions, and the agent determined that breaking those functions into specialized subordinate agents would make the overall system more efficient\. That was not irrational behavior\. That was architectural decomposition, except the system was doing it dynamically rather than waiting for a human architect to draw the boxes\. We decompose systems all the time\. We split monoliths into services, divide workloads into containers, isolate business domains, separate responsibilities, and create interfaces between components\. We do this because focused components are usually easier to optimize, monitor, secure, and improve\. The difference in this experiment was that I did not manually design the decomposition\. The agentic system did it itself, and it did it much faster than I expecte Figure 1: From a single inventory management agent to a hierarchy of specialized subordinate agents\.## The first agent decomposed the business function\. The first agent, which I called the master inventory agent, started with the broad inventory management objective\. It was responsible for understanding product availability, stock depletion, reorder points, purchasing needs, and the operational trade\-offs between carrying too much inventory and not carrying enough\. It had access to simulated inventory data, business rules, and a remote LLM, and it could reason about whether a certain grouping of work should remain centralized or be pushed to a subordinate agent\. It quickly identified inventory depletion management as a function that deserved its own subordinate agent\. That made sense because inventory depletion is not just watching stock counts decline\. It requires understanding historical sales velocity, seasonal patterns, supplier lead times, safety stock, product priority, margin implications, warehouse timing, and exception conditions\. It is a focused enough function to be managed by a specialized agent, but complex enough to justify some level of autonomy\. So the master inventory agent spawned an inventory depletion agent\. That subordinate agent’s role was narrow\. It watched stock movement, depletion curves, reorder signals, and products trending toward stockout conditions\. It evaluated minimum inventory thresholds and flagged cases where reorder points appeared to be too high, too low, or misaligned with recent sales behavior\. At this point, nothing looked alarming\. The system was behaving the way a good architecture should behave\. A broad function had been decomposed into a more focused function, and that focused function had a clear responsibility inside the larger inventory management process\. If I had stopped the experiment there, I would have called it a successful example of controlled agentic decomposition\. But the inventory depletion agent had the same basic capability as the master agent\. It was also allowed to determine whether parts of its own work should be split into subordinate agents\. It looked at depletion forecasting, reorder exception analysis, sales\-driven inventory signals, supplier timing, and replenishment risk, and concluded that several of those areas would benefit from their own focused agents\. The system was no longer just executing an inventory management process\. It was building an internal agent structure around that process\. That was the moment when the architecture stopped being static\. ## The architecture became dynamic\. Traditional enterprise systems are usually decomposed by architects, developers, platform engineers, and operations teams\. We decide what services exist, define the interfaces, create deployment units, build scaling rules, and determine what should be separated from what\. Even with microservices, containers, and orchestration platforms, the basic shape of the system is usually known ahead of time\. We may scale the number of instances, but we normally do not allow the system to invent entirely new functional entities whenever it thinks that would be useful\. In this experiment, the agentic system made those decisions dynamically\. The number of agents could change at runtime\. The hierarchy could change\. Responsibilities could shift\. Communication paths could emerge\. The cost profile could change because new agents meant new reasoning loops, new model calls, new memory requirements, and new monitoring requirements\. This is a very different kind of architecture from the systems most enterprises are used to operating\. A static multi\-agent system is one thing\. You define five agents, assign them roles, orchestrate their interactions, and observe the result\. That may still be complex, but at least the architecture is known\. A dynamic agent\-spawning system is something else entirely\. The architecture can evolve during execution, and that means the system can become more capable and more complex at the same time\. That is both the value and the risk\. If the system is allowed to spawn subordinate agents, it can adapt to complexity as the workload changes\. It can create focused agents around emerging problems\. It can shift from a general\-purpose structure to a more specialized structure without waiting for a development team to redesign the application\. However, if this is not governed, it can expand faster than anyone expects, and that is exactly what happened\. ## The first hour looked controlled\. During the first hour, the master inventory agent spawned four subordinate agents\. That seemed reasonable, and it was close to what I expected\. A broad inventory management function can logically split into several major areas such as depletion, purchasing, logistics, accounting, and sales signal analysis\. Four subordinate agents did not seem excessive\. In fact, it looked like the system had discovered a fairly normal functional decomposition\. The system held at roughly that level for about an hour and a half\. During that time, the subordinate agents refined their responsibilities, exchanged information, and started optimizing their assigned workflows\. The inventory depletion agent focused on stock movement and reorder risk\. The purchasing coordination agent focused on supplier timing and replenishment actions\. The logistics agent watched warehouse movement and inbound inventory status\. The accounting\-oriented agent reviewed valuation and reconciliation issues\. Then the second layer of agents started spawning their own subordinate agents\. This was not a bug because I had allowed it\. The first generation of subordinate agents had also been given the ability to create more specialized agents when they determined that a grouping of work would be better handled separately\. Three of the first four subordinate agents decided that they needed more focused agents underneath them, and the growth pattern became obvious\. The inventory depletion agent created agents for depletion forecasting, reorder exception analysis, and sales\-driven stock risk\. The purchasing coordination agent created agents for supplier timing, purchase order review, and replenishment risk\. The logistics agent created agents for warehouse movement, shipping delays, and inbound inventory status\. The agents were not spawning randomly\. They were decomposing work into smaller and smaller functional domains\. That was impressive\. It was also the point where I should have put a hard limit in place\. I did not, because the point of the experiment was to see what would happen without those limits\. That decision gave me the answer I was looking for, although not necessarily the answer I wanted\. ## The next morning I had 686 agents\. I let the system run overnight\. The agents did not have access to production systems, real purchasing systems, financial systems, supplier portals, or anything that could cause actual business damage\. They were running in a sandbox connected to a remote LLM and simulated business data\. The environment simulated a multi\-platform architecture using virtualization, but everything was physically running on a single platform\. When I checked the system the next morning, there were 686 agents running\. That number got my attention, but the more unsettling part was that the system was not collapsing\. It was not simply generating useless agents\. It was still carrying out the inventory management work, and several of the benchmarks had improved\. Inventory depletion decisions were more accurate, exception handling was more consistent, reorder logic was more refined, supplier timing analysis had improved, and sales signal interpretation became more granular\. That was the part that scared me\. If the system had failed, the lesson would have been simple\. I could have said that uncontrolled agent spawning creates chaos and should be avoided\. But the system did not fail\. It optimized\. The agents became more specialized, and that specialization improved the business function\. This is where agent sprawl becomes a more serious topic than a simple warning about runaway automation\. The system was not doing something obviously wrong\. It was doing something that appeared to be locally rational and globally useful\. The problem was that it was doing it without the governance, cost controls, lifecycle management, and architectural boundaries that would be required in any real enterprise system\. Figure 2: The overnight expansion from one master inventory agent to 686 subordinate agents\.## The agents optimized by narrowing responsibility\. The system discovered something architects already know: narrow responsibility often improves optimization\. A broad inventory management agent has to reason across depletion, purchasing, logistics, accounting, sales, suppliers, and exceptions\. That makes it flexible, but it also makes it general\. A subordinate agent focused only on supplier timing can optimize around that problem\. A subordinate agent focused only on reorder exceptions can optimize around that problem\. A subordinate agent focused only on sales\-driven stock risk can optimize around that problem\. Each subordinate agent could operate with a smaller context, a clearer objective, and a more focused operating loop\. This reduced the amount of reasoning each agent had to do across unrelated areas and allowed the agents to improve within narrower domains\. That is why the system improved\. The agents were not simply multiplying for the sake of multiplying\. They were specializing, and the specialization reduced the complexity of each individual agent’s task\. However, the same mechanism that improves performance can also create unbounded growth\. If every agent can improve its own outcomes by spawning more specialized subordinate agents, then the system has a built\-in bias toward expansion\. That bias may be rational from the perspective of each individual agent\. The problem is that thousands of locally rational decisions can produce a globally unmanageable architecture\. This is the core issue with agent sprawl\. It is not necessarily the result of bad agent behavior\. It can be the result of good agent behavior operating without architectural limits\. The agents are not breaking the rules\. They are following the rules too aggressively because the rules do not contain enough boundaries\. ## This is not the same as autoscaling\. It is tempting to compare this to autoscaling, but that comparison is only partially useful\. Traditional autoscaling creates more copies of an existing runtime component\. If traffic increases, we add more containers\. If message volume increases, we add more workers\. If compute demand increases, we scale the processing pool\. This is capacity scaling, and while it can be complicated, it is usually bounded by policies that architects and operators define\. Agent spawning is different because the system is not just creating more copies\. It is creating new functional entities with distinct roles, distinct responsibilities, and distinct decision boundaries\. Autoscaling asks, “How many instances do we need?” Agent spawning asks, “What new responsibilities should exist as separate autonomous units?” That is a much more powerful question, and it is much harder to govern\. If a container scales from 10 instances to 50 instances, you have a capacity event\. If an inventory depletion agent spawns agents for reorder exceptions, supplier timing, demand anomaly detection, seasonal forecasting, margin\-sensitive stock decisions, and warehouse prioritization, you have an architecture event\. The shape of the system has changed, not just its size\. That distinction matters because most enterprise controls are designed to manage scale, not autonomous functional growth\. That is why the governance model has to be different\. You cannot manage agent spawning as if it were just another infrastructure scaling policy\. You need controls around identity, purpose, cost, access, lineage, communication, observability, and termination\. Otherwise, you do not have an agentic architecture\. You have an agentic population explosion that happens to be executing business logic\. Figure 3: Traditional autoscaling creates more copies, while agent spawning creates more responsibilities\.## What we learned about unpredictability\. AI agents become much less predictable when they are given autonomy, tools, memory, feedback loops, and the ability to spawn subordinate agents\. That does not mean they become random\. It means their behavior emerges from how they interpret goals, constraints, context, available tools, and success measures\. You may know what you asked them to do, but that does not mean you know every path they will take to accomplish it\. Some people will object to this and say that we program agents, define prompts, select models, set up workflows, and control the tools\. That is all true, but it is also incomplete\. In a highly constrained workflow, behavior may be predictable enough for most business purposes\. Once agents can reason about their own performance and create subordinate agents to improve outcomes, the system begins to exhibit behavior that is much harder to anticipate\. The agents in my test did not violate the objective\. They interpreted it aggressively\. They were told to manage inventory efficiently\. They discovered that specialization improved efficiency\. They were allowed to spawn subordinate agents, so they did\. The system did not misunderstand the assignment\. It followed the assignment in a way I had not fully bounded\. That is the uncomfortable lesson for enterprise architects\. When agents have autonomy, the boundaries matter as much as the goals\. If the goal is clear but the boundaries are vague, the system may pursue the goal in ways that are technically valid and operationally surprising\. This is not a science fiction problem\. It is a requirements, architecture, governance, and operations problem\. ## What we learned about automated optimization\. The positive side of this experiment is that AI can now automate parts of architectural optimization that used to be manually designed\. For decades, architects have been responsible for decomposing systems\. We determined the services, processes, workflows, scaling models, and operational boundaries\. We decided what should be separated, what should be centralized, and what should be duplicated\. Agentic systems can now participate in that process, at least in limited and controlled ways\. The agents in this experiment did not merely execute business rules\. They reasoned about the structure of the work\. They determined that certain groupings of responsibility were too broad\. They created subordinate agents to handle narrower domains, and those subordinate agents improved performance through specialization\. This means agentic AI can potentially become an optimization layer for complex business systems, not just a task execution layer\. That is a meaningful architectural capability\. Instead of simply using AI to perform tasks, we can use AI to reason about how tasks should be distributed\. In complex environments such as supply chain, IT operations, security operations, and financial reconciliation, this could be useful\. A system that can create focused subordinate agents around emerging operational problems could respond faster than a static architecture\. However, automated optimization without automated governance is not architecture\. It is acceleration without brakes\. The faster the system can adapt, the more important it becomes to define what it is allowed to change, how much it is allowed to spend, what data it can access, how long subordinate agents can live, and who is accountable for the decisions those agents make\. ## The cost model can get ugly fast\. Every agent consumes something\. It may consume tokens, memory, CPU, storage, network bandwidth, observability capacity, or human attention\. Even if each agent is inexpensive, hundreds or thousands of agents can become expensive quickly\. In my experiment, I was dealing with a sandbox and simulated business data, but in a real enterprise environment the cost profile would become a first\-order architectural concern\. Many of the subordinate agents did not need a large frontier model for every task\. A lot of inventory work can be handled by small language models, deterministic logic, rules engines, or basic analytics\. You do not need an expensive LLM call to determine whether inventory has dropped below a threshold\. You may need more sophisticated reasoning when analyzing supplier instability, market changes, weather disruptions, tax implications, pricing shifts, exchange rates, or unusual demand patterns\. That means agent spawning needs a cost\-aware execution model\. Each agent should have a budget\. Each function should have a budget\. The system should know when a small model is sufficient and when a larger model is justified\. It should route work based on complexity, business value, and risk rather than allowing every subordinate agent to use the most expensive reasoning path available\. Otherwise, agent sprawl becomes not only an architecture problem, but a financial problem\. The first sign of failure may not be a crashed system\. It may be the invoice\. If enterprises are going to allow agents to spawn subordinate agents, then cost governance has to be designed into the architecture from the beginning rather than added later as an emergency control\. ## This is not new, but it is newly practical\. The ideas behind this are not entirely new\. We have been playing with versions of autonomous decomposition and distributed execution for decades through expert systems, distributed objects, actor models, service\-oriented architecture, grid computing, microservices, containers, and orchestration platforms\. The desire has always been the same\. We want systems that can distribute work, adapt to changing conditions, and optimize themselves\. The difference is that the enabling technology is now accessible\. The models exist\. The tools exist\. The cloud platforms exist\. The APIs exist\. The cost of experimentation is low enough that a single architect can build a prototype that would have required a serious lab environment not that long ago\. That changes the practical reality of what can be tested, deployed, and misused\. We are no longer asking whether systems can be made to spawn specialized autonomous components\. They can\. The more important question is whether we can govern them well enough to use that capability safely\. The answer today is that we probably can in some cases, but not casually and not without strong architectural discipline\. This matters because many enterprises will be tempted to move too quickly\. The demo will be impressive\. The productivity claims will sound attractive\. The first prototype may even work, just as mine did\. But production systems are not judged by whether they work once in a sandbox\. They are judged by whether they can operate securely, economically, predictably, and explainably under real business constraints\. ## The governance model needs to come first\. If I built this again, I would not start with the agent\. I would start with the governance model\. The system should have hard limits on the total number of agents, limits by function, limits by cost, and limits by risk class\. It should have policies that define when a subordinate agent can be spawned automatically and when human approval is required\. Every agent should have lineage\. If agent 686 exists, I should be able to trace it back to the master inventory agent and understand why each parent agent created the next level\. I should be able to see the business justification, assigned role, permissions, cost profile, active tools, model selection, and retirement criteria\. Without that lineage, the system becomes very difficult to audit, debug, secure, or explain\. I would also separate proposing a subordinate agent from activating one\. An agent should be able to recommend that a new subordinate agent would improve performance, but that does not mean the system should always activate it automatically\. For low\-risk read\-only functions, automatic activation may be acceptable\. For functions that touch purchasing, finance, customer commitments, supplier communication, or regulated data, approval should be required\. The governance model also needs retirement\. Agents should not live forever just because they were once useful\. The system needs to identify redundant, stale, low\-performing, or conflicting agents and shut them down\. If agents can spawn, the architecture also needs a way to prune\. Creation without cleanup is how sprawl becomes permanent\. ## The scary part is that it worked\. The most unsettling part of this experiment was not that the agents behaved badly\. They did not\. The most unsettling part was that they behaved reasonably\. They interpreted the goal, optimized around it, used the autonomy I gave them, specialized the work, and improved the business function\. They did exactly what the architecture allowed them to do\. The fault was not in the agents\. The fault was in the missing boundaries\. I assumed the system would create a few subordinate agents and then stabilize\. It created 686\. If I had let it run for a week, I might have had 10,000 agents, perhaps more\. Eventually, the system would have run into memory, processor, storage, or token limits\. I do not own a data center, and I do not want to fund one just to prove a point\. But resource exhaustion is only part of the concern\. The bigger issue is control\. Who owns each agent? What is each one allowed to do? What data can each one access? What decisions can each one make? What happens when agents disagree? What audit trail exists? What is the kill switch? If those questions do not have clear answers, the architecture is not ready for production\. This is why I came away both excited and concerned\. Agent spawning can produce specialization, parallelism, and optimization\. It can also create systems that expand faster than our ability to govern them\. The same capability that makes the architecture powerful also makes it risky\. ## The architectural pattern is powerful but dangerous\. This pattern has real potential\. Complex supply chain systems could use controlled subordinate agent spawning to handle specialized operational functions\. IT operations could use it to create incident\-specific diagnostic agents\. Security operations could use it to investigate threats through narrowly scoped subordinate agents\. Financial operations could use it for reconciliation, anomaly detection, audit preparation, and forecasting\. However, this should not be the default architecture\. For most business problems, a single well\-designed agent or a small fixed group of agents will be enough\. Dynamic agent spawning adds complexity, cost, governance overhead, and operational risk\. It should be used only when the complexity of the business problem justifies it and when the organization has the maturity to manage it\. When it is justified, it can be powerful\. The ability to let an AI system decompose work into subordinate agents is an architectural tool\. It can produce better specialization, more parallelism, and faster optimization\. But it can also create a system that grows beyond human understanding if the boundaries are weak\. The future of agentic AI is not just about smarter individual agents\. It is about managing populations of agents that can organize, specialize, spawn subordinate agents, and optimize their own work\. If we get that right, we gain a new architectural pattern\. If we get it wrong, we create software systems that expand faster than our ability to govern them\. Based on my little inventory management experiment, they will not wait for us to catch up\. ## References\. \[1\] IBM, “What is AI agent orchestration?” IBM defines AI agent orchestration as coordinating multiple specialized AI agents within a unified system to achieve shared objectives\. \[2\] GitHub, “What is AI agent orchestration?” GitHub describes agent orchestration as coordinating autonomous agents so they can plan, decide, act, and collaborate toward shared goals within defined constraints\. \[3\] Microsoft Azure Architecture Center, “AI agent orchestration patterns\.” Microsoft discusses design patterns for using multiple agents to break complex problems into specialized units of work or knowledge\. \[4\] Agentic Patterns, “Sub\-agent spawning\.” This pattern describes the creation of subordinate or specialized agents to handle focused work inside broader agentic systems\. Some AI tools used for the images and to edit this article\.