# Role-Typed Subagents

> Pre-allocating fixed roles (manager, coder, researcher) across a typed agent fleet before knowing what workloads will actually look like.

- **Category**: Agentic AI
- **Subcategory**: Anti-Patterns
- **Canonical URL**: https://designpattern.fyi/patterns/role_typed_subagents/

---

## 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.



## Use Cases
- 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.






## Trade-offs




### Considerations & Drawbacks

- 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







---
**Reference**: [Original Source](https://www.agentpatternscatalog.org/patterns/role-typed-subagents/)