Agent Task Auto-Decomposition Logic Development · cfgnotes

1. Introduction

As large model-driven agents are gradually deployed in enterprise production environments, a common problem emerges: With the same underlying large model, why can some agents efficiently complete complex tasks while others get stuck in infinite loops from the very first step? The core difference often lies not in the model itself, but in the ability of automatic task decomposition — whether a vague, complex goal can be broken down into an executable, verifiable sequence of subtasks.

This article starts from the practical needs of enterprise-grade AI agent deployment, focusing on complex task automatic decomposition as a core capability. It systematically introduces decomposition strategies, ReAct framework implementation, multi-agent collaboration, and practical code. After reading this article, you will master: Agent task automatic decomposition methods, subtask planning implementation code, ReAct framework task decomposition, multi-agent collaboration task allocation, agent role persona design, task logic orchestration in practice, and key points for optimizing agent tool calls.

2. Core Concepts and Design Principles of Task Decomposition

2.1 What is Task Decomposition

Task Decomposition is the process of breaking a complex goal into multiple manageable, executable subtasks. In enterprise-grade agent systems, this typically appears as a three-layer structure:

• Goal Layer: The raw requirement input by the user, e.g., “Analyze this quarter’s sales data and generate a report”
• Subtask Layer: Clear and actionable steps generated by the agent’s planning module, e.g., “Extract data - Clean data - Calculate metrics - Write report”
• Action Layer: Actual tools or APIs invoked for each subtask, e.g., SQL queries, Python calculations, document generation

2.2 Key Design Principles

2.2.1 Granularity Control Principle

The granularity of subtasks directly affects execution efficiency and stability. Practical experience shows:

• Too fine: Generates a large number of micro-tasks; the model incurs high switching costs between tasks and easily falls into infinite loops
• Too coarse: The subtask itself remains complex, making it difficult for the agent to complete in one go

Recommended granularity criterion: A subtask should be completable within 3-5 tool calls, and its result should have a clear verification standard.

2.2.2 Dependency Modeling

There are three basic dependency types among subtasks:

• Sequential dependency: B depends on A’s output, e.g., “Clean data” must come after “Extract data”
• Parallel no dependency: A and B can be executed simultaneously, e.g., querying different data sources at the same time
• Conditional branching: Whether to execute B depends on the result of A

Practical advice: Explicitly declare dependency types in the task structure definition to avoid the model guessing during inference.

2.2.3 Traceability and Exception Handling

After each subtask is executed, the following should be recorded:

• Execution status (success/failure/timeout)
• Output summary (key results, not full data)
• Exception information (to facilitate subsequent adjustments or human intervention)

The design principle is “fail early, feedback fast” — if a subtask cannot be completed, interrupt as early as possible and return a fix suggestion, rather than continuing to execute downstream tasks.

3. Dynamic Task Decomposition Based on the ReAct Framework

3.1 Core Mechanism of the ReAct Framework

The ReAct (Reasoning + Acting) framework is the basic pattern for current mainstream agent task planning. Its core loop consists of three steps:

1. Reasoning: The model analyzes the current state, synthesizes task goals, history, and available tool information, and decides on the next action
2. Acting: Invokes the selected tool or API to perform an operation
3. Observing: Obtains the tool execution result as input for the next round of reasoning

This loop executes at each subtask level until the task is completed, the maximum number of steps is reached, or an unrecoverable error occurs.

3.2 Static Decomposition vs. Dynamic Decomposition

Dimension	Static Decomposition	Dynamic Decomposition (ReAct)
Task sequence	Fully determined before execution	Dynamically adjusted based on intermediate results
Dependency handling	Preset fixed order	Adaptive handling
Exception adaptation	Poor, requires manual rework	Good, can re-plan
Execution efficiency	High, no extra reasoning overhead	Slightly lower, requires repeated model reasoning

Scenario selection:

• For fixed-process scenarios (e.g., fixed data processing pipelines), static decomposition is more efficient
• For open-ended questions or scenarios where results depend on the execution process (e.g., code debugging), dynamic decomposition is more reliable

3.3 Dynamic Adjustment Example

Suppose the user asks “Analyze customer feedback data and output a visualization report.” A ReAct agent might go through the following dynamic adjustments:

Reasoning: This is a data analysis and report generation task. First, check the data source.
Action: Call list_files() to view available files.
Observation: Found two CSV files: feedback_2024.csv and feedback_2023.csv

Reasoning: Need to process the data for each year separately, then aggregate and compare.
Action: Execute clean() -> analyze() for each file.
Observation: Analysis complete. Found 5% abnormal records in 2024 data.

Reasoning: The anomaly rate is high; need to clean the abnormal data first.
Action: Call filter_outliers()
... (subsequent adjustments)

