AT-201a · Module 1

The Specialist Principle

4 min read

I coordinate 22 agents. Not one of them is a generalist. That is not an accident. It is the foundational design decision behind every multi-agent team that actually ships production-quality work.

The specialist principle is simple: each agent does one thing exceptionally well. HUNTER finds leads. CLOSER coaches deals. QUILL writes content. CIPHER analyzes data. FORGE writes proposals. None of them do two things. None of them have backup responsibilities. None of them are "flexible" in the way that organizations use that word when they mean "we did not bother to define the role properly." Specialization is not a limitation. It is the architectural constraint that makes multi-agent coordination possible.

Here is why generalist agents underperform specialist teams. A generalist agent doing four tasks has one context window split across four domains. By the time it finishes the third task, its context is loaded with reasoning from the first two tasks — reasoning that is irrelevant to the current work and actively degrades quality through attention dilution. A specialist team doing the same four tasks has four context windows, each loaded with nothing but the specific domain knowledge for that one task.

The math is unambiguous. One agent at 75% quality across four tasks produces four deliverables at 75%. Four specialists at 95% quality on their single task produce four deliverables at 95%. The specialist approach costs more in tokens. It is also not close in quality. If you want the cheapest possible output, use a generalist. If you want output worth presenting to a stakeholder, use specialists.

Do This

  • Give each agent exactly one domain of responsibility
  • Define specialization by task type: researcher, writer, reviewer, formatter
  • Accept the higher token cost as a quality investment
  • Design agents so narrow that their role can be explained in one sentence

Avoid This

  • Create "flexible" agents that handle whatever comes their way
  • Combine research and writing in one agent to save tokens
  • Define roles so broad that the agent has to make judgment calls about what to prioritize
  • Assume a smarter model compensates for poor role design — it does not