Why 100 Agents? Skill Engineering in a Production Agent Swarm (Part 2)
My second Hacker Noon article is live. It picks up where Part 1 left off and goes deeper on the piece that turned out to matter most: skills.
The question I keep getting: why 100+ agents?
Better question: why do you have 100 utility functions? Nobody plans to write 100 utility functions. You write one to avoid repeating a date formatter. Then another to normalize API responses. Each one exists because you noticed a repeated pattern and extracted it. That’s DRY. That’s good engineering.
My agent system reached 100+ the same way. Not by design. By refactoring. Every agent started as a repeated prompt that was expensive to re-explain. DRYP — Don’t Repeat Your Prompt — applied to the new medium.
The article covers:
- Why skills work — precompiled expertise vs. raw prompting
- SkillsBench data — 7,308 agent runs proving 2-3 focused skills is the sweet spot (a $0.04 model with skills outperforms an $8 model without)
- Managing 100+ skills — hierarchy, not chaos. I talk to 8-10 directly; they delegate the rest
- The person-risk-analyzer — a full skill lifecycle from personal tool to company-wide Slack bot
- The three-stage payoff — custom skill -> engineering artifact -> business tool
The core finding: the skill is the product. The model is just the runtime.