3.4 Crash Handling and Fallback Strategies

Two common crash patterns during dynamic decomposition and their handling:

• Reasoning loop: The model repeatedly thinks about the same state without taking substantive action. Solution: Set a maximum number of ReAct steps (e.g., 10). After timeout, fall back to a simplified plan.
• Wrong tool selection: The model selects an inappropriate tool (e.g., using a statistical tool for text processing). Solution: Design a tool call validation module to check input/output type matching.

4. Implementation Code for Subtask Planning (Examples and Explanations)

4.1 Basic Implementation: Simple ReAct Agent

The following example shows a subtask planning logic based on rule matching:

from typing import List, Dict, Optional
import re

class ReActAgent:
    """
    Simple ReAct Agent implementation
    Core logic: Match user input to predefined task templates, generate a sequence of subtasks
    """
    
    def __init__(self, rules: Dict[str, List[str]]):
        """
        Initialize rule base
        :param rules: mapping from task type -> list of subtasks
        """
        self.rules = rules
        self.execution_history = []
    
    def plan(self, task: str) -> List[str]:
        """
        ReAct loop: Reason -> Act -> Observe, decompose the task
        :param task: raw task input by the user
        :return: list of subtasks
        """
        thoughts = []
        subtasks = []
        
        # ReAct loop, attempt up to 5 steps
        for step in range(5):
            # Reasoning phase: match task type
            matched_rule = None
            for pattern, steps in self.rules.items():
                if re.search(pattern, task, re.IGNORECASE):
                    matched_rule = pattern
                    matched_steps = steps
                    break
            
            if matched_rule:
                # Action: adopt subtasks generated by the rule
                subtasks = matched_steps.copy()
                thoughts.append(f"Identified task type: {matched_rule}")
                self._log_execution(f"Step {step}: Matched rule {matched_rule}")
                break
            else:
                # Action: no rule matched, use generic splitting
                parts = re.split(r'[,，。\n]', task)
                subtasks = [p.strip() for p in parts if len(p.strip()) > 5]
                thoughts.append("No specific rule matched, using generic splitting")
                self._log_execution(f"Step {step}: Using generic splitting")
                break
        
        self.execution_history.append({
            "task": task,
            "thoughts": thoughts,
            "subtasks": subtasks
        })
        
        return subtasks
    
    def _log_execution(self, message: str):
        """Internal logging for debugging and traceability"""
        print(f"[ReAct Log] {message}")

# Usage example
rules = {
    "Data Analysis": ["Collect raw data", "Perform data cleaning", "Statistical analysis of metrics", "Generate visualization report"],
    "Code Writing": ["Design architecture plan", "Implement functionality", "Unit test coverage", "Perform code review"],
    "Customer Complaint Handling": ["Record complaint details", "Classify problem type", "Provide solution", "Track resolution result"]
}

agent = ReActAgent(rules)
result = agent.plan("Please perform data analysis: extract sales data from the database and generate a report")
print(result)
# Output: ['Collect raw data', 'Perform data cleaning', 'Statistical analysis of metrics', 'Generate visualization report']

4.2 Enhanced Version: Dynamic Subtask Generation

In production, rule matching has limited coverage, requiring model-driven dynamic decomposition:

class DynamicAgent:
    """
    Agent supporting dynamic decomposition
    Combines rule matching and model reasoning strategies
    """
    
    def __init__(self, model_api_callable, rules: Dict[str, List[str]]):
        self.model = model_api_callable  # Large model API callable
        self.rules = rules
    
    def decompose_task(self, task: str, context: Optional[str] = None) -> List[str]:
        """
        Dynamically decompose a task
        1. First attempt rule matching
        2. If no match, use model reasoning to generate subtasks
        3. Validate and optimize the generated results
        """
        # Step 1: Rule matching
        for pattern, steps in self.rules.items():
            if re.search(pattern, task, re.IGNORECASE):
                return steps
        
        # Step 2: Model reasoning generation
        prompt = f"""
        Decompose the following task into executable subtasks, each subtask should be independent and verifiable:
        Task: {task}
        Context: {context or "No specific context"}
        Format: One subtask per line, no numbering
        """
        
        model_response = self.model(prompt)
        raw_subtasks = model_response.strip().split('\n')
        
        # Step 3: Validation
        validated = [t for t in raw_subtasks if self._is_valid_subtask(t)]
        
        # Limit to a maximum of 8 subtasks
        return validated[:8]
    
    def _is_valid_subtask(self, task: str) -> bool:
        """Check if a subtask is valid"""
        return len(task) > 10 and len(task) < 200

4.3 Common Pitfalls and Optimization Tips

