-
Notifications
You must be signed in to change notification settings - Fork 0
Implement LLM-based decomposition strategy #168
Copy link
Copy link
Closed
Labels
prio:highImportant, should be prioritizedImportant, should be prioritizedscope:large3+ days of work3+ days of workscope:medium1-3 days of work1-3 days of workspec:agent-systemDESIGN_SPEC Section 3 - Agent SystemDESIGN_SPEC Section 3 - Agent Systemspec:providersDESIGN_SPEC Section 9 - Model Provider LayerDESIGN_SPEC Section 9 - Model Provider Layerspec:task-workflowDESIGN_SPEC Section 6 - Task & Workflow EngineDESIGN_SPEC Section 6 - Task & Workflow Enginetype:featureNew feature implementationNew feature implementationtype:testTest coverage, test infrastructureTest coverage, test infrastructure
Description
Context
Extracted from #14 (task decomposition and routing engine). The DecompositionStrategy protocol and ManualDecompositionStrategy are implemented. This issue covers the LLM-based strategy where an agent autonomously decides how to break down a parent task into subtasks.
Depends on the agent execution loop being available to make LLM calls.
Acceptance Criteria
-
LlmDecompositionStrategyimplementsDecompositionStrategyprotocol - Uses an LLM provider to analyze the parent task and generate a
DecompositionPlan - Respects
DecompositionContextconstraints (max_subtasks, max_depth) - Validates LLM output (well-formed subtask IDs, valid dependencies, no cycles)
- Handles LLM failures gracefully (malformed output, refusal, timeout)
- Unit tests with mocked provider calls
- Integration test with real provider (optional, behind marker)
Design Spec Reference
- §6.9 — Task Decomposability & Coordination Topology
- §6 — Task Workflow
Notes
- The
DecompositionStrategyprotocol (engine/decomposition/protocol.py) already defines the interface DecompositionServiceaccepts any strategy — plug in the new one via dependency injection- Consider prompt engineering for consistent subtask ID generation and dependency specification
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
prio:highImportant, should be prioritizedImportant, should be prioritizedscope:large3+ days of work3+ days of workscope:medium1-3 days of work1-3 days of workspec:agent-systemDESIGN_SPEC Section 3 - Agent SystemDESIGN_SPEC Section 3 - Agent Systemspec:providersDESIGN_SPEC Section 9 - Model Provider LayerDESIGN_SPEC Section 9 - Model Provider Layerspec:task-workflowDESIGN_SPEC Section 6 - Task & Workflow EngineDESIGN_SPEC Section 6 - Task & Workflow Enginetype:featureNew feature implementationNew feature implementationtype:testTest coverage, test infrastructureTest coverage, test infrastructure