Problem
InvestigateQuery runs the iterative, LLM-driven planner (runSequentialPlanner, which loops calling makeDecision/aiDecisionFn and re-evaluates context each step) ONLY in the fallback branch where the decision tree returns zero applicable nodes (agent.go:158-168). For any query the decision tree matches (the common case), the agent does a single parallel fan-out, aggregates once, and returns — it never re-plans based on what the first round found, never calls aiDecisionFn, and never sets IsComplete based on gathered evidence. The advertised ReAct loop (BuildDecisionPrompt lists actions like gather_logs / investigate_errors / complete) is effectively dead on the hot path, and maxSteps defaults to 3 (agent.go:52) but is irrelevant once parallel agents run.
Where
internal/agent/agent.go:122-168internal/agent/planner.go:13-63internal/agent/agent.go:52
Root cause
The architecture treats decision-tree fan-out and the LLM reasoning loop as mutually exclusive (if len(applicableNodes) > 0 ... else runSequentialPlanner). There is no outer loop that, after a fan-out round, feeds aggregated results back into an LLM 'do I have enough / what next' decision and optionally spawns a second round.
How to fix
Wrap the fan-out in the same step loop as the planner: after AggregateResults, build a decision prompt with the gathered data and call aiDecisionFn to decide complete vs. spawn-more; only return when the LLM declares completeness or MaxSteps is hit. Reuse BuildDecisionPrompt/makeDecision so both paths share one orchestration state machine instead of two disjoint branches.
Acceptance criteria
A query that needs follow-up (e.g. 'why is service X erroring' where round 1 surfaces a log group needing a deeper filter) triggers a second coordinated round; debug output shows >1 decision step on a decision-tree-matched query.
Severity: medium · from holistic hardening review.
Problem
InvestigateQueryruns the iterative, LLM-driven planner (runSequentialPlanner, which loops callingmakeDecision/aiDecisionFnand re-evaluates context each step) ONLY in the fallback branch where the decision tree returns zero applicable nodes (agent.go:158-168). For any query the decision tree matches (the common case), the agent does a single parallel fan-out, aggregates once, and returns — it never re-plans based on what the first round found, never callsaiDecisionFn, and never setsIsCompletebased on gathered evidence. The advertised ReAct loop (BuildDecisionPromptlists actions like gather_logs / investigate_errors / complete) is effectively dead on the hot path, andmaxStepsdefaults to 3 (agent.go:52) but is irrelevant once parallel agents run.Where
internal/agent/agent.go:122-168internal/agent/planner.go:13-63internal/agent/agent.go:52Root cause
The architecture treats decision-tree fan-out and the LLM reasoning loop as mutually exclusive (
if len(applicableNodes) > 0 ... else runSequentialPlanner). There is no outer loop that, after a fan-out round, feeds aggregated results back into an LLM 'do I have enough / what next' decision and optionally spawns a second round.How to fix
Wrap the fan-out in the same step loop as the planner: after
AggregateResults, build a decision prompt with the gathered data and callaiDecisionFnto decidecompletevs. spawn-more; only return when the LLM declares completeness orMaxStepsis hit. ReuseBuildDecisionPrompt/makeDecisionso both paths share one orchestration state machine instead of two disjoint branches.Acceptance criteria
A query that needs follow-up (e.g. 'why is service X erroring' where round 1 surfaces a log group needing a deeper filter) triggers a second coordinated round; debug output shows >1 decision step on a decision-tree-matched query.
Severity: medium · from holistic hardening review.