1. Subtask naming convention: Use short descriptions starting with a verb (e.g., “Extract data” instead of “Perform data extraction processing”) to reduce model interpretation ambiguity.
2. Length limit: Do not generate more than 8 subtasks in a single planning step; decompose long task sequences into multiple levels.
3. Context preservation: Keep the complete “Reasoning-Acting-Observing” records in the ReAct loop for traceability and debugging.

5. Multi-Agent Collaboration and Role Persona Design

5.1 Multi-Agent Collaboration Models

When a single agent cannot handle a complex task, a multi-agent system achieves parallel processing through role division. Common patterns:

• Hierarchical: One management agent decomposes tasks, multiple execution agents process in parallel
• Peer-to-peer: All agents have equal status, coordinating tasks through a communication protocol
• Role-based: Each agent has a fixed role (e.g., product manager, developer, tester), collaborating according to a preset workflow

5.2 MetaGPT’s Task Decomposition Practice

Take the MetaGPT open-source project as an example in software development scenarios:

• Product Manager Agent: Analyzes requirements, outputs PRD documents
• Architect Agent: Designs technical solutions based on PRD
• Developer Agent: Implements code according to the plan
• Tester Agent: Writes and executes test cases

The role persona design of each agent defines its behavioral boundaries:

• Product manager instructions include: “You are a rigorous product manager; your output must include feature lists, user stories, and acceptance criteria”
• Developer instructions include: “You can only call code generation and file manipulation tools; you are not responsible for database design”

5.3 CrewAI Multi-Role Collaboration Pattern

Core configuration for implementing multi-agent collaboration in the CrewAI framework:

from crewai import Agent, Task, Crew

# Define role agents
data_analyst = Agent(
    role='Data Analyst',
    goal='Analyze data and extract key metrics',
    backstory='Proficient in data cleaning and statistical analysis',
    tools=[sql_tool, python_tool],
    allow_delegation=False
)

visualization_agent = Agent(
    role='Visualization Engineer',
    goal='Convert data metrics into charts',
    backstory='Master of Matplotlib and Tableau',
    tools=[chart_tool],
    allow_delegation=False
)

# Define tasks
analyze_task = Task(
    description='Analyze 2024 sales data, extract month-over-month growth rate',
    agent=data_analyst
)
visualize_task = Task(
    description='Generate a comparison bar chart from the analysis results',
    agent=visualization_agent,
    depends_on=[analyze_task]
)

# Create crew and execute
crew = Crew(
    agents=[data_analyst, visualization_agent],
    tasks=[analyze_task, visualize_task]
)
result = crew.kickoff()

5.4 Communication and Synchronization Issues

Three common problems in multi-agent collaboration:

1. Inconsistent output format: Downstream agents cannot parse upstream output. Solution: Define standardized interface protocols (e.g., JSON schema)
2. Execution order dependency: Agent B needs results from Agent A, but A hasn’t completed yet. Solution: Manage with a task dependency graph, explicitly declare upstream/downstream relationships
3. Resource contention: Multiple agents call the same external API simultaneously, causing rate limiting or data inconsistency. Solution: Introduce resource locks or queue scheduling

6. Task Logic Orchestration and Tool Call Optimization

6.1 Execution Order Orchestration

Based on dependency relationships among subtasks, there are three basic orchestration patterns:

Sequential execution: Each subtask’s output (except the last) is the input for the next

for subtask in subtask_list:
    result = execute(subtask, previous_result)
    previous_result = result

Parallel execution: Independent subtasks start simultaneously

import asyncio
tasks = [execute_for_subtask(s) for s in independent_subtasks]
results = await asyncio.gather(*tasks)

Conditional branching: Choose different branches based on execution results

if execute(subtask_meta)['status'] == 'success':
    execute(subtask_detail)
else:
    execute(subtask_investigation)

6.2 Tool Call Optimization Strategies

Tool descriptions are crucial for the agent to select the correct tool. Optimization methods:

1. Description refinement: Avoid vague descriptions like “This tool can do many data operations.” Instead, use “Data cleaning tool: receives a pandas DataFrame, returns deduplicated data.”

2. Parameter examples: Include input and output examples in each tool function’s docstring.

3. Conflict resolution: When multiple tools have similar functionality, explicitly state the differences. For example:

   • “query_all_users: returns basic information (ID, name, email) of all users in the database”
   • “query_active_users: returns detailed information (including login time, device type) of users who have logged in within the last 30 days”

6.3 OpenHands AgentController Action Routing

In the OpenHands framework, the AgentController is responsible for dispatching tasks to different agent action units:

• CodeAgent: Handles code generation and debugging
• KnowledgeAgent: Handles document queries
• ConstraintAgent: Checks whether execution results meet constraint conditions

