Executive Summary

Key numbers

Four cells. The first two are how common the failures are and how far the reported score sits from the real one. The second two are the leakage rate of the framework that carries a dedicated safeguard, and the tests nobody passed even once.

Source: CWI paper (arXiv:2610.14115).

Start with one case the paper walks through. The Kaggle challenge called Problematic Internet Use asks for a prediction of how heavily a young person uses the internet. The researchers took that challenge's data, split it their own way, and handed it to the agents. ReAct and AIDE came back with near-perfect marks on their own validation, close to 1.0 on QWK, the metric the challenge uses.

Skill was not the reason. The evaluation portion the researchers carved out still held the variables beginning with PCIAT-, and from one of them, PCIAT-PCIAT_Total, the value to be predicted can be derived directly. The real Kaggle test set carries no such column. Both agents picked that variable up as a feature. In effect they read the answer, then produced it.

Put the same pipelines on the actual competition leaderboard and the numbers change. ReAct scored 0.4440, AIDE 0.4280, and MLEvolve 0.4170. The human who won that challenge scored 0.4820. All four figures are from the private leaderboard, and the public one puts them in the same order. A pipeline that had been scoring near 1.0 on its own validation dropped to a clear distance behind first place once the channel was closed.

The remaining gap is not explained by the failures. When the researchers laid the winning solution alongside the agent pipelines, they found it never predicted the target index directly. It predicted the continuous score that the agents had grabbed as a feature, and applied the thresholds that sort that score into grades only at the final stage. It used an objective suited to the distribution of the target, ran multi-seed 10-fold cross-validation, and combined model families of different kinds. None of the three agents reached for choices like these. The paper records this part separately from the failure list, because something is left over after every failure is removed.

The researchers evaluated three data science agents. ReAct is the plain baseline that thinks and acts in turns while using tools; AIDE rewrites its own code through repeated refinement; MLEvolve is a self-evolving multi-agent system that splits search and memory across several agents. Each was paired with three language models of different capacity, giving nine configurations. AutoGluon, a widely used automated machine learning system that is not an agent at all, was run alongside them as a reference point.

There are 220 tasks: 123 regression and 97 classification, with 108 drawn from STRABLE, 44 from Kaggle, 36 from OpenML, 24 from UCI, and 8 from MLE-bench. Each dataset was split 80 to 20, and the agents received both halves on the understanding that correct practice means leaving the evaluation half out of training. Healthcare supplies the largest share at 50 tasks, finance the next at 47.

One suspicion needs clearing first. Most of these tasks are public tabular datasets, so a language model may well have seen them during training, in which case a good score would come from recall rather than from analysis. The researchers tested that before anything else. They measured how far each table had been memorized by asking models to complete its column names, pulled out a high-memorization group and a low-memorization group, and ran both again with column names and descriptions masked. An unmasked rerun served as the control. That makes six tests in all, three agent frameworks on one model, repeated once for each group, and not one of them came out significant. Memorized tables were not what lifted the scores.

The grading was done by a language model judge rather than by people. It works in two passes: first it reads a pipeline to see which stages are present, then it judges only the failures that apply to those stages. Marking a pipeline for ignoring temporal order when the data has no time dimension would be wrong, so the filter comes first. Checked against 285 human-assigned ratings over 19 pipelines, the judge agreed 89.5% of the time, with Cohen's kappa at 0.62.

The paper also states which way the judge leans. Precision is 0.71 and recall 0.65, which leans toward missing real failures rather than inventing them. The authors therefore read the failure rates in their results as an underestimate rather than an overestimate. That is the direction to keep in mind while reading the numbers below.

The taxonomy holds 15 failure modes in two groups. Six are data leakage, where information from the evaluation data finds its way into training. Nine are non-leakage, where a required step is skipped or a wrong choice is made.

Every configuration carried failures. In all nine of them, at least one failure mode showed up in 43% or more of the pipelines. The judge also flagged problems outside the fixed list of 15, and once those were filtered down to genuine violations of data science practice, they still appeared in 37% of pipelines. The most common kind among them was, again, leakage.

The central finding is about how failures relate to reported performance. Scores cannot be compared across tasks that use different metrics, so the researchers ranked the pipelines within each task and used that ranking as a stand-in for performance. Because some configurations are simply stronger than others, each pipeline's rank was then compared against the rank expected for its own configuration, which strips out that baseline difference and leaves the effect of a single failure mode.

Where those ranked scores were measured matters. They come from the very evaluation portion handed to the agent, the part given with instructions not to train on it. That is the same place an organization's validation score comes from, and it is exactly the channel through which leakage pushes a score upward.

Once the baseline was removed, the results split in two directions. Every data leakage mode improved the ranking. Information from the evaluation data had entered training, so the gain is no surprise, and the lack of surprise is exactly the problem: nothing in the scorecard separates that gain from skill. The non-leakage modes mostly went the other way, and among them, having no train/validation split at all did the most damage, costing more than a full rank position on average.

One mode breaks the pattern. Using only a single evaluation metric belongs to the non-leakage group, yet it improved the ranking. The researchers read it this way: a pipeline that watches one metric gets tuned narrowly to that metric, and that is the metric the pipelines are ranked by, so it comes out ahead. Robustness along other axes may have been traded away for that gain, but a single metric is precisely what cannot show the loss.

The summary the paper draws is blunt. A high score on the test data does not mean a sound pipeline. Evaluate agents by their scores alone and the evaluation ends up rewarding leakage.

