Agentic AutoML on Relational Databases

Most of the world's structured data lives in relational databases. Banks, hospitals, retailers, and governments keep their records in collections of tables linked by keys: customers point to orders, orders point to products, products point to suppliers. This is where the data actually is, and it rarely moves. Machine learning, however, expects a single flat table: one row per example, one column per feature. To bridge the gap, practitioners spend most of their effort flattening the database into that shape — joining tables together, aggregating across relationships ("how many orders did this customer place in the last 30 days?"), and hand-crafting the features that carry the relational structure into a form a model can read. This step is laborious, it discards much of the structure that made the database useful in the first place, and it forces the data out of the system it lives in — which is expensive and often impossible when privacy or governance rules keep the data in place. Relational machine learning offers a different path: learn directly on the relational structure, without flattening and without moving the data. Recent relational deep learning work (Fey et al. 2024; Robinson et al. 2024) treats the database as a graph — the rows are nodes and the foreign keys are edges — and trains a model over that graph in place. The promise is to skip the brittle, manual feature-engineering step entirely and let the model exploit the schema as it stands. This reframes a long-standing problem. Automated Machine Learning (AutoML) was built to take the burden of model selection and hyperparameter tuning off the human (Thornton et al. 2013; Feurer et al. 2015; Hutter, Kotthoff, and Vanschoren 2019). But today's AutoML tools still assume the data arrives as a fixed, single table. They automate the search over algorithms; they do not reason about the data — how it could be reshaped, joined, aggregated, or enriched — which is where real performance gains usually come from (Kanter and Veeramachaneni 2015). On a relational database, the data side is the problem: which tables to bring in, which relationships to traverse, which aggregates to compute. An AutoML system that understands relational structure has a far richer space of moves available to it than one staring at a single table. This is where the current wave of agentic AI becomes interesting. An agent can plan, take actions, and call tools on its own. Pointed at a relational database, an agent could in principle read the schema, decide which relationships are worth exploring, derive new features across tables, augment or enrich the data, and then run the model search — all without a human flattening the database by hand and without copying the data out. But to do this in a principled way, we need to ask a basic question: what is the right way to describe and organize this whole process? What formalism lets an agent reason about schema traversal, feature enrichment, and model search together, rather than as disconnected steps? A second, very practical question is the infrastructure underneath. When an agent experiments with many versions of a relational dataset (materializing a join, adding a derived table, augmenting rows, trying a transformation) it needs a fast and cheap way to create, modify, and discard these versions — ideally in place, so the data never leaves the database. Database clones — lightweight copy-on-write branches of a database that can be spun up and thrown away — may be a natural fit. Each experiment becomes a clone the agent can play with without disturbing the original or moving anything. Whether database clones are actually a good backbone for agentic relational AutoML is an open and practical question. RESEARCH QUESTIONS RQ1 (Landscape). What do AutoML and relational machine learning look like today? Which problems do current tools solve well, and where do they fall short — especially in doing ML on relational data without flattening or moving it, and in feature enrichment across tables? RQ2 (Formalism). Is there a clean way to describe the combined process of schema exploration, feature enrichment, and model search so that an agentic system can reason about it directly over a relational database? What would such a formalism need to capture? RQ3 (Infrastructure). Are database clones a sensible foundation for managing the many dataset versions an agentic relational AutoML system would generate, in place and without copying the data out? What are the trade-offs in speed, storage, and convenience? APPROACH Survey first. The core deliverable is a literature review — essentially a small survey paper — mapping out the state of AutoML and relational machine learning. Students read and organize recent work on automated model selection, hyperparameter optimization, automated feature engineering, relational deep learning, and data augmentation, and place agentic approaches in that context. Identify the gaps. From the survey, we pin down concretely where today's tools stop short, with attention to the data side (relational feature enrichment, augmentation, learning in place) rather than only the algorithm side. Sketch the formalism. Based on what the survey reveals, we outline what a formal description of agentic relational AutoML might look like. This is exploratory and conceptual; the goal is a clear sketch, not a finished theory. Consider the infrastructure angle. Where time allows, we examine database clones as a possible substrate for managing relational dataset experiments in place, and discuss the practical trade-offs. LOGISTICS Time commitment: 3 months, around 3 hours per week. Meetings: roughly 1 hour per week. Team size: 2 to 3 students. Mode: remote. Authorship: co-authorship on the resulting survey paper, with credit reflecting contribution. MINIMUM REQUIREMENTS Interest in research — reading literature, organizing ideas, writing them up clearly. Comfort reading CS papers. Working knowledge of classical machine learning. Familiarity with relational databases and basic SQL. Good Python skills. Nice to have (can be picked up during the project): SDLC familiarity, some CUDA/parallel programming exposure, prior use of an AutoML library (auto-sklearn, AutoGluon, H2O) or a relational/graph learning library. REFERENCES Fey et al. 2024. "Relational Deep Learning: Graph Representation Learning on Relational Databases." arXiv:2312.04615. Feurer et al. 2015. "Efficient and Robust Automated Machine Learning." NeurIPS 28. Hutter, Kotthoff, and Vanschoren, eds. 2019. Automated Machine Learning: Methods, Systems, Challenges. Springer. Kanter and Veeramachaneni. 2015. "Deep Feature Synthesis: Towards Automating Data Science Endeavors." IEEE DSAA. Robinson et al. 2024. "RelBench: A Benchmark for Deep Learning on Relational Databases." NeurIPS. arXiv:2407.20060. Thornton et al. 2013. "Auto-WEKA: Combined Selection and Hyperparameter Optimization of Classification Algorithms." KDD.