kyegomez/swarms

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

Open

#1,553 opened on Apr 21, 2026

View on GitHub
 (2 comments) (0 reactions) (0 assignees)Python (948 forks)github user discovery
FEATenhancementgood first issue

Repository metrics

Stars
 (6,809 stars)
PR merge metrics
 (PR metrics pending)

Description

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.

Contributor guide

Research direction
Implement a replanning mechanism in HierarchicalSwarm that, upon judge rejection (REVISE), allows the director to issue new subtasks, reassign failed subtasks, or reorder dependencies. This involves extending the judge verdict schema with a feedback and failed subtasks list, and creating a ReplanAction enum. The director should be invoked with the original plan and judge feedback to return a ReplanAction, which the swarm then applies.
Tech stack
python
Domain
backend
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Mostly clear
Prerequisites
Python
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
40