Essay · August 7, 2026
Why breadth is free now, and what that changes
"Do one thing well" is good advice about tools whose cost you pay whether or not you use them. That was every tool, for the whole history of the advice. It stops being automatically true the moment a capability can sit installed and dormant for a month at a cost of one line, and most instincts about scope haven't caught up.
The old arithmetic
A broad tool used to be worse than a focused one for concrete reasons. More surface to learn. More menu to search. More code to load. Every user paid for every feature, so features aimed at other people were pure cost to you, and the discipline of cutting scope was the discipline of respecting that.
Under progressive disclosure the arithmetic changes. The agent holds a name and a description for each skill and nothing else until a request matches. So the marginal cost of the skill you never use collapses to roughly a sentence, while the marginal benefit stays whatever it's worth on the day you need it.
When the marginal cost of an unused capability approaches zero, "does this belong in the same tool" stops being the interesting question. The interesting question becomes whether the capability is worth having at all.
What that permits
Mostly it permits keeping things a scope-discipline instinct would have cut. The same install that runs an A-F code review with OWASP and deploy-risk checks also runs a design and visual-QA pass on the screen you just shipped, an SEO and answer-engine audit on the page describing it, and a rights-and-royalty prep pass on a music release. None of those tax the others. Four capabilities, four descriptions, one loaded at a time.
The far end of that range is amazon-returns-recovery, and it is the honest test of the argument, because it is the skill most obviously "not a developer tool." It audited a real account and recovered $448.31 across three documented cases, including a $372.69 refund that had already been denied.
Under the old arithmetic that skill has no defense. It has nothing to do with code, it would be dead weight in the menu, and shipping it alongside a code reviewer would be a category error. Under the new one it costs a sentence until the day it pays for itself several hundred dollars over.
The category that opens up
Look at why the returns case works and it isn't technical difficulty. Mechanically it's evidence gathering, policy research, and patient support correspondence. A person could do all of it. The reason a person often doesn't is that it's tedious, mildly adversarial, spread over days, and structured so that giving up is the path of least resistance. The counterparty is, to put it gently, not optimizing for your persistence.
That describes a large category: subscription cancellations, warranty claims, billing disputes, rights paperwork, anything where the work is not hard but the process is designed to outlast you. These tasks were never worth building dedicated software for, because the software would cost more than the recovery. As a skill, one of them costs a description.
So the useful filter stops being "is this in scope for a dev tool" and becomes "is this a task I keep abandoning." Those are very different questions, and the second one has better answers.
The condition
None of this licenses hoarding. Breadth is free in context and it is not free in routing: every added skill is one more candidate that could fire on the wrong request, which is what explicit NOT FOR boundaries exist to prevent. The two properties are load-bearing together and neither survives alone. Progressive disclosure without boundaries is a pack that costs nothing and picks wrong. Boundaries without progressive disclosure is a pack that picks correctly and costs too much to keep.
With both, the count stops being the thing to optimize. Seventy-one is not a claim about ambition. It's just what happens when you stop deleting useful things to protect a budget you no longer spend.