Principle:CrewAIInc CrewAI Manager Agent Configuration
Overview
A coordination pattern for configuring a manager agent that receives all tasks, decides which specialist to delegate to, and aggregates results across a team of workers.
Description
Manager Agent Configuration establishes the coordinating authority in a hierarchical crew. The manager receives all tasks, uses delegation tools (DelegateWorkTool, AskQuestionTool) to route work to specialists by their role names, reviews returned results, and may re-delegate or ask follow-up questions. The manager can be auto-created from a provided LLM or explicitly configured as a custom Agent with specific instructions.
The manager agent occupies a unique position in the hierarchy:
- It is the sole entry point for all tasks -- every task flows through the manager before reaching any specialist.
- It has delegation tools automatically assigned -- the framework ensures the manager always has DelegateWorkTool and AskQuestionTool, regardless of how it is configured.
- It has allow_delegation forced to True -- even if explicitly set to False, the framework overrides this for the manager, since delegation is its core function.
- It does not execute tasks directly (by design) -- the manager's role is to coordinate, not to perform the specialized work itself.
There are two distinct approaches to configuring a manager:
Auto-Created Manager
The developer provides only a manager_llm (a model identifier string or LLM instance) to the Crew. The framework automatically creates a manager agent with a generic "Crew Manager" role, a coordination-focused goal, and the delegation tools. This approach is suitable when the manager's behavior does not need customization beyond selecting the LLM.
Custom Manager
The developer provides a fully configured manager_agent (an Agent instance) to the Crew. This allows fine-grained control over the manager's role name, goal, backstory, and any additional tools or configuration. The framework still ensures delegation tools are present and allow_delegation is True, regardless of what the developer specifies.
Theoretical Basis
This principle is grounded in the Mediator Pattern from software design (Gang of Four). The mediator pattern defines an object that encapsulates how a set of objects interact. Instead of objects communicating directly with each other, they communicate through the mediator.
In the hierarchical crew:
- The manager is the mediator.
- The specialists are the colleagues that interact only through the mediator.
- Tasks are the requests that flow through the mediator to the appropriate colleague.
This pattern offers several advantages:
- Reduced coupling -- Specialists do not need to know about each other; they only interact with the manager.
- Centralized control -- The manager can implement complex routing logic, retry strategies, and result aggregation.
- Flexibility -- New specialists can be added or removed without affecting other specialists, only the manager's awareness changes.
Constraints
- Exactly one manager per hierarchical crew -- multiple managers would create conflicting coordination.
- Either manager_agent or manager_llm must be provided -- the framework validates this at crew initialization and raises an error if neither is specified for a hierarchical process.
- Both cannot be provided simultaneously -- if manager_agent is set, manager_llm is ignored (with a potential warning).
- The manager's LLM should be capable -- since the manager must reason about task requirements and specialist capabilities, a more capable model (e.g., GPT-4 class) is recommended.
Related Principles
- Specialist Agent Definition -- The worker agents that the manager coordinates.
- Hierarchical Crew Assembly -- The crew-level composition that brings manager and specialists together.
- Managed Execution -- The runtime behavior where the manager actively delegates and queries.