The failure table invites a wrong conclusion at first glance. ReAct paired with the smallest model shows 0.00 on four leakage modes. No imputation before the split, no ignored time order, no scaling before the split, no feature selection before the split. Other cells in the same row explain why. That configuration did not produce a train/validation split in a single pipeline, a rate of 1.00, and did no feature engineering in 0.98 of them.

Skip the split and you cannot commit the errors that happen before a split. Build no features and nothing leaks through a feature. A clean leakage record in the small model is not an observed practice; it is the gap left by a step never taken. Put the same model under AIDE, which does create a validation split, and imputation before splitting rises from 0.00 to 0.08.

Go up in capacity and the opposite shows up. Stronger models build features and designate their own validation sets, then leak inside the steps they have added. Whichever of the three agents it was attached to, the most capable model ignored temporal order in more than a third of the pipelines where order mattered. Counted outside the taxonomy, the share of pipelines leaking validation data into training climbs with capacity as well, from 8% to 16% to 26%.

Swapping the framework produces the same split. Some cells get repaired and others get created. With the most capable model, AIDE and MLEvolve both took having no train/validation split from the 0.40 it stood at under ReAct down to 0.00. MLEvolve took no feature engineering from 0.38 to 0.00 and naive ensembling from 0.90 to 0.04. In exchange, AIDE reported only a single evaluation metric in 85% to 88% of its pipelines whatever model it ran on. In that same cell, ReAct sits at 15% with the small model and 14% with the most capable one.

That is design rather than accident. AIDE scores and selects candidate solutions by a single validation metric. Yet as section 3 showed, using only one metric is the one non-leakage mode that improves the ranking. A failure that helps a pipeline place well is built into the framework itself.

The cell that stings most belongs to MLEvolve. This framework runs a dedicated agent to check for leakage, and with the most capable model it recorded the fewest failures inside the taxonomy of any configuration. Yet 50% of that same configuration's pipelines leaked validation data into training, and 57% of them carried a failure from outside the taxonomy, the highest share among all nine configurations. This is not the kind of problem a dedicated checking component closes off.

The large-scale analysis shows what agents actually do, but its tasks were not built with traps inside them, which makes the right answer hard to pin down. So the researchers wrote a separate exam. Each test plants one specific pitfall in the data and watches whether the agent recognizes it. Seventeen tasks rest on three underlying datasets, and every agent-task-hint combination was run five times and averaged.

There are six tests: class imbalance, inconsistently written values, telling correlation from causation, feature transformation that needs domain knowledge, leakage at the feature selection stage, and metric choice. Of the three models used earlier, the two smaller ones mostly failed to produce usable executable code here and dropped out of the analysis. The one that remained, joined by a fourth model brought in for this suite alone, left six configurations standing: two models crossed with three agents.

The outcome is stark. Two of the six tests were failed by every configuration in every run. One asks the agent to discard a fake feature that correlates strongly with the target while having nothing to do with it; the other asks it to drop, during feature selection, a feature that would not be available at training time. Both come back at a failure rate of 1.0. The test on inconsistently written values lands close behind, with five of the six configurations failing every run and the remaining one at 0.8. The other three tests varied widely by configuration.

The late addition was not uniformly better than the model it joined. Attached to ReAct, it reduced failures on class imbalance and on domain feature transformation, but the improvement did not carry over to the other tests. A stronger model does not evenly improve the judgment calls that methodology requires.

Hints were tested too. ReAct and AIDE dropped sharply as the hints grew more explicit, with failure rates approaching zero. The gap was in noticing the constraint, not in meeting it once prompted. MLEvolve moved differently. It improved up to a moderate level of guidance, then stopped responding to anything more explicit, and stayed above the other two throughout. The authors attribute this to elaborate search and optimization, where a constraint given at the outset is hard to carry all the way through.

This paper usually gets read as evidence that data science agents are not ready yet. From where we sit, working on data, something else comes into view first. When people did this work by hand, a good share of those fifteen failures got caught in code review and peer discussion. When did you split? Was the imputation before or after the split? Why that metric? Those were a reviewer's questions. Automation removed the seat where they were asked.

What took that seat is the scorecard. And by this paper's measurement, the scorecard gives its prize to the failure that most needs catching. A validation accuracy of 0.93 handed over by an agent may have come from procedure kept properly, or it may have come from the answer leaking in. The number by itself cannot tell the two apart.

So the question to ask before signing off changes. Not what the score is, but what was kept intact to produce it. When were training and validation separated, and how was each side of that line handled? Was a dataset with a time order split at random? Is a single metric doing all the work? This paper's failure list converts directly into a checklist. At minimum, an agent can be required to submit, alongside the model, which steps it took and how it isolated the evaluation data at each one.

One more thing follows. Section 4 teaches that an inspection built on counting failures backfires, because the pipeline that skipped the most steps looks cleanest. A quality record has to show what was done before it shows what went wrong. Which steps were taken, and which boundary was held at each one. Without those two lines, no score counts as evidence.

Thank you for reading this far. The paper is here, and the failure taxonomy with the test suite is on the project page. When your team receives a model from an agent, what do you ask for besides the score? We would be glad to hear it.

• 1.Li, X., Xia, H., Gomm, D., Santos, A., Wolff, C., & Hulsebos, M. (2026). "The Silent Failures in Agentic Data Science." arXiv:2610.14115.
• 2.TRL Lab. (2026). "Silent Failures in Agentic Data Science — Project Page." Failure taxonomy and controlled test suite.