Role-Typed Subagents
Pre-allocating fixed roles (manager, coder, researcher) across a typed agent fleet before knowing what workloads will actually look like.
Intent & Description
🎯 Intent
Assigning each sub-agent a fixed role and restricted tool palette up front, then routing tasks by matching them to a role label.
📋 Context
The team designs the architecture before seeing real workloads. Manager, researcher, coder, designer — each gets its own system prompt and tool subset. Looks clean on the diagram. In practice, workloads don’’t fit the taxonomy, off-label tasks get squeezed into the nearest role, and “the coder agent team” becomes a political boundary that ossifies the system.
💡 Solution
Use one general-purpose sub-agent shape with the full tool palette. Let the orchestrator route by task content — not role label. When specialization pays, apply it per-call (prompt overlay + tool subset for this specific task) rather than per-agent-type. See clone-fan-out-research, role-assignment, supervisor.
Real-world Use Case
- Never as the architectural backbone; role labels are not free decomposition.
- Apply persona prompts as per-call overlays on general-purpose sub-agents, not as a fixed agent typology.
- Before adding a new typed sub-agent, ask if a general-purpose agent with a per-call overlay would do.
Source
📌 TL;DR
Apply personas as per-call prompt overlays on general-purpose sub-agents — never bake role types into your architecture.
Disadvantages
- Tasks outside the foreseen role table get squeezed into the nearest label — degrading quality
- Capability-equal parallelism is impossible by construction
- Adding a new role requires re-architecting rather than a parameter change
- Role labels invite team boundaries that ossify the system over time