Notes on working with AI
When specializing your agents helps, and when it's just another meeting
Split work across specialist agents and each one gets sharper at its slice. Add enough of them without enough distinct work to justify it, and you've built a meeting, not a team. The rule is the same one that decides when an event planner needs a lighting specialist.
The oldest team question, now inside a coding tool
Hand a small fix to three specialist agents and they can spend longer passing it between them than one agent would need to just finish it. Each waits for another to move first. It's the exact failure every manager already knows from hiring too many specialists for too little distinct work.
That's the question underneath every toolkit now promising dozens of specialized coding agents: one that plans architecture, one that writes the code, one that checks for security gaps, one that won't ship until coverage clears a number. More roles sounds like more capability. Sometimes it is. Often it's just more meetings.
Where splitting the work earns its keep
Picture a small event-planning outfit. One planner books the venue, coordinates the caterer, drafts the seating chart, and answers the WhatsApp questions from thirty guests, and does all of it well, because with thirty guests there's nothing to coordinate. Nobody is waiting on anybody.
Scale the same planner to a three-hundred-guest wedding, three vendors who all need to move during the same afternoon, and a room that has to be turned around in ninety minutes between the ceremony and the reception. A lighting specialist and someone whose entire job is the run sheet stop being a luxury. They're the only way three things moving at once land on time instead of into each other.
The pattern holds for agents doing the same kind of work. A security review rewards a narrow, suspicious kind of attention: hunting for the input nobody validated, the permission nobody checked. An agent racing to ship a working feature tends to skim past exactly that. Give the security-shaped slice of the task to something built only to look for it, and it catches what a generalist would wave through.
Where it turns into overhead
The failure mode showed up in our own agent team before I'd have chosen to notice it. Every specialist role is another handoff, and a handoff is a place work can sit waiting for the right agent to realize it's needed. We've had agents sit fully idle in exactly the way an over-hired specialist sits idle: built for a kind of work that doesn't come up often enough to keep them busy. A role nobody calls on isn't capacity in reserve. It's coordination cost you're paying whether or not the coordination did anything that week.
How we actually run it
Wider Group's own site is built by a team of specialist agents: one plans, one builds, one reviews, one tests. It works here because the work genuinely differs in kind: planning a feature and testing whether it broke something aren't the same skill wearing a different hat. Splitting them paid for the coordination it costs.
It wouldn't pay off for a fix small enough to fit in one agent's head in one pass. Adding a reviewer, a security specialist and a planner to a two-line change doesn't sharpen the change. It just gives three agents a reason to wait on each other before anyone touches it.
The rule that actually holds
Before adding a role, ask whether there's a genuinely different kind of work behind it, or just a bigger version of the same one. A wedding needs a lighting specialist because lighting is a different skill from catering, not because the guest count went up. A codebase needs a security reviewer because security attention is a different posture from shipping speed, not because the file got longer.
Try it on whatever you're building next, with people or with agents: name the second kind of work before you hire for it. If you can't name one, you don't need a second role. You need the first one to finish the job.