Paper deep dive
The Silent Failures in Agentic Data Science
Xue Li, Hongqian Xia, Daniel Gomm, Aécio Santos, Cornelius Wolff, Madelon Hulsebos
Intelligence
Status: succeeded | Model: Gemma-4-26B-A4B | Prompt: intel-v1 | Confidence: 92%
Last extracted: 10/14/2026, 9:32:19 AM
Summary
This paper evaluates agentic data science (DS) systems by identifying 'silent failures'—methodological violations like data leakage and inappropriate validation that may coexist with high predictive accuracy. Through large-scale analysis of 220 tasks, a curated test suite, and qualitative comparison with human experts, the authors find that most agents contain at least one failure mode. They highlight a positive correlation between data leakage and performance, arguing that evaluations must go beyond accuracy to ensure robustness and trustworthiness.
Entities (12)
Relation Signals (8)
Agentic Data Science → suffersfrom → Silent Failures
confidence 95% · We argue that these evaluations overlook the fundamental principles of data science... As such, only assessing downstream performance masks methodological failures
LLM-as-Judge → evaluates → Failure modes
confidence 94% · we devise an LLM-as-Judge evaluation to assess whether generated pipelines exhibit specific failure modes
Data Leakage → correlateswith → Predictive Performance
confidence 93% · we identify a positive correlation between the occurrence of data leakage failures and predictive performance
AutoGluon → servesas → Baseline
confidence 92% · we include AutoGluon... which serves as a strong non-agentic baseline
Agentic Data Science → lacks → Domain Knowledge
confidence 91% · Our qualitative analysis shows that DS agents generally lack problem solving creativity and domain knowledge
MLEvolve → uses → Gemini-3.7
confidence 90% · Table 3: Occurrence rate per failure modes... by agent and model... MLEvolve Gemini-3.7
AIDE → uses → Qwen-27B
confidence 90% · Table 3: Occurrence rate per failure modes... by agent and model... AIDE Qwen-27B
ReAct → uses → Qwen-4B
Cypher Suggestions (0)
No Cypher suggestions yet.
Abstract
Abstract:Large language models have significantly lowered the barrier to writing code. Naturally, this has also led to the development of data science agents that promise automating the design and execution of data science from task formulation to model development. Existing evaluations of agentic data science (agentic DS) assess downstream predictive performance and code correctness, providing preliminary insight in agentic DS capabilities. We argue that these evaluations overlook the fundamental principles of data science: methodological data science- and domain knowledge. As such, only assessing downstream performance masks methodological failures such as data leakage and inappropriate validation, limiting the development of robust agentic DS systems. In this paper, we evaluate agentic DS beyond accuracy from three different angles: 1) a large-scale analysis of failure modes in common agentic DS frameworks and models across 220 data science tasks, 2) a reusable and extensible test suite with curated data science tasks that test for six specific failures in a controlled manner, and 3) a qualitative assessment of agentic DS pipelines against expert solutions on Kaggle competitions. We find that the majority of agentic solutions contain at least one failure mode despite the complexity of agentic harness or model capacity. Moreover, we identify a positive correlation between the occurrence of data leakage failures and predictive performance, confirming the necessity to evaluate agents beyond accuracy. Our qualitative analysis shows that DS agents generally lack problem solving creativity and domain knowledge, compared to competition-winning data scientists. We believe that principled failure mode analysis, as presented here, should be integral part of agentic DS evaluations, and that the insights we surface will be key in developing trustworthy agentic DS pipelines.
Tags
Links
- Source: https://arxiv.org/abs/2610.14115v1
- Canonical: https://arxiv.org/abs/2610.14115v1
Trouble viewing inline? Open PDF directly →
Full Text
68,721 characters extracted from source content.
Expand or collapse full text
THE SILENT FAILURES IN AGENTIC DATA SCIENCE Xue Li 1 , Hongqian Xia 1 , Daniel Gomm 1 , A ́ ecio Santos 1 , Cornelius Wolff 1 , Madelon Hulsebos 1 1 Centrum Wiskunde & Informatica, Amsterdam, Netherlands xuel, madelon@cwi.nl ABSTRACT Large language models have significantly lowered the barrier to writing code. Nat- urally, this has also led to the development of data science agents that promise au- tomating the design and execution of data science from task formulation to model development. Existing evaluations of agentic data science (agentic DS) assess downstream predictive performance and code correctness, providing preliminary insight in agentic DS capabilities. We argue that these evaluations overlook the fundamental principles of data science: methodological data science- and domain knowledge. As such, only assessing downstream performance masks method- ological failures such as data leakage and inappropriate validation, limiting the development of robust agentic DS systems. In this paper, we evaluate agentic DS beyond accuracy from three different angles: 1) a large-scale analysis of failure modes in common agentic DS frameworks and models across 220 data science tasks, 2) a reusable and extensible test suite with curated data science tasks that test for six specific failures in a controlled manner, and 3) a qualitative assessment of agentic DS pipelines against expert solutions on Kaggle competitions. We find that the majority of agentic solutions contain at least one failure mode despite the complexity of agentic harness or model capacity. Moreover, we identify a pos- itive correlation between the occurrence of data leakage failures and predictive performance, confirming the necessity to evaluate agents beyond accuracy. Our qualitative analysis shows that DS agents generally lack problem solving creativ- ity and domain knowledge, compared to competition-winning data scientists. We believe that principled failure mode analysis, as presented here, should be inte- gral part of agentic DS evaluations, and that the insights we surface will be key in developing trustworthy agentic DS pipelines. Project resources are available at https://trl-lab.github.io/ds-agent-failures/. 1INTRODUCTION The strong code generation capabilities in large language models (LLMs) have led to their wide adoption in software engineering (Jimenez et al., 2024). When connected to execution environ- ments, LLMs can be deployed as agents for the autonomous completion of tasks, which has become an emerging practice across applications and industries (Pan et al., 2025). While coding agents generally improve with more capable backbone LLMs (Jimenez et al., 2024), understanding perfor- mance beyond end-to-end capabilities is key (Gu et al., 2025). Prior analyses of agentic code-based systems have surfaced common failure modes beyond code correctness, such as disobeying task specifications, misaligned agent interactions, and incorrect task verification (Cemri et al., 2025). In parallel with coding agents, we observe an influx in the automation of data science pipelines through specialized data science agents as well (Guo et al., 2024; Grosnit et al., 2025; Du et al., 2026). Data science use cases, particularly of a predictive nature, are traditionally characterized as multi-disciplinary processes that involve long-trained data scientists, domain experts, software and data engineers (De Bie et al., 2022). What constitutes a “good” data science pipeline is also inher- ently task- and data-dependent, and cannot be coupled with a hard verifiable signal. For example, model training and evaluation may require a temporal splitting procedure if the use-case demands temporal anticipation, while predictive performance metrics need to suit the target data distribution. These characteristics also translate into different evaluation protocols: whereas software is tested in an integrated verifiable manner, the assessment of (statistical) validity and utility in data science 1 arXiv:2610.14115v1 [cs.AI] 9 Oct 2026 is typically spread over the entire process and requires input from domain experts, engineers, and data scientists (De Bie et al., 2022; Cong et al., 2025). These characteristics, therefore, necessitate different evaluations beyond code generation capabilities. An early large-scale evaluation of generic agents across diverse tasks common in industry, among which data science tasks, highlighted a significant difference where most LLMs had a success rate of zero on data science tasks compared to approximately 15% higher success rates on other tasks (Xu et al., 2025). Specialized DS agent benchmarks provide a more holistic analysis of metrics such as cost, efficiency, and success rates, surfacing the differences across models and DS agent frame- works (Huang et al., 2024; Jing et al., 2025; Nayak et al., 2026). However, we argue that the poten- tial presence of silent failures can give a distorted view of generalizability, hence making it risky to assess the actual capability of DS agents with downstream metrics only. The development of reli- able DS agents, therefore, demands more fine-grained evaluations beyond downstream performance metrics to understand their true failure modes and capabilities. Silent Failures We define silent failures as task-relevant methodological violations that compromise the validity or soundness of a solution, but may remain undetected by conventional output-based evaluation. Silent failures can coexist with executable code and strong predictive performance. ReActAIDEMLEvolve 0 20 40 60 80 100 Pipelines with ≥ 1 failure mode (%) 100% n=220 99% n=211 100% n=65 99% n=220 95% n=185 98% n=203 99% n=219 97% n=219 68% n=219 Qwen-4BQwen-27BGemini-3.7 Figure 1: Percentage of pipelines with at least one failure mode per agent- model configuration. In this paper, we present① the first large-scale analysis of common failure modes of various DS agents and mod- els on 220 tasks,② insights from a reusable controlled test suite with curated tasks, and③ a qualitative analy- sis of capabilities in comparison with human expert solu- tions, all grounded in data science best practices (Lones, 2024; Kumar et al., 2025). Across analyses, we find that the majority of agent-generated pipelines contain at least 1 data science failure mode regardless of the complexity data science agent framework (Figure 1). We also find that data leakage failure rates correlate with inflated pre- dictive performance, underlining the necessity to evaluate agents beyond accuracy. Finally, our qualitative analysis shows that agents’ solutions are weaker on task formula- tion and feature engineering compared with human expert solutions, illustrating a lack of problem-solving creativity and domain knowledge. We believe that principled failure mode analysis, as presented in this paper, should be an integral part of agentic DS benchmarks and evaluations. We also envision that the DS practices framework and surfaced insights are key for developing robust data science agents. 2RELATED WORK Automated data science. Automated Machine Learning (AutoML) systems address the need for automating the selection of model architectures and optimization of hyperparameters (Hutter et al., 2019), through frameworks like TPOT (Olson et al., 2016), AutoGluon (Erickson et al., 2020), and auto-sklearn (Feurer et al., 2015). By optimizing over a large search space, AutoML frameworks often match the performance of models engineered by machine learning experts (Hutter et al., 2019; Erickson et al., 2026), yet remain constrained to a predefined search space and narrow scope of the end-to-end data science workflow. The recent line of work on tabular foundation models (TFMs) intends to remedy the hyperparameter search and instead train and predict in one forward pass using a pre-trained in-context learning model (Hollmann et al., 2025; Qu et al., 2025). Given the time- consuming nature of data science and the limited human capacity, it has naturally become a new objective to automate many steps in the end-to-end data science workflow (De Bie et al., 2022). The increasing code generation capacity of LLMs has led to their deployment in autonomous data science agents, performing tasks across the entire workflow. Approaches for building and refining machine learning pipelines vary significantly. Some agents construct them in a single loop (Grosnit et al., 2025), while others iteratively refine them (Guo et al., 2024; Jiang et al., 2025; Zhang et al., 2026) or systematically explore the design space (Du et al., 2026). Our analysis includes DS-tailored agents, simpler ReAct agents, and AutoGluon as a reference AutoML implementation. 2 Agentic data science benchmarks and evaluations. Benchmarks have been proposed alongside the proliferation of research into data science agents. Their aim has mostly been to assess the predictive performance of the models these agents produce. These benchmarks predominantly build on machine learning competitions sourced from Kaggle (Chan et al., 2025; Jing et al., 2025; Shu et al., 2025; Nie et al., 2026; Sun et al., 2026; Nayak et al., 2026; Huang et al., 2024), which provide reference solutions that can be used to define relative performance metrics. They focus on predictive performance and mostly do not analyze failures. Those that do report only high- level failure categories, mostly focused on execution errors such as incorrect tool use and coding mistakes (Nie et al., 2026; Shu et al., 2025). We instead analyze how data science agents implement predictive models by characterizing which practices they follow and where they fail. Failure mode analysis in LLM agents. Analyzing code and execution traces of agentic systems has become essential for understanding these systems. Such analyses have yielded taxonomies of failure modes specific to multi-agent systems (Cemri et al., 2025), safety aspects (Bryan et al.), and alignment under adverse incentives (Li et al., 2026). A consistent finding across analyses is that the ability to write working code and correctly use tools is getting less relevant to the performance of agentic systems, whereas errors concentrate in planning and reasoning (Zhu et al., 2026) and under- standing data (Zhu et al., 2026) and the broader context (Patel et al., 2026). Existing taxonomies and analyses are mostly proposed for code generation and thus focus on failures in agent coordination, grounding, and execution, providing an incomplete view of violations in data science methodology. 3EVALUATION METHODOLOGY In this section, we introduce the methodology used to understand why data science agents fail. We first introduce the approach used to carry out large-scale analysis of data science failures using LLM- as-judge (Section 3.1), then we present the systematic test suites with curated tests (Section 3.2), and finally we outline the qualitative comparisons with high-performing solutions (Section 3.3). 3.1LARGE-SCALE FAILURE MODE ANALYSIS Evaluating agentic data science across a large number of tasks through manual inspection is costly. Following previous evaluations of agentic systems (Cemri et al., 2025), we devise an LLM-as-Judge evaluation (Zheng et al., 2023) to assess whether generated pipelines exhibit specific failure modes. However, not all failure modes are applicable in every data science use case, and often depend on properties of the task, data, or pipeline itself. For example, ignoring temporal order when splitting the data constitutes a failure only when the data involves a temporal structure for which chronologi- cal separation is required, and is irrelevant in other cases. To account for the task-conditional relevance of failure modes, we apply a two-stage LLM-based evaluation. In the first stage, the judge analyzes each generated solution to identify its pipeline structure and determine which failure modes are applicable. Specifically, it extracts whether the so- lution contains key pipeline components, including data cleaning ,feature engineering , validation ,hyperparameter tuning ,model comparison , andensembling , as well as whether it uses deep learning or stochastic models (uses deep learning and uses stochastic model ). This structural information serves as a filter for determining the applicability of individual failure modes. In the second stage, the judge evaluates the generated pipeline for the applicable failure modes. We evaluate all failure modes within a single LLM call, providing the pipeline structure extracted in the first stage as additional context. The judge produces a binary decision for each failure mode, indicating whether the corresponding failure is present in the solution, and, if so, extracting the lines of code where the failure mode occurs. Besides filtering out inapplicable failure modes per pipeline, this two-stage evaluation process separates pipeline understanding from failure detection and improves consistent performance across agents. We inform the failure modes with commonly identified bad practices (Kumar et al., 2025; Lones, 2024), as shown in Table 1. These failure modes span the stages of data science pipelines . We broadly categorize them into “data leakage” modes, indicated using FM , and “non-leakage” modes, using FM. Detailed definitions for all failure modes are available in Appendix A.2. Our analysis 3 Table 1: Failure modes used for the large-scale analysis. Identifier (ID) colors distinguish two categories: FMData Leakage modes andFMNon-leakage modes. Failure modes marked with a dagger ( † ) are conditionally evaluated based on pipeline stage characteristics (e.g., whether deep learning or ensembling is used). IDFailurePipeline StageIDFailurePipeline Stage FM01 Wrong task formulationProblem Formulation FM09 Feature selection before splittingFeature Selection FM02Peeking at test data during EDAExploratory Data AnalysisFM10Wrong model type for taskModel Selection FM03Not cleaning dataPreprocessingFM11No regularisation in DL † Model Training FM04Imputation before splittingPreprocessingFM12Naive ensembling † Model Optimization FM05 Ignoring temporal order † Data Splitting FM13 Reusing test set across variants † Model Evaluation FM06No train/val splitData SplittingFM14Single eval of stochastic model † Model Evaluation FM07No feature engineeringFeature EngineeringFM15Using only one eval metricModel Evaluation FM08Scaling before splittingPreprocessing focuses on a predefined set of common data science failure modes and therefore does not exhaust all possible issues in a pipeline. The detected failures should thus be interpreted as a subset of potential methodological problems. To partially capture failures outside the taxonomy, we additionally in- clude an other category that allows the judge to flag and describe additional issues. We also validate the judge against independent human annotations to assess reliability. 3.2CURATED TEST SUITE WITH DATA SCIENCE FALLACIES Although the large-scale analysis provides quantitative insights into agent behaviour over naturalistic tasks, it cannot control what the correct practice should look like because the tasks were not designed with specific defects. To assess agents under more controlled conditions, we design a test suite in which each test targets a specific failure mode through a predefined perturbation. For example, to evaluate whether agents appropriately handle class imbalance, we construct a task with a highly imbalanced target distribution and examine whether the generated pipeline adopts suitable practices. Each test follows a “unit-test-style” design: the relevant pitfall is deliberately embedded in the task, and failure indicates that the agent did not identify or appropriately address the targeted issue. For each task, we additionally define multiple levels of hints that vary in instructional explicitness. The base condition provides no hint about the failure mode. We then increase the amount of guidance. To determine whether an agent exhibits the appropriate behaviour for a given failure mode, we use an LLM-based judge to inspect the generated pipeline. For each test, we predefine the set of ac- ceptable treatments corresponding to the targeted failure mode, and the judge checks whether any of these treatments is present. To obtain a stable estimation, we run each agent-task-hint combination five times and aggregate the results across runs. The six designed tests are shown in Table 2, with the formalization and evaluation defined in each row. These failure modes cover different stages of data science pipelines. We select these failure modes that satisfy three criteria: (1) can be instantiated through a controlled dataset or task design, (2) the expected methodological response can be speci- fied clearly enough to support a controlled evaluation, and (3) the targeted decision can be isolated from other parts of the pipeline with limited confounding. 3.3SKILL GAP ANALYSIS WITH EXPERT DATA SCIENCE SOLUTIONS The previous evaluations primarily focus on identifying practices that violate established data sci- ence principles, hence compromising the validity of a solution. However, the absence of such fail- ures does not necessarily imply that a pipeline is highly effective. For example, an agent may pro- duce a methodologically valid pipeline while ignoring a better task formulation, or a non-obvious feature transformation that can better capture the underlying structure of the task. To understand how data science agents compare to human experts in data science, we curate a set of Kaggle chal- lenges that accept late submissions. For each task, we submit the predictions or solutions produced by agents to the leaderboard and compare their performance with high-performing solutions. The leaderboard provides an external reference for assessing generated pipelines. Moreover, we com- pare both the predictive performance and the modelling practice used by high-ranking solutions. This helps identify practices that contribute to performance gains even when their absence does not constitute a methodological failure. Additionally, this helps in understanding the true performance of agents-generated solutions on realistic challenges. As an additional reference, we compare the DS agent solutions with the solution of AutoGluon on selected tasks. 4 Table 2: Six controlled failure-mode test suites. Each test introduces a targeted perturbation designed to expose a specific data science failure and is evaluated with a strict evaluation measure. Failure ModeTest CaseAssessment TF01Ignoring Class Imbalance Dataset with high class-imbalanceAssess if the agent is alerting to the skew; classifier performing poorly on minority class TF02Not Normalizing Formatting Inconsistent formatting of equivalent values (for example, string-encoded missing values) Assess if an agent is aware of and reacts appropriately to the inconsistency during data preprocessing TF03Not Separating Correlation from Causation Dataset includes a feature that strongly correlates with the target, without meaningful relationship Assess if an agent is able to distinguish spurious relations by excluding spurious features TF04No Domain Feature Engineering Prediction task requires a domain-specific feature transformation that is not apparent in the data Assess if an agent is able to apply feature transformation utilizing its pre-trained domain knowledge. TF05Data Leakage in Feature Selection Dataset includes features that are not expected to be used at training time. Assess if an agent is deliberately excluding the features. TF06Wrong Metric Selection Task with imbalanced classes yielding high accuracy if not evaluated with a proper class-balancing metric Assess if an agent chooses the appropriate metric accounting for imbalance 4SURFACING SILENT FAILURES IN DATA SCIENCE AGENTS Here, we present the insights discovered using the evaluation methods described in Section 3. We first describe the specific experimental setup used for the evaluation in Section 4.1, then describe the results and main takeaways of the large-scale analysis in Section 4.2, subsequently show the results and insights in Section 4.3, and finally present the comparisons with expert solutions in Section 4.4. 4.1EXPERIMENTAL SETUP Datasets. The evaluation set contains 220 tasks paired with corresponding datasets and is used for the large-scale failure mode analysis. The tasks are drawn from five sources: 108 from STRABLE (Blayer et al., 2026), 44 from Kaggle, 36 from OpenML, 24 from UCI 1 , and 8 from MLE-bench (Chan et al., 2025). The benchmark comprises 123 regression tasks, of which 122 have a single output and one has multi-outputs, and 97 classification tasks, of which 54 are binary and 43 are multi-class. To prepare the datasets, we perform an 80:20 split for the train and test sets. At runtime, agents are provided with both sets and are expected not to utilize the test set at training time, following the correct practice. Besides, a separate set of 17 tasks is used for the curated test suite , with 3 underlying datasets. Additional dataset details are available in Appendix A.3. Data science agents. We evaluate three data science agents, namely a ReAct baseline (Yao et al., 2022), AIDE (Jiang et al., 2025), and MLEvolve (Du et al., 2026). MLEvolve is the highest-ranking open-source DS agent in MLEBench (Chan et al., 2025), while AIDE consistently achieved the strongest classification performance in the recent benchmark by Nayak et al. (2026). MLEvolve is a self-evolving multi-agent system that iteratively optimizes ML pipelines using methods such as progressive Monte Carlo Graph Search, retrospective memory, and hierarchical adaptive code gen- eration. AIDE generates pipelines using an iterative code refinement process, leveraging evaluation feedback and execution logs to progressively improve generated solutions over multiple iterations. It consistently achieved the strongest classification performance in the recent benchmark by Nayak et al. (2026). For comparison, we set both AIDE and MLEvolve agents’ steps to 10. Additionally, we include AutoGluon (Erickson et al., 2020), a widely used AutoML system, which serves as a 1 Kaggle: kaggle.comOpenML: openml.orgUCI: archive.ics.uci.edu 5 AgentModelWrong task formulationPeeking at test data during EDANot cleaning dataImputation before splittingIgnoring temporal orderNo train/val splitNo feature engineeringScaling before splittingFeature selection before splittingWrong model type for taskNo regularisation in DLNaive ensemblingReusing test set across variantsSingle eval of stochastic modelUsing only one eval metric ReAct Qwen-4B0.020.010.280.000.001.000.980.000.000.01N/AN/AN/A0.480.15 Qwen-27B0.010.120.040.130.360.050.500.000.030.00N/A0.490.000.950.89 Gemini-3.70.020.070.300.060.480.400.380.000.080.00N/A0.90N/A0.040.14 AIDE Qwen-4B0.010.020.720.080.130.070.930.020.000.03N/AN/AN/A0.190.87 Qwen-27B0.030.080.210.030.150.010.710.000.020.00N/A0.81N/A0.080.85 Gemini-3.70.010.150.450.130.470.000.120.030.140.00N/A0.460.000.030.88 MLEvolve Qwen-4B0.020.020.860.090.020.690.940.020.000.00N/AN/AN/A1.000.34 Qwen-27B0.010.080.170.030.170.010.160.000.010.000.000.510.060.760.87 Gemini-3.70.000.100.100.100.360.000.000.010.060.000.000.040.010.130.43 Table 3: Occurrence rate per failure modes (FM) by agent and model over the pipelines for which the FM is applicable. N/A indicates that the number of applicable pipelines (as defined in Section 4.2) for a given FM is less than 20. Red indicates leakage modes and blue indicates non-leakage modes. strong non-agentic baseline based on heuristic-driven optimization and ensemble learning. Com- paring these solutions across different failure modes allows us to obtain insights into what agent frameworks are really improving. LLMs. The capacity of LLMs is important to agentic systems, since smaller models usually perform worse than larger LLMs in agentic tasks. To understand the impact of different models within agentic data science frameworks, we use three models of different capacities. We select qwen-3.5-4b and qwen-3.8-27b, which can be hosted locally on commodity hardware, and gemini-3.7-flash, which we select because it has a good performance-efficiency trade-off in agentic tasks Google (2026). All LLM judges use the more capable gemini-3.1-pro. Addi- tionally, for the curated test suite, we also evaluate gpt-5.6-sol. To assess the reliability of the LLM judge output, we compare with independent human annotations. Across 285 failure mode rat- ings among 19 pipelines, the judge achieves 89.5% agreement with the human annotator (Cohen’s κ = 0.62, 95% CI [0.50, 0.73]), with precision (0.71) and recall (0.65) for detecting present failures. The detailed agreement breakdown is in Appendix A.4. Validation of dataset memorization robustness. Many tabular prediction tasks are publicly avail- able online, and LLMs are likely to have seen them in their training data. To understand if a good predictive performance is partly because the underlying model has seen the tabular data, we run memorization tests using column header completion (Bordt et al., 2024; Lai et al., 2026). We then select a subset of tasks with high and low memorization rates, respectively. Following a similar procedure as in KramaBench (Lai et al., 2026), we then randomize the column names and rerun the agents on tasks with masked metadata and description. We also rerun the agents on the un- masked version as a placebo to obtain unbiased effects. A large difference in ∆ plc and ∆ alt for a high-memorization set indicates that the performance is derived from memorization and vice versa. Finally, we apply the non-parametric Wilcoxon test to compare whether there are significant predic- tive performance differences when tables are memorized. We test this on three DS agent frameworks paired with gemini-3.7-flash since it has the lowest data science failure rate. We present the results in Appendix A.1. All p values are non-significant in both sets with high and low memoriza- tion rates, indicating that memorizing tables does not significantly affect predictive performance. 4.2LARGE-SCALE ANALYSIS SURFACES RECURRENT SILENT FAILURES Table 3 shows the prevalence of failure modes in agent frameworks and models. It shows that the specific failures the pipelines exhibit depend on how completely they cover the data science workflow. Failures happen either because agents perform operations incorrectly, or because they outright skip parts of the workflow (e.g., “No val split”, “No feature engineering”). More capable models and elaborate frameworks shift failures from skipping steps to failures within these steps. 6 Failures occur across models and frameworks. All framework–model configurations have at least one failure mode that occurs in 43% or more of the pipelines. Agent frameworks reduce some of the failures of the ReAct baseline. With gemini-3.7-flash, both AIDE and MLEvolve reduce “No val split” from 0.40 to 0.00, and MLEvolve reduces “No feature engineering” from 0.38 to 0.00 and “naive ensembling” from 0.90 to 0.04. At the same time, frameworks also in- crease non-leakage failure modes. AIDE reports only a single evaluation metric in 85%–88% of its pipelines regardless of the model, compared with 15% and 14% for ReAct with qwen-3.5-4b and gemini-3.7-flash, which is consistent with its design of scoring and selecting candidate solu- tions by a single validation metric (Jiang et al., 2025). Whether a framework improves adherence to DS practices depends on the model used. For example, AIDE lowers “No feature engineering” with gemini-3.7-flash (0.38 to 0.12), but raises it with qwen-3.8-27b (0.50 to 0.71). Higher capacity models cover the data-science stages better but do not follow good practices. The low rates of leakage failures for small models do not indicate sound practices. ReAct with qwen-3.5-4b never designates a validation set and rarely performs feature engineering; con- sequently, the leakage modes that depend on the agent performing either do not occur (“Impute before split”, “Ignores temporal order”, “Scale before split”, and “Feature-selection before split” are all 0.00). Under AIDE, qwen-3.5-4b does use a validation split, resulting in increased leakage across the related failure mode; for instance, imputation before splitting increases from 0.00 to 0.08. More capable models more frequently perform feature engineering and designate a validation set themselves, but they similarly show elevated leakage failure modes. For example, gemini-3.7-flash ignores the temporal order in more than a third of the pipelines over ap- plicable tasks for all three agents. Overall, the results indicate that model capacity improves the coverage of the data-science workflow but that higher capacity models still commit errors within the expanded workflow. Thus, the raw number of failures over a pipeline is not indicative of the pipelines quality, since skipping part of the workflow removes the opportunity to fail within it. Worse performance (rank) Better performance (rank) absentpresent −0.5 0.0 0.5 1.0 1.5 rank residual FM08 FM04 * FM02 * FM05 * FM15 * FM09 FM14 FM07 FM03 * FM12 *** FM01 FM06 *** Leakage modeNon-leakage mode Figure 2: Adjusted effect of FMs on resid- ual rank in the test set that is accessible to the agent. A high rank indicates worse per- formance, while a low rank indicates better performance (* indicates significance). Leakage extends beyond the taxonomy. We addi- tionally analyse the failures flagged by the judge that fall outside of the fixed taxonomy, with full details re- ported in Appendix A.7. We find additional failures in 37% of the pipelines. Most commonly in the form of further leakage modes, namely leakage of validation into train data, e.g., where preprocessing or target en- coding is fitted before cross-validation, and additional leakage of test into train data. The leakage modes show increasing prevalence with increasing model ca- pacity, following the same trend as the leakage modes inside the taxonomy. Notably, 50% of the pipelines of MLEvolve with gemini-3.7-flash, the con- figuration with the fewest failures within the taxon- omy, exhibit leakage between validation and train data, even though MLEvolve includes a dedicated agent for checking leakages (Du et al., 2026). Failure types correlate with reported performance. Lastly, we analyse how the failures relate to predic- tive performance. For each task, we rank the pipelines of each framework–model configuration by the predic- tive performance the pipelines achieve on the test set provided to the agent. Since the configuration (i.e., a combination of model and the agent framework) influ- ences the failures that occur in a pipeline as well as its performance, a direct comparison of raw ranks would primarily reflect differences between these configurations. We therefore compare each pipeline’s rank to the rank expected for its configuration, and measure how this difference changes when a failure mode is present (Appendix A.6). Figure 2 shows that leakage and non-leakage modes affect performance in opposite directions. All data leakage modes lead to improved rankings, which can be expected as leakage introduces information from the evaluation data into the training pro- cess. This illustrates why downstream performance alone is not a good measure of agentic DS 7 capability. The non-leakage failure modes have the opposite relation: more failure modes correlate with lower ranks. Not using a validation split ( FM06) to assess model generalizability has the largest effect, deteriorating the performance by more than a full rank position on average. An exception to the pattern is that using only one evaluation metric ( FM15) is associated with a better rank. We hypothesize that pipelines that evaluate a single metric optimize narrowly for the metric specified by the task, which is also the metric we rank by, possibly at the cost of robustness that a single metric cannot capture. Overall, the results show that a better score on test data does not imply a better pipeline, and evaluating agents solely by their scores can reward leakage modes. 4.3CONTROLLED EVALUATION CONFIRMS CONSISTENT FAILURE PATTERNS Figure 3 reports failure rates on the six controlled tests for ReAct, AIDE, and MLEvolve us- ing gemini-3.7-flash and gpt-5.6-sol.Figure 4 further examines how these fail- ures change as increasingly explicit hints are provided. We also evaluated qwen-3.5-4b and qwen-3.8-27b; however, most runs failed to produce usable executable pipelines and therefore are excluded from the analysis. Next, we discuss our main findings in turn. Some methodological failures persist across configurations. The clearest examples are correla- tion and causation reasoning ( TF03) and leakage in feature selection (TF05), where every configu- ration reaches a failure rate of 1.0. Messy data normalization (TF02) shows similar behaviour: five configurations fail every run, while ReAct with gemini-3.7-flash fails at a rate of 0.8. In con- trast, class imbalance ( TF01 ), domain feature engineering ( TF04 ), and metric selection ( TF06 ) vary substantially across agents and models, indicating that different methodological decisions depend on both the underlying LLM and the agent framework. Stronger models do not consistently yield better data science practice.Compared to gemini-3.7-flash, gpt-5.6-sol reduces failures for ReAct on class imbalance ( TF01) and domain feature engineering (TF04), but the effect does not generalize across tests. This suggests that improvements in model capability do not transfer uniformly to methodological decision-making. Explicit hints reduce failures, but not all. Figure 3 shows that ReAct and AIDE improve sharply as hints become more explicit, with failure rates approaching zero under the strongest guidance. This suggests that many failures arise from failing to recognize the relevant methodological constraint rather than from an inability to carry out the correct practice once prompted. However, MLEvolve behaves differently: although moderate hints reduce its failure rate, stronger hints do not lead to further improvement, and its failure rate remains substantially higher than ReAct and AIDE under more explicit guidance. This points to a limitation of more advanced frameworks, where elaborate search and optimization may fail to maintain explicit constraints during the pipeline generation. ReActAIDEMLEvolve 0.0 0.5 1.0 Fail rate (mean ± SD) TF01 Ignoring class imbalance 0.76 0.64 0.80 n=2 0.36 0.56 0.80 n=3 ReActAIDEMLEvolve TF02 Not normalizing messy data 0.801.001.001.001.001.00 ReActAIDEMLEvolve TF03 Correlation vs. causation 1.001.001.001.001.001.00 n=4 ReActAIDEMLEvolve 0.0 0.5 1.0 Fail rate (mean ± SD) TF04 Missing domain feature eng. 1.00 0.00 0.10 0.20 0.00 0.30 ReActAIDEMLEvolve TF05 Data leakage in feat. sel. 1.001.001.001.001.001.00 ReActAIDEMLEvolve TF06 Wrong metric selection 0.00 0.40 0.20 1.00 0.00 1.00 gemini-3.7-flashgpt-5.6-sol Figure 3: Results for the curated test suite of failure modes. Failure rate represents failure occurrences per failure mode, averaged over n = 5 runs. A failure rate of 1.0 means it occurs in every run. 0.0 0.5 1.0 gemini-3.7-flash 1234 0.0 0.5 1.0 gpt-5.6-sol Fail rate (mean ± SD) Hint level ReActAIDEMLEvolve Figure 4: Average FMs per hint level. Hint level 1 is no hint; higher is more explicit. 8 4.4DATA SCIENCE AGENTS RARELY DISCOVER EXPERT-LEVEL STRATEGIES Table 4 compares agent-generated pipelines with AutoGluon solutions and the 1st-place Kaggle solutions across five challenges. Expert solutions remain ahead, and the performance gap varies by challenge. On the two Playground competitions, Heart Disease Prediction and Obesity risk, the gap is relatively small, while larger gaps remain on Single-Cell Perturbation, Problematic Internet Use, and Survival Predictions. This suggests that automated pipelines can be competitive on relatively accessible tabular tasks, while more specialized challenges leave large room for improvements. Table 4: Leaderboard performance across Kaggle challenges. Scores reported as private / public. Best overall score is bolded, and the second-best is underscored. AutoGluon solutions are applicable only for challenges with CSV uploads (i.e., heart disease prediction and obesity risk) which are playground tasks and hence more simplistic in nature. Data Science AgentsAutoMLBaseline ChallengeMetricReActAIDEMLEvolveAutoGluon1st Place (Human) Single-Cell PerturbationsMRRMSE↓1.1020 / 0.76900.8970 / 0.66000.8310/ 0.6170– / –0.7290 / 0.5230 Heart Disease PredictionAUC-ROC↑0.9547 / 0.95310.9549 / 0.95330.9546 / 0.95310.9551/ 0.95360.9554 / 0.9542 Obesity RiskAccuracy↑0.9065 / 0.90900.9059 / 0.90250.9071 / 0.90350.9074/ 0.90750.9116 / 0.9234 Problematic Internet UseQWK↑0.4440/ 0.46800.4280 / 0.46400.4170 / 0.4480– / –0.4820 / 0.5010 Survival PredictionsC-index↑0.6502 / 0.64650.6536 / 0.64880.3155 / 0.3233– / –0.7013 / 0.6981 No agent dominates across tasks. MLEvolve performs best among the agents on Single-Cell Perturbations, ReAct on Problematic Internet Use, and AIDE on Survival Predictions. These results suggest that improvements introduced by the frameworks are not universal. Interestingly, MLEvolve performs poorly on Survival Predictions because it optimized on the inverted ranking, illustrating how a single error in decision-making can dominate downstream performance. Case Study. To examine where this gap comes from, we compare the pipelines generated by Re- Act, AIDE, and MLEvolve using gemini-3.7-flash with the 1st-place solution for the Kaggle Problematic Internet Use challenge (Figure 8 in Appendix A.8). Our test split contains PCIAT- * variables, including PCIAT-PCIAT Total, from which the target sii can be derived, although these variables are not included in the actual Kaggle test set. ReAct and AIDE selected these leaked features and consequently achieved local QWK scores near 1.0, despite producing pipelines that would fail under the competition setting. This again confirms that predictive scores during agents’ optimization are not trustworthy. Structural evaluation further reveals recurring weaknesses across frameworks: ReAct exhibited preprocessing leakage, limited feature engineering, arbitrary ensem- ble weights, and invalid test IDs; AIDE relied largely on raw features and mishandled categorical variables; and MLEvolve produced richer domain-informed features but still introduced leakage dur- ing encoding and relied on equal-weight ensembling. But this case study also indicates that the gap to expert solutions goes beyond failures. The 1st-place solution has fundamentally different, creative modelling choices. For example, it predicts the continuous PCIAT Total rather than sii directly, applied optimized thresholds only at the final stage, used a Tweedie objective, adopted multi-seed 10-fold cross-validation, and combined diverse model families. These findings can inform future DS agent design to also focus on higher-level choices in problem formulation, task-specific objectives, validation design, feature engineering, and model diversity. 5CONCLUSION With the strong coding capabilities of large language models, they are increasingly integrated in data science agents. With higher-capacity models and advanced data science scaffolding, recent bench- marks show improving downstream performance. In this work, we systematically evaluate failure modes in the pipelines that DS agents implement to get a more nuanced view of their true data science practices beyond accuracy. We perform a large-scale analysis across 220 tasks and nine configurations of model–agent configurations, an extensible controlled test suite, and comparisons with expert real-world solutions. We surface many different failures that purely downstream perfor- mance evaluation masks. In fact, our results indicate that data leakage failure modes – which we identify to exist in many forms – can actually lead to stronger predictive performance on a test set. 9 We also find that more sophisticated agent frameworks do not necessarily eliminate these failures. Despite the presence of dedicated data leakage checks in some frameworks, these can still exhibit leakage failures. This suggests that preventing such failures requires more than adding specialized components. Agent designs must reason more explicitly about methodological validity throughout the pipeline. Altogether, our findings reinforce the need to evaluate agentic data science beyond accuracy. We envision that our findings will improve agentic DS evaluations broadly, and inform the design of future agentic data science systems and models. AI USE STATEMENT In this work, we used generative AI tools to implement methods, to clean and reformat datasets, to support qualitative and thematic data analysis, and to interpret results. We have not used genera- tive AI tools to design or provide feedback on research methodology or experiments, to generate synthetic data sets, to help develop theoretical models or conceptual frameworks, to propose or re- fine hypotheses, and to assist in the writing of proofs, to formulate mathematical claims, to provide critical ingredients for proving mathematical claims, and to assist with translation are not applica- ble to this work. Additionally, we used generative AI tools to create or modify scientific figures, suggest experimental parameters, create and edit software code, create artifacts such as traces and LLM-judge logs evaluated in this project, and to edit the research paper to improve readability. We have reviewed all AI-assisted work. We validated each of the generated artifacts, and thoroughly reviewed and tested the generated code by one author. We validated every generated figure and as- sessed its validity. We take responsibility for the final content of this work, including text, claims or artifacts produced with the aid of generative AI. ACKNOWLEDGEMENTS This work was supported by the Dutch Research Council (NWO, AiNed Fellowship grant NGF.1607.22.045) and a grant from SAP. We also gratefully acknowledge support through com- pute credit grants from Google and OpenAI. This work also used the Dutch national e-infrastructure with the support of the SURF Cooperative using grant no. EINF-19960. REFERENCES Gioia Blayer, Myung Jun Kim, F ́ elix Lefebvre, Lennart Purucker, Alan Arazi, Eilam Shapira, Roi Reichart, Frank Hutter, Marine Le Morvan, David Holzm ̈ uller, and Ga ̈ el Varoquaux. Strable: Benchmarking tabular machine learning with strings, 2026. URL https://arxiv.org/ abs/2605.12292. Sebastian Bordt, Harsha Nori, Vanessa Cristiny Rodrigues Vasconcelos, Besmira Nushi, and Rich Caruana. Elephants never forget: Memorization and learning of tabular data in large language models. In First Conference on Language Modeling, 2024. URL https://openreview. net/forum?id=HLoWN6m4fS. Pete Bryan, Giorgio Severi, Joris de Gruyter, Daniel Jones, Blake Bullwinkel, Amanda Min- nich, Shiven Chawla, Gary Lopez, Martin Pouliot, Adam Fourney, Whitney Maxwell, Katherine Pratt, Saphir Qi, Nina Chikanov, Roman Lutz, Sekhar Rao Dheekonda, Bolor- Erdene Jagdagdorj, Eugenia Kim, Justin Song, Keegan Hines, Daniel Jones, Richard Lundeen, Sam Vaughan, Victoria Westerhoff, Yonatan Zunger, Chang Kawaguchi, Mark Russinovich, and Ram Shankar Siva Kumar.Taxonomy of Failure Mode in Agentic AI Systems.URL https://cdn-dynmedia-1.microsoft.com/is/content/ microsoftcorp/microsoft/final/en-us/microsoft-brand/documents/ Taxonomy-of-Failure-Mode-in-Agentic-AI-Systems-Whitepaper.pdf. Mert Cemri, Melissa Z. Pan, Shuyi Yang, Lakshya A. Agrawal, Bhavya Chopra, Rishabh Tiwari, Kurt Keutzer, Aditya Parameswaran, Dan Klein, Kannan Ramchandran, Matei A. Zaharia, Joseph Gonzalez, and Ion Stoica. Why Do Multi-Agent LLM Systems Fail?Ad- vances in Neural Information Processing Systems, 38, 2025.doi: 10.52202/085713-4082. URL https://proceedings.neurips.c/paper_files/paper/2025/ 10 hash/b1041e52d3be19f0a9bc491657488e4a-Abstract-Datasets_and_ Benchmarks_Track.html. Jun Shern Chan, Neil Chowdhury, Oliver Jaffe, James Aung, Dane Sherburn, Evan Mays, Giulio Starace, Kevin Liu, Leon Maksin, Tejal Patwardhan, Aleksander Madry, and Lilian Weng. MLE- bench: Evaluating Machine Learning Agents on Machine Learning Engineering. International Conference on Learning Representations, 2025:50466–50494, May 2025. Tianji Cong, Julian Martin Eisenschlos, Daniel Gomm, Leo Grinsztajn, Andreas C M ̈ uller, Anupam Sanghi, Jan-Micha Bodensohn, Vadim Borisov, Michael Cochez, Katharina Eggensperger, et al. Position: unlocking the full potential of data science requires tabular foundation models, agents, and humans. 2025. Tijl De Bie, Luc De Raedt, Jos ́ e Hern ́ andez-Orallo, Holger H Hoos, Padhraic Smyth, and Christo- pher KI Williams. Automating data science. Communications of the ACM, 65(3):76–87, 2022. Shangheng Du, Xiangchao Yan, Jinxin Shi, Zongsheng Cao, Shiyang Feng, Zichen Liang, Boyuan Sun, Tianshuo Peng, Yifan Zhou, Xin Li, Jie Zhou, Liang He, Bo Zhang, and Lei Bai. MLEvolve: A Self-Evolving Framework for Automated Machine Learning Algorithm Discovery, June 2026. URL https://arxiv.org/abs/2606.06473v1. Nick Erickson, Jonas Mueller, Alexander Shirkov, Hang Zhang, Pedro Larroy, Mu Li, and Alexan- der Smola. AutoGluon-tabular: Robust and accurate AutoML for structured data, 2020. URL https://arxiv.org/abs/2003.06505. arXiv: 2003.06505 [stat.ML]. Nick Erickson, Lennart Purucker, Andrej Tschalzev, David Holzm ̈ uller, Prateek Desai, David Sali- nas, and Frank Hutter. Tabarena: A living benchmark for machine learning on tabular data. Advances in Neural Information Processing Systems, 38, 2026. Matthias Feurer, Aaron Klein, Katharina Eggensperger, Jost Springenberg, Manuel Blum, and Frank Hutter.Efficient and robust automated machine learning.In C. Cortes, N. Lawrence, D. Lee, M. Sugiyama, and R. Garnett (eds.), Advances in neural in- formation processing systems,volume 28. Curran Associates,Inc.,2015.URL https://proceedings.neurips.c/paper_files/paper/2015/file/ 11d0e6287202fced83f79975ec59a3a6-Paper.pdf. Google. Gemini 3.7 Flash: Our most intelligent workhorse model. Google Blog, August 13 2026. URL https://blog.google/innovation-and-ai/models-and-research/ gemini-models/introducing-gemini-3-7-flash/. Antoine Grosnit, Alexandre Maraval, Refinath S. N, Zichao Zhao, James Doran, Giuseppe Paolo, Albert Thomas, Jonas Gonzalez, Abhineet Kumar, Khyati Khandelwal, Abdelhakim Benechehab, Hamza Cherkaoui, Youssef Attia El-Hili, Kun Shao, Jianye Hao, Jun Yao, Bal ́ azs K ́ egl, Haitham Bou-Ammar, and Jun Wang. Kolb-Based Experiential Learning for Generalist Agents with Human-Level Kaggle Data Science Performance, September 2025. URL http://arxiv. org/abs/2411.03562. arXiv:2411.03562 [cs.LG]. Alex Gu, Naman Jain, Wen-Ding Li, Manish Shetty, Kevin Ellis, Koushik Sen, and Armando Solar- Lezama. Tasks, challenges, and paths towards AI for software engineering. In ICLR 2025 Third Workshop on Deep Learning for Code, 2025. URL https://openreview.net/forum? id=t0QaoJqjdw. Siyuan Guo, Cheng Deng, Ying Wen, Hechang Chen, Yi Chang, and Jun Wang. DS-Agent: Au- tomated Data Science by Empowering Large Language Models with Case-Based Reasoning. In Proceedings of the 41st International Conference on Machine Learning, p. 16813–16848. PMLR, July 2024. URL https://proceedings.mlr.press/v235/guo24b.html. Noah Hollmann, Samuel M ̈ uller, Lennart Purucker, Arjun Krishnakumar, Max K ̈ orfer, Shi Bin Hoo, Robin Tibor Schirrmeister, and Frank Hutter.Accurate predictions on small data with a tabular foundation model. Nature, 637(8045):319–326, January 2025. ISSN 1476- 4687. doi: 10.1038/s41586-024-08328-6. URL https://w.nature.com/articles/ s41586-024-08328-6. 11 Qian Huang, Jian Vora, Percy Liang, and Jure Leskovec. MLAgentBench: evaluating language agents on machine learning experimentation. In Proceedings of the 41st International Conference on Machine Learning, volume 235 of ICML’24, p. 20271–20309, Vienna, Austria, July 2024. JMLR.org. Frank Hutter, Lars Kotthoff, and Joaquin Vanschoren (eds.).Automated Machine Learning: Methods, Systems, Challenges.The Springer Series on Challenges in Machine Learning. Springer International Publishing, Cham, 2019. ISBN 978-3-030-05317-8 978-3-030-05318- 5. doi: 10.1007/978-3-030-05318-5. URL http://link.springer.com/10.1007/ 978-3-030-05318-5. Zhengyao Jiang, Dominik Schmidt, Dhruv Srikanth, Dixing Xu, Ian Kaplan, Deniss Jacenko, and Yuxiang Wu. AIDE: AI-driven exploration in the space of code, 2025. URL https://arxiv. org/abs/2502.13138. arXiv: 2502.13138 [cs.AI]. Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. Swe-bench: Can language models resolve real-world github issues? In International Conference on Learning Representations, volume 2024, p. 54107–54157, 2024. Liqiang Jing, Zhehui Huang, Xiaoyang Wang, Wenlin Yao, Wenhao Yu, Kaixin Ma, Hongming Zhang, Xinya Du, and Dong Yu. DSBench: How Far Are Data Science Agents from Becoming Data Science Experts? In The Thirteenth International Conference on Learning Representations, 2025. Smitha Kumar, Michael A Lones, Manuel Maarek, and Hind Zantout. Navigating pitfalls: Evaluat- ing llms in machine learning programming education. arXiv preprint arXiv:2505.18220, 2025. Eugenie Lai, Gerardo Vitagliano, Ziyu Zhang, Om Chabra, Sivaprasad Sudhir, Anna Zeng, Anton Zabreyko, Chenning Li, Ferdi Kossmann, Jialin Ding, et al. Kramabench: A benchmark for ai systems on data-to-insight pipelines over data lakes. In International Conference on Learning Representations, volume 2026, p. 142883–142912, 2026. Miles Q. Li, Benjamin C. M. Fung, Martin Weiss, Pulei Xiong, Khalil Al-Hussaeni, and Claude Fachkha. A benchmark for evaluating outcome-driven constraint violations in autonomous AI agents, 2026. URL https://arxiv.org/abs/2512.20798. arXiv: 2512.20798 [cs.AI]. Michael A Lones. Avoiding common machine learning pitfalls. Patterns, 5(10), 2024. Kartik Nagaraj Nayak, Nitishkumar Solpure, Niladri Mitra, Tom Zehle, Alexander Pfefferle, Omar Swelam, and Frank Hutter. Towards Benchmarking Agentic Data Scientists. In AutoAI Meets Foundation Models, August 2026. URL https://openreview.net/forum?id= UoYzHOKZaL. Fan Nie, Junlin Wang, Harper Hua, Federico Bianchi, Yongchan Kwon, Zhenting Qi, Owen Queen, Shang Zhu, and James Zou. DSGym: A Standardized and Holistic Framework for Evaluating and Training Data Science Agents. June 2026. URL https://openreview.net/forum?id= 2WrNPRW9Km. Randal S. Olson, Ryan J. Urbanowicz, Peter C. Andrews, Nicole A. Lavender, La Creis Kidd, and Jason H. Moore. Applications of Evolutionary Computation: 19th European Conference, EvoAp- plications 2016, Porto, Portugal, March 30 – April 1, 2016, Proceedings, Part I, chapter Automat- ing Biomedical Data Science Through Tree-Based Pipeline Optimization, p. 123–137. Springer International Publishing, 2016. ISBN 978-3-319-31204-0. doi: 10.1007/978-3-319-31204-0 9. URL http://dx.doi.org/10.1007/978-3-319-31204-0_9. Melissa Z Pan, Negar Arabzadeh, Riccardo Cogo, Yuxuan Zhu, Alexander Xiong, Lakshya A Agrawal, Huanzhi Mao, Emma Shen, Sid Pallerla, Liana Patel, et al. Measuring agents in pro- duction. arXiv preprint arXiv:2512.04123, 2025. Liana Patel, Siddharth Jha, Negar Arabzadeh, Carlos Guestrin, Ion Stoica, and Matei Zaharia. What happens when the model eats the stack? Rethinking the research agenda for data agents to withstand the bitter lesson, 2026. URL https://arxiv.org/abs/2609.03141. arXiv: 2609.03141 [cs.DB]. 12 Jingang Qu, David Holzm ̈ uller, Ga ̈ el Varoquaux, and Marine Le Morvan. TabICL: A Tabular Foun- dation Model for In-Context Learning on Large Data. In Proceedings of the 42nd International Conference on Machine Learning, volume 267. PMLR, 2025. doi: 10.48550/arXiv.2502.05564. URL https://proceedings.mlr.press/v267/qu25d.html. Fan Shu, Yite Wang, Ruofan Wu, Boyi Liu, Zhewei Yao, Yuxiong He, and Feng Yan. DARE- bench: Evaluating Modeling and Instruction Fidelity of LLMs in Data Science. In The Four- teenth International Conference on Learning Representations, October 2025. URL https: //openreview.net/forum?id=eJV3JhJvZF. Zhaoyan Sun, Shan Zhong, Daizhou Wen, Jiaxing Han, Guoliang Li, Ying Yan, Peng Zhang, Yu Su, Xiang Qi, Baolin Sun, Chengyuan Yang, Tao Fang, and Huaiyu Ruan. AgenticDataBench: a comprehensive benchmark for data agents, 2026. URL https://arxiv.org/abs/2607. 01647. arXiv: 2607.01647 [cs.DB]. Frank Fangzheng Xu, Yufan Song, Boxuan Li, Yuxuan Tang, Kritanjali Jain, Mengxue Bao, Zora Wang, Xuhui Zhou, Zhitong Guo, Murong Cao, et al. Theagentcompany: benchmarking llm agents on consequential real world tasks. Advances in Neural Information Processing Systems, 38, 2025. Shunyu Yao, Jeffrey Zhao, Dian Yu, Izhak Shafran, Karthik R Narasimhan, and Yuan Cao. React: Synergizing reasoning and acting in language models. In NeurIPS 2022 Foundation Models for Decision Making Workshop, 2022. Ruiyi Zhang, Peijia Qin, Qi Cao, Li Zhang, and Pengtao Xie. AIBuildAI: An AI agent for auto- matically building AI models. In ICML 2026 Workshop: AI as a Tool for Mathematics, Com- puter Science, and Machine Learning, 2026. URL https://openreview.net/forum? id=nckjXxN9WZ. Lianmin Zheng, Wei-Lin Chiang, Ying Sheng, Siyuan Zhuang, Zhanghao Wu, Yonghao Zhuang, Zi Lin, Zhuohan Li, Dacheng Li, Eric Xing, et al. Judging llm-as-a-judge with mt-bench and chatbot arena. Advances in neural information processing systems, 36:46595–46623, 2023. Yuqi Zhu, Yi Zhong, Jintian Zhang, Ziheng Zhang, Shuofei Qiao, Yujie Luo, Lun Du, Da Zheng, Ningyu Zhang, and Huajun Chen. Why do open-source LLMs struggle with data analysis? a systematic empirical study. In Proceedings of the Fortieth AAAI Conference on Artificial In- telligence and Thirty-Eighth Conference on Innovative Applications of Artificial Intelligence and Sixteenth Symposium on Educational Advances in Artificial Intelligence, volume 40 of AAAI’26/IAAI’26/EAAI’26, p. 35239–35247. AAAI Press, June 2026. ISBN 978-1-57735-906- 7. doi: 10.1609/aaai.v40i41.40831. URL https://doi.org/10.1609/aaai.v40i41. 40831. 13 AAPPENDIX A.1DETAILS ON MEMORIZATION CHECK SETUP Table 5 presents the p values for the paired Wilcoxon test on both the high-memorised set and low- memorised set. The testing shows that the performance has no significant changes regardless of memorizing the tables. Table 5: Wilcoxon signed-rank test of ∆ alt vs. the rerun randomized ∆ plc , computed separately for high- and low-memorization rate tasks across agentic frameworks. None of the six tests reaches significance at α = 0.05, so dataset memorization does not measurably influence performance. Agentn (high)Wilcoxon p (high) n (low)Wilcoxon p (low) ReAct170.890180.212 AIDE160.231160.782 MLEvolve160.597170.890 A.2FAILURE MODES DEFINITIONS In Table 6 we include the definition of each of the failure modes evaluated in the large-scale analysis. IDFailure ModeDefinition FM01Wrong task formulationThe agent frames the modelling problem in a way that discards the signal the task actually provides. FM02Peeking at test data during EDAExploring test data during initial analysis creates untestable as- sumptions baked into model design. FM03Not cleaning dataIgnoringdataduplication,missingvalues,andout- liers/inconsistencies before model building. FM04Imputation before splittingPerforming mean/median imputation before splitting – leaks test statistics into training. FM05Ignoring temporal orderRandomly splitting time-series data without respecting tempo- ral order – introduces look-ahead bias. FM06No train/val splitModel trained and evaluated on the same data – performance is a misleading overestimate. FM07No feature engineeringThe agent uses raw columns as-is (at most basic imputa- tion/encoding) with no derived features or domain-informed transforms, even where the task or column names suggest obvi- ous ones. FM08Scaling before splittingFitting scaler on the full dataset before splitting – test statistics leak into training. FM09Feature selection before splittingSelecting features on the full dataset before splitting – causes test leakage. FM10Wrong model type for taskUsing a regression model for a classification task (or vice versa) – conceptual mismatch. FM11No regularisation in DLTraining deep learning models without dropout or weight decay – prone to overfitting. FM12Naive ensemblingWhen the agent combines multiple models, it uses an unweighted/equal-weight average or simple majority vote with no tuning of the combination itself, where a more sophisticated combination is straightforward given what’s already computed. FM13Reusing test set across variantsSame test set used to select among multiple models – test set gradually leaks into model selection (sequential overfitting). FM14Single eval of stochastic modelSingle evaluation of a stochastic/unstable model; results may not reflect true performance. FM15Using only one eval metricSingle metric gives an incomplete picture; different metrics re- veal different failure modes. Table 6: Failure modes definition. 14 A.3DATASET DETAILS Table 7 shows the characteristics of the tasks we curated, including source information, number of tasks by type, median row, and median of features. Table 8 shows the domain distribution. SourceNRegr.Bin.-cls.Multi-cls.Med. rowsMed. feat. Kaggle4418178100,82024 MLE-bench86206,97613 OpenML361015113,10418 STRABLE1087613197,71017 UCI24127511,80513 Total22012254438,69318 Table 7: Dataset characteristics across the 220 benchmark tasks. DomainTasks Healthcare50 Finance47 Science25 Retail23 Social21 Energy17 Transportation14 Education11 Environment8 Mixed3 Bioinformatics1 Total220 Table 8: Domain distribution across the 220 benchmark tasks. A.4HUMAN ANNOTATOR AGREEMENT To assess the reliability of the LLM judge, a human annotator independently re-labeled all 15 failure modes on 19 randomly sampled pipelines (11 of the 30 originally sampled pipelines were excluded because their generated code was no longer recoverable on disk). Agreement was scored on a binary present/not-present basis per failure mode; a diagnostic check showed the annotator’s absent/N/A distinction did not track the judge’s own applicability gating consistently in either direction, so that distinction was not scored as disagreement. Across all 285 (pipeline × failure-mode) ratings, the judge agreed with the human annotator on 89.5% of ratings (Cohen’s κ = 0.62, 95% CI [0.50, 0.73], via a pipeline-cluster bootstrap), indicating substantial agreement. Precision and recall for the present class were comparable (precision = 0.71, recall = 0.65), with no significant directional bias toward over- or under-flagging failures (p = 0.29). Disagreement concentrated in a small subset of failure modes, i.e., naive ensembling and reliance on a single evaluation metric (each at 0.68 agreement), while the remaining 13 failure modes achieved≥0.79 agreement, 9 of them≥0.89. A.5FAILURE ANALYSIS In Table 10 we show the number of applicable pipelines for each of the failure modes that require a specific pipeline stage or type of data to be present. A.6EFFECTS OF FAILURES ON PREDICTIVE PERFORMANCE To calculate the failure modes’ effect on the predictive performance, we provide the correlation between the two variables. However, scores alone are not comparable because tasks use different 15 FMFailure ModenAgreementPrecisionRecallHuman Present FM01Wrong task formulation † 190.950.00–0 FM02Peeking at test data during EDA † 190.950.00–0 FM03Not cleaning data190.950.801.004 FM04Imputation before splitting190.790.500.254 FM05Ignoring temporal order † 190.950.501.001 FM06No train/val split190.890.671.004 FM07No feature engineering191.001.001.005 FM08Scaling before splitting190.891.000.333 FM09Feature selection before splitting † 190.840.000.001 FM10Wrong model type for task † 191.00–0 FM11No regularisation in DL † 191.00–0 FM12Naive ensembling190.680.500.676 FM13Reusing test set across variants † 190.95–0.001 FM14Single eval of stochastic model190.891.000.504 FM15Using only one eval metric190.681.000.6216 Overall (κ = 0.62)2850.890.710.6549 Table 9: Human-vs-LLM-judge agreement on 19 randomly sampled, independently annotated pipelines. Scored as Present vs. Not-Present (all 15 failure modes per pipeline). Cohen’s κ = 0.62 (95% CI [0.50, 0.73]) indicates moderate, above-chance agreement. Precision exceeds recall gen- erally (judge-as-predictor, human as ground truth), indicating the judge is conservative rather than strict: reported failure rates in the main results are more likely an under- than an over-estimate. AgentModeln judgedIgnoring temporal orderNo regularisation in DLReusing test set across variantsSingle eval of stochastic modelNaive ensembling ReAct Gemini-3.721913700211198 Qwen-4B220138002191 Qwen-27B2201380124217118 AIDE Gemini-3.7219137341215215 Qwen-4B211133001903 Qwen-27B1851120417627 MLEvolve Gemini-3.7219124134118194189 Qwen-4B654521212 Qwen-27B203125454619498 Total176110891843341637851 as % of total–61.8%10.4%19.0%93.0%48.3% Table 10: Number of applicable pipelines per failure mode, by agent and model. metrics. Therefore, we use the rank among all solutions as the measurement of predictive perfor- mance. We run generated solutions on the tasks and calculate the score on the pre-processed test set. Finally, we rank the solutions across all 9 configurations. A naive correlation between failure modes and predictive rank is confounded by model and agent capability. For example, qwen-3.5-4b may exhibit fewer detected failures because it produces simpler pipelines, while also ranking poorly. We therefore estimate the effect of each failure mode after controlling for model and agent identity. rank∼ present + C(model) + C(agent) For each failure mode, we fit a model that predicts a pipeline’s rank from three things: whether the failure mode is present, which model produced it, and which agent produced it. Giving the model 16 ReActAIDEMLEvolve 0.0 0.5 1.0 1.5 2.0 2.5 3.0 3.5 4.0 Average failure modes per judged pipeline 2.94 n=220 3.01 n=211 3.34 n=65 3.21 n=220 2.24 n=185 2.49 n=203 2.63 n=219 2.68 n=219 1.22 n=219 Qwen-4BQwen-27BGemini-3.7 Figure 5: Average failure modes per pipeline by agent-model configuration. 051015202530 % of all detected failure instances (n=4549) FM11 No regularisation in DL FM13 Reusing test set across variants FM10 Wrong model type for task FM08 Scaling before splitting FM01 Wrong task formulation FM09 Feature selection before splitting FM04 Imputation before splitting FM02 Peeking at test data during EDA FM05 Ignoring temporal order FM06 No train/val split FM12 Naive ensembling FM03 Not cleaning data FM14 Single eval of stochastic model FM07 No feature engineering FM15 Using only one eval metric 0.0% n=0 0.1% n=4 0.3% n=13 0.4% n=17 0.6% n=27 1.6% n=74 2.7% n=125 2.9% n=134 6.3% n=286 8.4% n=381 9.4% n=426 11.8% n=538 12.8% n=581 18.9% n=859 23.8% n=1084 leakother Figure 6: Failure mode distribution. 4,557 failures detected over 1,761 pipelines, averaging 2.58 failures per pipeline. and agent their own separate adjustments, a model that’s simply bad overall doesn’t get mistaken for the failure mode itself being harmful. The one number we care about is how much presence of the failure mode shifts the rank, once that adjustment is made. For visualization in Figure 7, we use the corresponding partial residual: r i = β 1 present i + ˆε i . 17 Its group means are 0 when the failure is absent and β 1 when present, so the plotted difference directly represents the adjusted effect. absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=-0.60 p=0.26 (n=17) FM08 Scaling before splitting absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=-0.41 p=0.033 (n=123) FM04 Imputation before splitting * absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=-0.38 p=0.03 (n=134) FM02 Peeking at test data during EDA * absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=-0.31 p=0.028 (n=286) FM05 Ignoring temporal order * absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=-0.08 p=0.73 (n=74) FM09 Feature selection before splitting absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=-0.30 p=0.02 (n=1065) FM15 Using only one eval metric * absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=-0.02 p=0.89 (n=572) FM14 Single eval of stochastic model absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=+0.22 p=0.097 (n=848) FM07 No feature engineering absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=+0.29 p=0.016 (n=527) FM03 Not cleaning data * absentpresent −2 0 2 4 6 rank resid. Δ=+0.58 p=9.4e-05 (n=424) FM12 Unweighted ensembling *** absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=+0.70 p=0.15 (n=27) FM01 Wrong task formulation absentpresent −6 −4 −2 0 2 4 6 rank resid. Δ=+1.37 p=4.3e-18 (n=380) FM06 No train/val split *** Qwen-4BQwen-27BGemini-3.7 Figure 7: Effects of each failure mode on predictive performance measured in residual rank. A.7FAILURE MODES BEYOND THE TAXONOMY In addition to the failure modes captured in the taxonomy, we evaluate the additional failure modes the LLM-judge reports as a list of free-text failures (Section 3.1). Across pipelines, the judge flags 2,294 additional failures. We filter these failures to only include actual violations of data science principles, filtering out other issues flagged by the judge, such as failures to produce code or imple- mentation bugs, yielding 1,343 additional data science failures. We assign these failure modes into categories that we extract from manually screening them and then assign a category to each failure by independent keyword matching and through an LLM-judge (qwen-3.5-9b), where disagree- ments are manually resolved. On a sample of 59 reports that were labelled blindly, the final labels agree in 95% of the cases. Additional failure modes. Table 11 shows the three most prominent categories. Validation→train leakage concerns instances where information from the validation data leaks into the trained model, without involving the test set. For instance, preprocessing or target encoding fitted on the full train- ing data before cross-validation, early stopping on the fold the model is scored on, and ensemble weights fitted and scored on the same predictions. Test→train leakage encompasses leakage of test data into the training that falls outside of the taxonomy, such as transforms (e.g., label encod- ing, TF-IDF, or aggregated features) that are fitted on the training and test data. Flawed training protocol includes training without early stopping, predicting with the model of a single fold, and not retraining the final model on the full training data. Less frequent additional categories are in- consistent preprocessing of training and test data, nominal features treated as continuous, identifier columns used as features, target leakage through a feature, and incorrectly implemented metrics, each occurring in at most 6% of the pipelines. Observations.The additional failures follow the same pattern described in Section 4.2. Validation→train leakage increases with model capacity, from 8% of the pipelines for qwen-3.5-4b to 16% for qwen-3.8-27b and 26% for gemini-3.7-flash. It is most fre- quent for MLEvolve (33% with qwen-3.8-27b and 50% with gemini-3.7-flash), whose pipelines frequently combine cross-validation with target encoding, early stopping, and blending, 18 AgentModelValidation → train leakage Test → train leakage Flawed training protocol ReAct Qwen-4B0.000.000.03 Qwen-27B0.080.020.07 Gemini-3.7 0.150.150.12 AIDE Qwen-4B 0.160.010.29 Qwen-27B 0.070.020.03 Gemini-3.70.130.350.01 MLEvolve Qwen-4B 0.050.000.05 Qwen-27B 0.330.000.02 Gemini-3.70.500.140.01 Table 11: Share of pipelines for which the judge reports the three most prominent failure modes beyond the taxonomy. Figure 8: Exemplar pipelines of DS agents generated solutions using gemini-3.7-flash v.s. human expert solution. and it almost never occurs when there is no validation step, as for ReAct with qwen-3.5-4b. MLEvolve with gemini-3.7-flash, the configuration with the fewest failures within the tax- onomy, has the highest share of pipelines with a failure falling outside the taxonomy (57%), indicat- ing that it insufficiently accounts for leakage. Since the judge reports these failures without being prompted for them specifically, the shares should be interpreted as lower bounds on their actual prevalence. A.8PROCEDURAL COMPARISONS BETWEEN AGENTIC SOLUTIONS AND EXPERT SOLUTIONS In Figure 8 we extract the key steps and procedures across solutions generated by three agents and expert solutions from Kaggle. 19