Routing rules are based on task label matching, e.g., tasks with the “analysis” label are routed to CodeAgent, tasks with the “question” label are routed to the knowledge base agent.

6.4 AG-UI Frontend Tool Routing

When embedding an agent in a web page (e.g., AG-UI), it is necessary to distinguish between frontend and backend tool execution environments:

• Frontend tools: e.g., “Get user geolocation”, “Switch theme color” — executed in the browser
• Backend tools: e.g., “Query database”, “Call API” — executed by the server-side agent

AG-UI achieves automatic routing through declarative annotations: frontend functions are marked with the [Description] attribute, and the framework automatically identifies and calls them during the conversation.

7. Pitfall Records and Common Issues

7.1 Overtly Fine Task Decomposition Leading to Infinite Loops

Phenomenon: The model repeatedly generates new subtasks without taking any substantive action, eventually hitting the maximum step limit.

Root cause: Improper decomposition granularity; each subtask is too fine, causing the model to loop between “Reasoning -> Re-reasoning”.

Solutions:

1. Set an upper limit on the number of subtasks (recommended 3-8)
2. For tasks exceeding the limit, force trigger the execution function
3. Introduce an “execution tendency” metric in the ReAct loop; if no tool has been called for X consecutive steps, automatically trigger a default execution path

7.2 Inaccurate Reasoning Leading to Unreasonable Subtasks

Phenomenon: The model decomposes “Analyze sales data” into unrelated subtasks like “Learn SQL syntax”.

Root cause: The model has an incorrect understanding of domain knowledge, or the context window is insufficient, causing loss of task intent.

Solutions:

1. Increase domain keywords in the task description (e.g., subtask templates corresponding to “data analysis”)
2. Use few-shot examples to guide the model’s output format
3. Combine with rule-based validation to filter or regenerate unreasonable subtasks

7.3 Multi-Agent Communication Timeout

Phenomenon: Agent A calls Agent B and waits for a long time without response, causing an overall timeout.

Root cause: No timeout protection set, or Agent B is blocked by other tasks.

Solutions:

1. Set a timeout for each agent call (e.g., 30 seconds)
2. Use message queues for asynchronous communication to avoid synchronous blocking
3. Design degradation strategies upon timeout (e.g., Agent A returns partial results directly)

7.4 Conflicting Tool Descriptions

Phenomenon: The agent selects a tool with a vague description, and the execution result does not meet expectations.

Root cause: Multiple tools have similar functionality, and their descriptions lack distinction.

Solutions:

1. Use “exclusion” descriptions to clarify what the tool does not do (e.g., “This tool does not perform data write operations”)
2. Add usage scenario examples for each tool
3. Introduce tool selection priority, adjusting recommendation rankings based on recent successful call records

8. Summary and Expansion

8.1 Key Points Review

This article systematically introduces the development of agent task automatic decomposition logic, covering the following:

1. Task decomposition design principles: Granularity control, dependency modeling, traceability and exception handling
2. ReAct framework implementation: Reasoning-Acting-Observing loop, dynamic adjustment of subtask sequences
3. Core code implementation: From rule matching to model reasoning, providing reusable subtask planning code
4. Multi-agent collaboration: Role persona design, communication protocols, CrewAI practice
5. Task logic orchestration: Sequential/parallel/conditional branching, tool call description optimization
6. Common pitfalls: Troubleshooting and solutions for infinite loops, unreasonable subtasks, timeouts, and description conflicts

The ability of automatic task decomposition is key to the controllability and execution efficiency of agent systems — without reasonable decomposition, agents facing complex tasks will either fall into infinite loops or produce unreliable results.

8.2 Expansion Directions

• Long-term task memory: For tasks lasting hours or even days, introduce external memory storage to avoid losing intermediate states due to context window limitations.
• Self-correction mechanism: Automatically adjust subsequent planning based on subtask execution results, such as regenerating, skipping, or merging subtasks.
• Fine-tuning models to improve accuracy: Collect real execution data and fine-tune models for task decomposition in specific domains to reduce reasoning bias.
• Visual debugging tools: Visualize the task planning process and execution status to facilitate human intervention and rapid problem localization.

8.3 Recommended Resources

• LangChain Agent framework documentation
• MetaGPT open-source project: Multi-agent collaboration examples
• CrewAI practice guide: Best practices for role design
• OpenHands AgentController source code analysis

It is recommended to start with the basic ReAct Agent code provided in this article and gradually integrate capabilities such as rule validation, dynamic reasoning, and multi-agent collaboration, validating and adjusting decomposition strategies in practice.

Summary

Through this article, you should now have a deeper understanding of “Agent task automatic decomposition methods.” It is recommended to practice more in conjunction with actual projects. If you have any questions, feel free to discuss!