[feat][hiearchical_swarm][mid-flight replanning on judge rejection]

[kyegomez]

Problem

Today when the judge rejects a director's plan in HierarchicalSwarm, the swarm just loops the same plan. There is no way for the director to adapt — issue new subtasks, reassign failed ones to different workers, or change the decomposition.

Proposed feature

When the judge returns a rejection (or a low score), the director should be able to:

• Issue brand-new subtasks based on the judge's feedback
• Reassign specific failed subtasks to different workers
• Modify the dependency order between existing subtasks

Rather than restarting the whole plan, the director does an incremental replan informed by what went wrong.

Design sketch

• Judge verdict schema grows a feedback field (already partially present) and a failed_subtasks: List[str] list.
• On REVISE, the director is called with the original plan, the judge feedback, and the per-subtask results; it returns a ReplanAction (ADD / REASSIGN / REORDER / DROP).
• The swarm applies the action and re-runs only the affected subtasks.

Files

• swarms/structs/hiearchical_swarm.py

Why

Closes the feedback loop — the judge verdict currently has no way to actually drive adaptation. This is the biggest quality lift available for hierarchical runs.

[kinthaiofficial]

This is the right design direction. The current loop-same-plan behavior is the most common failure mode in hierarchical agent systems.

One pattern we found critical when implementing adaptive replanning:

The judge feedback must be structured, not free-text. If the judge just says "the plan is bad," the director cannot systematically determine what to change. Our judge returns:

• failed_subtasks with specific failure categories (timeout, wrong_output, dependency_unmet, budget_exceeded)
• reusable_results — subtask outputs that are still valid and should not be re-computed
• constraint_violations — which constraints the plan violated (helps the director avoid the same mistake)

Reassignment needs worker capability profiles. When subtask X fails on Worker A, the director needs to know why before reassigning to Worker B. If Worker A failed because of a model capability gap (e.g., cannot process images), reassigning to Worker B with the same model wastes a cycle. We tag each worker with capability metadata and the director filters candidates before reassignment.

Incremental replan should have a retry budget. Without a cap, the director-judge loop can cycle indefinitely — director replans, judge rejects, director replans again. We enforce a maximum of 3 replan cycles per task, after which the swarm escalates to the human operator with a summary of what was tried and why it failed.

On the ReplanAction design: consider adding a MERGE action that combines partial results from multiple failed subtasks into a single retry. We found that many failures happen because subtasks were decomposed too finely — merging two failed subtasks into one often succeeds where both individually failed.

We documented the coordination patterns and failure recovery strategies from running 221 agents at https://blog.kinthai.ai/221-agents-multi-agent-coordination-lessons

[adichaudhary]

Working on this