IBM researchers have released DRACO, a reinforcement-learning method for long-horizon agents that tries to solve a familiar training problem: a trajectory may contain dozens of actions, while the available reward arrives only once at the end. The paper was submitted to arXiv on September 3, 2026, and IBM has published Apache-2.0 training, evaluation and analysis code.
DRACO stands for Distributing Rubric-based Advantage for Credit Optimization. Instead of applying one trajectory-level advantage uniformly across every response token, the method uses dynamically generated rubrics and the judge's citations to redistribute that advantage toward the steps associated with each criterion. The total advantage assigned to a trajectory is preserved; what changes is where the learning signal lands.
A trajectory score becomes step-level training signal
Long-horizon agents make credit assignment unusually difficult. An agent can recover from an early mistake, perform several correct tool calls and still fail at the final step. A single success bit says little about which actions should be reinforced. Rubric-based evaluators provide more detail, but if their final score is still applied uniformly, much of that detail is lost during optimization.
DRACO generates prompt-specific and trajectory-specific rubrics during training, removes duplicates and drops criteria that do not distinguish rollouts in the group. A judge then scores a completed trajectory and cites the steps relevant to each rubric. Those citations are converted into per-step quality weights. The sign of the original group-normalized GRPO advantage is preserved while its magnitude is redistributed across the trajectory.
That distinction matters. DRACO is not introducing a second learned attribution model that must itself be trained and validated. The redistribution is closed-form. The additional dependency is instead the rubric and judge pipeline that decides which steps deserve credit.
The benchmark gains are promising, but one number conflicts
The arXiv abstract reports a 15.9-point improvement over the base model on AppWorld and a 5.3-point improvement over GRPO trained with sparse ground-truth reward. It also says the out-of-domain tau-bench result improves by 5.3 points over the base model without a frontier judge.
IBM's repository tells a slightly different story for tau-bench. Its README reports a 4.6-point gain over the base model, not 5.3. That discrepancy does not invalidate the method, but it is important because the repository is the artifact practitioners are most likely to use when reproducing the work.
Aipolix therefore treats the benchmark results as author-reported rather than independently established. No independent reproduction was identified in this run, and the tau-bench delta should be resolved by the authors before it is quoted as a settled result.
The judge becomes part of the training control plane
The more consequential engineering lesson is that DRACO moves evaluator behavior closer to the optimization loop. In several reported settings, the system uses an external frontier model to generate or score rubrics. Other settings replace that external judge with a served copy of the model being trained, including one configuration that requires agreement across three verdicts.
This changes what teams need to control. If rubric wording, judge version, sampling configuration or citation behavior changes, the location of the reward signal can change even when the scalar trajectory score looks similar. In other words, evaluator drift is no longer only an evaluation-quality concern. It can become a training-data and policy-update concern.
For teams experimenting with this approach, judge prompts, model versions, rubric-generation logic and citation outputs should be versioned alongside training configurations. A reproducible run needs to preserve not only model weights and optimizer settings but also the evaluator path that determined where credit was assigned.
The release is unusually inspectable
The IBM repository includes the training settings, launchers, reward-pipeline documentation, credit-assignment formulas, AppWorld and tau-bench evaluation harnesses, and analysis code used to produce the reported tables and figures. The README also documents eight training settings that vary reward source, judge choice and advantage distribution.
Most settings use Qwen3.6-27B, while one uses Qwen2.5-32B-Instruct. The proposed DRACO setting combines dynamic rubrics with per-step credit redistribution. The repository says each setting was trained for 100 steps, which is useful context when judging how broad the evidence is.
The code release makes the method testable, but it does not remove the need for replication. AppWorld and tau-bench are controlled environments, and production agents can have different tool failure modes, longer horizons and noisier observability.
What teams should test before adopting the idea
The practical test is not simply whether DRACO raises a benchmark score. Teams should compare uniform and redistributed credit while holding the base model, rollouts and judge as constant as possible. They should then measure whether improvements survive changes in judge model, rubric prompts and task distribution.
A second test is failure sensitivity. Because the method uses judge citations to decide which steps receive stronger credit, teams should deliberately perturb or withhold citations and observe how training changes. That can reveal whether the system is learning robust task behavior or overfitting to one evaluator's attribution style.
The broader architectural idea is valuable even if the published numbers move after replication: long-horizon agent training needs a traceable path from evaluation evidence to optimization. DRACO makes that path explicit. It also makes the evaluator an operational dependency that deserves the same versioning and audit discipline as the rest of the training stack.