Jump to content

Connect SuperML | Leeroopedia MCP: Equip your AI agents with best practices, code verification, and debugging knowledge. Powered by Leeroo — building Organizational Superintelligence. Contact us at founders@leeroo.com.

Principle:CrewAIInc CrewAI Managed Execution

From Leeroopedia
Revision as of 17:48, 16 February 2026 by Admin (talk | contribs) (Auto-imported from principles/CrewAIInc_CrewAI_Managed_Execution.md)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Overview

An execution pattern where a manager agent coordinates task completion by delegating subtasks to specialists and querying them for information using structured tool calls.

Description

Managed Execution is the runtime behavior of a hierarchical crew. The manager agent receives each task, reasons about which specialist is best suited, and uses DelegateWorkTool to assign work or AskQuestionTool to gather information. The manager identifies specialists by their role name. After receiving results, the manager may re-delegate, ask follow-up questions, or synthesize a final answer. This creates a dynamic execution flow that adapts to task requirements.

The execution proceeds through a repeating cycle for each task:

Phase 1: Task Reception

The manager agent receives a task (description, expected output, and any context from prior tasks). The task is presented to the manager's LLM along with a list of available specialists (by role name).

Phase 2: Reasoning and Planning

The manager's LLM reasons about the task requirements and available specialists. It decides:

  • Which specialist is most appropriate for the task (or for parts of the task).
  • Whether to delegate the full task or ask clarifying questions first.
  • Whether to break the task into multiple delegations.

Phase 3: Tool Execution

The manager invokes one of two tools:

  • DelegateWorkTool -- Assigns a specific task to a specialist identified by role name. The specialist executes the task and returns the result to the manager.
  • AskQuestionTool -- Sends a question to a specialist identified by role name. The specialist answers based on its expertise and tools, returning the answer to the manager.

Both tools take a coworker parameter (the specialist's role name), a task or question description, and optional context.

Phase 4: Result Evaluation

The manager receives the specialist's response and evaluates it against the task requirements. The manager may:

  • Accept the result -- If the output meets the expected output criteria, the manager synthesizes a final answer for the task.
  • Re-delegate -- If the result is insufficient, the manager can delegate again to the same or a different specialist with additional instructions.
  • Ask follow-up questions -- The manager can query the specialist (or a different one) for clarification or additional information.
  • Synthesize across multiple delegations -- For complex tasks, the manager may delegate to multiple specialists and combine their outputs into a cohesive result.

Phase 5: Task Completion

The manager produces a final output for the task. This output becomes available as context for subsequent tasks (if they reference this task in their context field). The cycle then repeats for the next task.

Theoretical Basis

This principle is grounded in the Tool-Augmented LLM Agent pattern, specifically the ReAct (Reasoning + Acting) paradigm. In ReAct:

  1. The agent observes the current state (task description, available tools, prior context).
  2. The agent thinks about what action to take (which specialist to delegate to, what to ask).
  3. The agent acts by invoking a tool (DelegateWorkTool or AskQuestionTool).
  4. The agent observes the tool's result and decides whether to take another action or finalize.

This loop continues until the agent is satisfied with the result. The delegation tools are the actions available to the manager in this ReAct loop, and the specialists' responses are the observations that inform the next reasoning step.

The key insight is that the manager does not execute tasks using its own knowledge -- it acts as a coordinator that leverages specialist capabilities through structured tool calls, much like a project manager who delegates work to team members and reviews their outputs.

Constraints

  • Manager LLM quality matters -- Poor reasoning by the manager leads to suboptimal delegation, wasted iterations, and lower-quality outputs. A capable LLM (GPT-4 class or better) is recommended.
  • Role name matching must be accurate -- The manager identifies specialists by role name in tool calls. If the role name in the tool call does not match any specialist, the delegation fails. The framework uses fuzzy matching to mitigate minor discrepancies.
  • Iteration limits apply -- The manager agent has a max_iter limit that caps the number of reasoning steps. If the manager exhausts its iterations without completing a task, it produces a best-effort result.
  • No direct specialist-to-specialist communication -- All communication flows through the manager. Specialists cannot delegate to or query each other.
  • Cost considerations -- Each delegation or question is an additional LLM call (for both the manager's reasoning and the specialist's execution). Complex tasks with many delegations can be expensive.

Related Principles

  • Specialist Agent Definition -- The workers that receive delegated tasks.
  • Manager Agent Configuration -- The coordinating agent that drives the execution.
  • Task Definition Hierarchical -- The task specifications that the manager receives and routes.
  • Hierarchical Crew Assembly -- The crew composition that enables managed execution.

Implementation:CrewAIInc_CrewAI_Delegation_Tools

Page Connections

Double-click a node to navigate. Hold to expand connections.
Principle
Implementation
Heuristic
Environment