Task Decomposition

The fundamental building blocks of an HTN. A compound task is an abstract, high-level objective (e.g., 'Deliver Package') that cannot be executed directly and must be decomposed. A primitive task is a directly executable action or operator (e.g., 'Navigate to Location', 'Pick Up Item') with defined preconditions and effects on the world state. The planner's goal is to decompose all compound tasks until only a sequence of primitive tasks remains.

A method is a schema that defines a possible way to decompose a specific compound task. It consists of:

• Head: The compound task it decomposes.
• Preconditions: Logical conditions that must be true in the current world state for this method to be applicable.
• Subtask Network: The ordered set of subtasks (which can be compound or primitive) that implement the method.

For the task 'Brew Coffee', one method's subtask network might be: [Grind Beans, Heat Water, Pour Water Through Grounds]. Different methods offer alternative decomposition strategies, enabling flexible planning.

An operator is the formal representation of a primitive task's executable logic. It is defined by:

• Preconditions: The set of facts that must be true in the state for the action to be legally performed.
• Effects: The set of state changes (additions and deletions of facts) that result from executing the action.

For example, the Drive(Vehicle, From, To) operator might have a precondition HasFuel(Vehicle) and effects At(Vehicle, To) and not(At(Vehicle, From)). Operators are the leaves of the decomposition tree, directly interfacing with the world model.

The task network is a directed graph representing the current set of tasks to be accomplished and the ordering constraints between them. During decomposition, a method adds its subtasks and constraints to this network. Constraints specify that one task must be completed before another can begin (e.g., Unlock Door must precede Open Door). The planner must find a total ordering of all primitive tasks that satisfies all constraints, resulting in a linear, executable plan.

The domain description is the complete formal specification of the planner's knowledge. It includes the library of all task schemas, methods, and operators. The initial state is a snapshot of the world at the start of planning, represented as a set of logical facts (e.g., RobotIn(Kitchen), BatteryLevel(High)). Together with the initial task network (the top-level goal), these form the complete HTN planning problem. The planner's search is constrained by this domain knowledge, making it more efficient than unstructured search.

A high-level goal like 'Build a user login API endpoint' is decomposed into a network of subtasks:

• Analyze Requirements: Parse the user story for specific fields (username, password) and security needs.
• Design Database Schema: Create a 'users' table with hashed password storage.
• Implement Core Logic: Write functions for user registration and credential validation.
• Write Unit Tests: Create tests for success, failure, and edge cases.
• Document API: Generate OpenAPI specification for the new endpoint.

Each of these subtasks may be further decomposed. For instance, 'Implement Core Logic' breaks into 'Hash password using bcrypt' and 'Generate JWT token on successful login'.

The compound task 'Fulfill Order #4567' is decomposed through an HTN into a sequence of parallel and sequential primitive actions:

1. Locate Items: (Parallel subtasks) Query inventory database for bin locations of each SKU in the order.
2. Plan Navigation: Calculate an efficient physical path for the Autonomous Mobile Robot (AMR) through the warehouse aisles, respecting ordering constraints (heavy items last) and resource constraints (battery life, shelf weight limits).
3. Execute Picks: (Sequential loop) For each item: Navigate to bin, position robotic arm, perform grasp, place in tote.
4. Deliver to Packing: Transport full tote to the packing station and update the order management system.

This decomposition must handle failures (item missing) by triggering replanning at the appropriate level.

For an AI agent tasked with 'Assess litigation risk for Project Alpha', task decomposition structures the research:

• Primary Task Network: Review contract clauses, analyze relevant case law, identify regulatory obligations.
• Method for 'Review contract clauses': Extract all indemnification, liability, and termination clauses; compare them against a compliance checklist.
• Method for 'Analyze case law': Search legal databases for rulings on similar contractual disputes; summarize judicial reasoning and outcomes.

The agent uses this hierarchical plan to synthesize a final report, ensuring each primitive task (e.g., 'Extract clause 12.4 from MSA.pdf') is grounded in a concrete action. Conditional tasks may be used: If a jurisdiction-specific regulation is found, then decompose a subtask to analyze its local enforcement history.

A compound task like 'Generate differential diagnosis' is decomposed using medical knowledge encoded as methods:

1. Ingest & Structure Data: Parse patient EMR, extracting key entities (symptoms: fever, cough; lab values: elevated WBC).
2. Trigger Hypothesis Generation: Match extracted findings against a knowledge graph of disease-symptom relationships to produce a list of candidate conditions.
3. Refine & Rank Hypotheses: For each candidate, decompose a subtask to gather supporting/contradicting evidence (e.g., 'Check for recent travel' for tropical diseases, 'Review prior imaging' for chronic conditions).
4. Recommend Next Steps: Output a solution plan suggesting the highest-yield diagnostic tests (primitive actions for the clinician).

This mirrors the SHOP planner approach: forward-chaining decomposition interleaved with evaluating the current patient 'state'.

Faced with a disruption like a port closure, an agent's goal 'Minimize delivery delay for shipment group' undergoes real-time decomposition:

• Assess Impact: Identify all shipments affected, their priorities, and current locations.
• Generate Alternatives: Decompose into evaluating different modes (air vs. rail), routes, and carriers. Each alternative is a sub-network of tasks to check capacity, cost, and ETA.
• Optimize Selection: Solve a multi-objective optimization across cost, time, and reliability. This may involve simulating the execution of candidate hierarchical plans.
• Execute Re-route: The chosen plan's primitive tasks become API calls to booking systems, notifications to logistics partners, and updates to tracking databases.

Iterative tasks monitor for further disruptions, triggering new decomposition cycles if needed.

To 'Create a training scenario for a customer service agent', a system decomposes the creative goal into executable steps:

• Define Scenario Core: Select a product type (e.g., 'streaming subscription') and a primary issue (e.g., 'billing discrepancy').
• Generate User Persona: Decompose into creating a name, a plausible history with the service, and a consistent emotional tone.
• Build Interaction Timeline: Create a skeletal plan of the conversation: user's initial complaint, agent's information gathering, escalation points, resolution offer.
• Populate with Dialogue: For each step in the timeline, generate specific, natural language utterances for both user and agent, ensuring they align with the persona and core scenario.
• Add Variability: Introduce conditional tasks (e.g., If user is frustrated, then include a request for a supervisor) to create multiple scenario branches.

This structured breakdown ensures generated scenarios are coherent, diverse, and fit for purpose.