Every agent you add makes every other agent more expensive
When you deploy your first agent -- a morning planning routine, say -- the cost is simple: the time to run it plus the time to maintain it. There is no coordination cost because there is nothing to coordinate with. The agent exists in isolation, and its value equation is straightforward.
When you add a second agent -- an evening review routine -- a new cost appears. The evening review needs to know what the morning plan contained. The morning plan should eventually incorporate patterns the evening review surfaces. Now you have two agents and one coordination link between them. The cost is still small, probably a few minutes of cross-referencing.
When you add a third agent, you don't add one more coordination link. You add two -- the third agent must coordinate with both the first and the second. A fourth agent adds three new links. A fifth adds four. The pattern is described by a formula that project managers and software engineers know well: for n agents, the number of potential coordination channels is n(n-1)/2. Five agents produce ten channels. Ten agents produce forty-five. Twenty agents produce one hundred and ninety.
The growth is not exponential in the strict mathematical sense -- it is quadratic -- but the practical effect feels exponential to the person living inside the system. Each new agent adds a linearly increasing number of new coordination relationships, and the total coordination burden accelerates far faster than the total value produced. This is the fundamental cost of agent sprawl: value grows linearly with each new agent, but coordination costs grow quadratically.
Brooks's law and the mythical man-agent
In 1975, Fred Brooks published The Mythical Man-Month, drawing on his experience managing the development of IBM's OS/360. His central observation has become one of the most cited laws in software engineering: "Adding manpower to a late software project makes it later." The mechanism is coordination overhead. Each new person added to a team must be brought up to speed by existing members, temporarily reducing their productivity. And the new person creates communication channels with every existing team member, increasing the total coordination burden on everyone.
Brooks noted that bugs cluster at the interfaces between code written by different people. The same principle applies to your cognitive agents. Failures cluster at the handoff points -- where the output of one agent becomes the input of another. Your morning plan tells you to block two hours for deep work. Your calendar management agent has already accepted a meeting in that window. Your energy tracking agent flags that your best deep-work hours are in the afternoon, not the morning. Each agent is functioning correctly within its own scope. The conflicts arise at the interfaces, and each new agent creates more interfaces.
The deeper lesson from Brooks is that coordination costs are not merely additive -- they are multiplicative, because coordination itself requires coordination. When you resolve a conflict between your planning agent and your calendar agent, you generate a decision that your energy tracking agent needs to know about. Managing the interactions between agents becomes its own task, one that grows faster than the agents themselves.
The microservices parable
The software industry spent the 2010s enthusiastically decomposing large applications into microservices -- small, independent services that each handle one function. The logic was compelling: smaller services are easier to understand, easier to deploy, and easier to scale independently. Each service, in isolation, was simpler than the monolith it replaced.
But isolation was an illusion. The services had to communicate. They had to share data. They had to handle failures in services they depended on. What had been function calls within a single application became network requests between services, each one introducing latency, failure modes, and versioning complexity. A 2025 CNCF survey found that 42 percent of organizations that adopted microservices are now consolidating services back into larger deployable units. Industry analyses estimate that at enterprise scale, microservices architectures cost $40,000 to $65,000 per month to operate compared to $15,000 for equivalent monolithic deployments -- and the difference is almost entirely coordination overhead: observability infrastructure, service mesh management, cross-service debugging, and the platform teams required to keep it all running.
The microservices story is the agent sprawl story told at industrial scale. Each microservice, like each cognitive agent, justified its existence individually. The cost was collective. And the organizations that recognized it earliest were the ones that started asking a question most agent-builders never ask: what is the coordination cost of adding this to the system?
Coase's limit: why systems stop scaling
The economist Ronald Coase asked a deceptively simple question in his 1937 paper "The Nature of the Firm": if markets are efficient, why do firms exist at all? His answer was transaction costs -- the overhead of negotiating, contracting, and enforcing agreements on the open market. Firms exist because, below a certain scale, it is cheaper to coordinate work internally through management than externally through market transactions.
But Coase also identified the limit. A firm will expand until the cost of organizing one more transaction internally equals the cost of conducting that transaction on the market. Beyond that point, growth makes the organization slower, not faster. Internal coordination costs -- administrative overhead, communication delays, the difficulty of preventing unproductive behavior -- rise with every additional activity the firm absorbs.
Oliver Williamson extended this insight, identifying bounded rationality as a key constraint: managers cannot hold the full complexity of a large organization in their heads, so coordination becomes increasingly approximate as the system grows. Decisions get worse because the decision-maker's model of the system becomes less accurate.
Your cognitive infrastructure follows the same pattern. You are the manager of your agent portfolio, and your rationality is bounded. You can hold five or six agents in your head with reasonable fidelity -- understanding their inputs, outputs, dependencies, and current state. Beyond that, your model of your own system starts to degrade. You forget which agents depend on which. You lose track of which outputs feed which inputs. You make changes to one agent without considering the downstream effects on three others. The system is still running, but your ability to manage it has been exceeded. You have crossed your personal Coase limit.
The attention tax: what sprawl costs you cognitively
Research on tool proliferation in workplaces quantifies the cognitive cost of managing too many systems. A 2022 study found that the average digital worker toggles between applications nearly 1,200 times per day, and 45 percent of workers report that switching between too many tools makes them less productive. The recovery cost is substantial: it takes an average of 9.5 minutes to regain productive workflow after switching to a different application. Workers lose the equivalent of five working weeks per year to context-switching overhead alone.
These numbers describe tool sprawl in professional settings, but the mechanism is identical to agent sprawl in personal cognitive infrastructure. Every agent you maintain demands a context switch: you must load its current state into working memory, evaluate its output, decide on any necessary adjustments, and then unload that context before switching to the next agent. The switching cost is not the time to physically check the agent -- it is the cognitive overhead of reorienting your attention.
Decision fatigue compounds the problem. Research on cognitive depletion shows that each decision you make draws from a limited pool of executive function resources. Every agent in your portfolio generates decisions: Is this output acceptable? Does this conflict with another agent's output? Should I intervene or let it run? A portfolio of fifteen agents generating two decisions each per day produces thirty additional decisions layered on top of everything else your day demands. You do not experience these as a single burden of "thirty decisions." You experience them as a pervasive background drain -- the feeling that your day is full of small obligations before you have done anything meaningful.
The paradox of individual value
The most insidious feature of agent sprawl is that every agent in the portfolio can be individually justified. Each one, evaluated in isolation, produces more value than it costs to operate. The morning planning agent saves you twenty minutes of scattered prioritization. The reading curation agent surfaces articles you would have missed. The relationship maintenance agent keeps you from losing touch with people who matter to you. If you evaluate any single agent and ask "is this worth keeping?", the answer is almost always yes.
This is why sprawl persists. The evaluation frame is wrong. The question is not whether each agent is worth keeping in isolation. The question is whether the marginal agent is worth keeping given the coordination costs it imposes on the entire system. An agent that produces ten minutes of value but adds fifteen minutes of coordination overhead across the rest of your portfolio is a net loss -- even though it would be a net gain if it were the only agent you operated.
Software engineers recognize this pattern as feature bloat. Studies show that nearly 45 percent of software features are rarely or never used, yet they persist because each feature was justified at the time of its creation. The evaluation happened at the moment of addition -- "will this feature help some users?" -- rather than at the level of the whole product -- "does this feature make the product better or worse for the typical user?" Microsoft Word accumulated thousands of features over decades while the average user touched about 5 percent of them. The features were not individually wrong. The system they formed was collectively unwieldy.
Your agent portfolio can become your personal Microsoft Word: technically capable of everything, practically optimized for nothing.
Amdahl's limit on parallel agents
Gene Amdahl formalized an important constraint on parallel processing in 1967: the speedup achievable by adding more processors is limited by the fraction of the work that must be done sequentially. If 20 percent of a task cannot be parallelized, then no number of additional processors can produce more than a five-times speedup. Adding processors beyond a certain point produces no measurable improvement because the sequential bottleneck dominates.
Neil Gunther later extended this insight to account for coordination overhead between processors. In Gunther's universal scalability law, adding processors eventually makes the system slower, not just flat -- because the coordination costs between processors grow faster than the parallel processing benefits. There is a point of negative returns, where each additional processor degrades total performance.
Your cognitive agents are parallel processors. Each one handles a domain of your life in parallel with the others. But some fraction of your cognitive work is inherently sequential -- you can only make one decision at a time, you can only direct attention to one thing at a time, and you must periodically synchronize the outputs of all your agents into a coherent picture of your priorities. That synchronization is your sequential bottleneck. Adding more agents does not reduce it. Beyond a certain point, adding more agents increases it, because each new agent generates more outputs that must be synchronized through the same single-threaded process: your conscious attention.
The pruning threshold
Agent sprawl has a diagnostic signature. You can feel it before you can measure it: the sensation that your infrastructure is running you rather than the reverse. You spend more time maintaining agents than benefiting from their outputs. You have agents whose outputs you haven't checked in weeks. You have agents that conflict with each other and you resolve the conflicts by ignoring one of them. You have agents you cannot clearly describe the purpose of without looking it up.
The quantitative test is the coordination ratio: total coordination costs divided by total value produced. When coordination costs are below 20 percent of total value, your system is lean. When they reach 30 percent, you are approaching the threshold. When they exceed 40 percent, you have crossed it -- your agents are spending more of your attention on their own maintenance than on producing value for you.
The response is not to dismantle everything. It is to prune. Identify agents with the worst value-to-coordination-cost ratio. Look for agents that overlap -- two routines that partially accomplish the same function, each adding coordination overhead but not enough unique value to justify the duplication. Look for agents that once served a purpose that no longer exists -- the habit you built for a job you no longer hold, the tracking system for a goal you achieved six months ago. Retirement criteria, covered in earlier lessons in this phase, provide the framework. The cost of sprawl provides the motivation.
From cost awareness to lifecycle awareness
Understanding that sprawl has a cost is necessary but not sufficient. Knowing that your portfolio has too many agents tells you to prune, but it does not tell you which agents to prune, when to prune them, or how to distinguish agents that have completed their purpose from agents that are still maturing.
The next lesson introduces agent lifecycle awareness -- the practice of maintaining a conscious, current map of where each agent sits in its lifecycle. Some agents are newly deployed and still in their critical first thirty days. Some are in stable maintenance mode, producing reliable value with minimal oversight. Some have been gradually degrading and are candidates for evolution or retirement. Some have completed the task they were built for and should have been retired weeks ago but persist because no one actively decided to stop them.
Without lifecycle awareness, pruning is reactive and emotional. You retire the agent that annoyed you most recently, not the one that contributes least. You keep the agent you invested the most effort in building, not the one that produces the most value. Lifecycle awareness replaces gut reactions with a systematic view -- one that lets you manage your agent portfolio the way Coase described effective firms: expanding when internal coordination is cheaper than the alternative, contracting when it is not.