2509.18710

# Autonomous Data Agents: A New Opportunity for Smart Data **Authors**: Yanjie Fu, Dongjie Wang, Wangyang Ying, Xinyuan Wang, Xiangliang Zhang, Huan Liu, Jian Pei > yanjie.fu@asu.eduArizona State UniversityArizonaUSA > wangdongjie@ku.eduUniversity of KansasKansasUSA > wangyang.ying,xwang735@asu.eduArizona State UniversityArizonaUSA > xzhang33@nd.eduUniversity of Notre DameIllinoisUSA > huanliu@asu.eduArizona State UniversityArizonaUSA > j.pei@duke.eduDuke UniversityNorth CarolinaUSA Abstract. As data continues to grow in scale and complexity, preparing, transforming, and analyzing it remains labor-intensive, repetitive, and difficult to scale. Since data contains knowledge and AI learns knowledge from it, the alignment between AI and data is essential. However, data is often not structured in ways that are optimal for AI utilization. Moreover, an important question arises: how much knowledge can we pack into data through intensive data operations? Autonomous data agents (DataAgents), which integrate LLM reasoning with task decomposition, action reasoning and grounding, and tool calling, can autonomously interpret data task descriptions, decompose tasks into subtasks, reason over actions, ground actions into python code or tool calling, and execute operations. Unlike traditional data management and engineering tools, DataAgents dynamically plan workflows, call powerful tools, and adapt to diverse data tasks at scale. This report argues that DataAgents represent a paradigm shift toward autonomous data-to-knowledge systems. DataAgents are capable of handling collection, integration, preprocessing, selection, transformation, reweighing, augmentation, reprogramming, repairs, and retrieval. Through these capabilities, DataAgents transform complex and unstructured data into coherent and actionable knowledge. We first examine why the convergence of agentic AI and data-to-knowledge systems has emerged as a critical trend. We then define the concept of DataAgents and discuss their architectural design, training strategies, as well as the new skills and capabilities they enable. Finally, we call for concerted efforts to advance action workflow optimization, establish open datasets and benchmark ecosystems, safeguard privacy, balance efficiency with scalability, and develop trustworthy DataAgent guardrails to prevent malicious actions. 1. Introduction As data become increasingly essential to AI, it has reshaped many data-driven tasks and applications like data collection, preprocessing, integration, feature engineering, data augmentation, equation extraction, text to SQL, data question answering, data retrieval, machine learning. For instance, feature engineering can leverage selection, transformation, and generation to create a new augmented feature set as data representation space, in order to develop discriminative data patterns for comparative machine learning. Despite the growing importance of quantity data in prediction and decision making, many of daily data-driven tasks remain repetitive, labor-intensive, and time-consuming (Figure 1). For example, when preparing data for analysis, users often need to repeatedly conduct data cleaning (e.g., handle missing values, addressing outliers, remove duplicate records, correcting inconsistent data entries and data types), data transformation (e.g., standardization, normalization, discretizations, One-Hot encoding, label encoding), feature engineering (e.g., selection, transformation, generation). To perform these data tasks, one of the most promising approaches is to develop autonomous data agents (DataAgents) that equip data with the ability to take task description as inputs, understand tasks, decompose and plan tasks, reason actions, ground actions, execute actions to operate data, so that data can think, speak, and act. DataAgents can reason, plan, ground, execute continuously without fatigue or loss of accuracy to extract knowledge from not just structure data, but also hybrid, multi-modal, semi-structure data, enhance analytical throughput, and accelerate knowledge discovery and decision-making. <details> <summary>2509.18710v2/x1.png Details</summary>  ### Visual Description # Technical Document Extraction: Arizona Retail Sales Analysis ## Diagram Overview The image presents a comparative analysis of two approaches to sales trend analysis: manual SQL processing vs. data agent automation. The diagram is divided into three primary sections: 1. Header (Manual Approach) 2. Main Chart (Process Comparison) 3. Footer (Data Agent Workflow) ## Header Section: Manual Approach ### Chart: Arizona Retail Sales Trends - **Chart Type**: Line Graph - **Legend**: Top Right - Electronics: Orange - Clothing: Blue - Grocery: Green - **Axes**: - X-axis: Years (1990, 2000, 2020) - Y-axis: Sales ($) - **Data Series**: 1. Electronics (Orange) - 1990: $10M - 2000: $18M - 2020: $25M - *Trend*: Steady upward trajectory 2. Clothing (Blue) - 1990: $5M - 2000: $12M - 2020: $15M - *Trend*: Gradual increase with plateau 3. Grocery (Green) - 1990: $3M - 2000: $7M - 2020: $10M - *Trend*: Consistent linear growth ### Text Elements - **Manual SQL Query**: ```sql SELECT DATE_TRUNC('month', Date) AS month, SUM(Sales) FROM retail_sales WHERE Region = 'Arizona' GROUP BY month ``` - **Data Processing Tools**: Pandas / Excel / Matplotlib - **Output**: Visualized report showing Arizona retail sales trends ## Main Chart: Process Comparison ### Diagram Components 1. **Left Side: Without Data Agent** - **Manual SQL Design** - **Data Processing & Visualization** - **Output**: Static visualization 2. **Right Side: With Data Agent** - **Perception Phase**: - Intent: Analyze sales trends - Region: Arizona - Output: Visualized report - **Planning & Decomposition**: - Subtasks: 1. Identify Data Source 2. Generate SQL 3. Execute SQL 4. Verify Results 5. Visualization 6. Summarize Findings ## Footer Section: Data Agent Workflow ### Data Source Table | Date | Region | Product | Sales ($) | |------------|----------|-----------|-----------| | 2021-01-15 | Arizona | Electronics | 9,230 | | 2021-01-18 | Arizona | Clothing | 5,600 | | 2021-03-20 | Utah | Grocery | 8,200 | ### SQL Execution Output | Date | Region | Product | Sales ($) | |------------|----------|-----------|-----------| | 2021-01-15 | Arizona | Electronics | 9,230 | | 2021-01-18 | Arizona | Clothing | 5,600 | | 2021-03-06 | Arizona | Food | 8,900 | ### Verification Process - **Result Verification**: - ✅ Correct - ❌ Need Refinement ### Final Output - **Visualization**: Line graph showing Arizona retail sales trends - **Summary**: > "Arizona retail sales decreased in Feb 2021 but rebounded strongly in March, ending the quarter with a 12% growth compared to January." ## Spatial Grounding - **Legend Position**: Top Right (Both Charts) - **Color Consistency**: - Orange = Electronics (Confirmed in both charts) - Blue = Clothing (Confirmed in both charts) - Green = Grocery (Confirmed in both charts) ## Trend Verification 1. **Manual Approach Chart**: - Electronics: +150% growth (1990-2020) - Clothing: +200% growth (1990-2020) - Grocery: +233% growth (1990-2020) 2. **Data Agent Output**: - Electronics: $9,230 (Jan 2021) - Clothing: $5,600 (Jan 2021) - Food: $8,900 (Mar 2021) - *Quarterly Growth*: +12% (Jan-Mar 2021) ## Component Isolation 1. **Header Region**: - Focus: Static visualization of historical trends - Tools: Manual SQL + Matplotlib 2. **Main Chart Region**: - Focus: Process comparison - Key Difference: Automation vs Manual 3. **Footer Region**: - Focus: Data agent workflow - Emphasis: Structured sub-tasks and verification ## Language Analysis - **Primary Language**: English - **Secondary Language**: None detected ## Critical Data Points 1. **Sales Figures**: - Electronics: $9,230 (Jan 2021) - Clothing: $5,600 (Jan 2021) - Grocery: $8,200 (Mar 2021) 2. **Temporal Data**: - Query Date Range: Jan 15 - Mar 20, 2021 - Reporting Period: Q1 2021 3. **Performance Metrics**: - 12% quarterly growth (Jan-Mar 2021) - 25% Electronics sales increase (Feb-Mar 2021) ## Process Flow Analysis 1. **Manual Approach**: - Linear workflow: SQL → Visualization - No intermediate verification steps 2. **Data Agent Approach**: - Cyclical process with verification checkpoints - Includes data validation phase ## Technical Implications - **Manual Method Limitations**: - Time-consuming SQL construction - No automated verification - Static output format - **Data Agent Advantages**: - Structured decomposition - Automated SQL generation - Dynamic visualization - Built-in quality checks ## Conclusion The diagram demonstrates a 40% reduction in processing steps when using data agents, with improved accuracy through automated verification. The Arizona retail data shows consistent growth across all product categories, with Electronics leading in absolute sales volume. </details> Figure 1. Data tasking without v.s. with DataAgents. Conventional data-related tasks, such as, data collection, integration, preprocess, engineering, retrieval, and analysis, have relied heavily on manual efforts and existing tools, thus, require practitioners to construct SQL queries, write complex data handling scripts, and interpret intermediate outputs. Although human expertise is effective, this manual or semi-manual process is time-consuming, error-prone, and difficult to scale. Recently, advances in reinforcement learning have enabled partial automation of these tasks (Fan et al., 2020, 2021; Wang et al., 2023; Xiao et al., 2023a; Wang et al., 2022). For instance, reinforcement intelligence can learn optimal strategies for querying, transforming, and analyzing data under a targeted task (Müller et al., 2022; Abdelaal et al., 2024). More recently, generative AI and large language models (LLMs) have demonstrated their broad world knowledge, structured data understanding, and instruction-following proficiency (Gong et al., 2025b, c, d; Abhyankar et al., 2025; Hollmann et al., 2023; Ko et al., 2025; Liu et al., 2024; Nguyen et al., 2024). This exhibits a strong potential to perform complex data tasks based on user instructions. For instance, the study in (Ying et al., 2024a) regards feature selection operations as tokens, and formulate feature selection, originally a discrete search task, into a generative learning task with continuous optimization in embedding space under an encoding-optimization-decoding framework. Unlike traditional solutions that require manual coding or empirical experiences, the emergence of agentic AI offers a promising new direction: by combining data with LLM reasoning, planning, tool usage, reflection, DataAgents can be instructed by a task description to independently retrieve datasets, clean records, generate SQL queries, analyze results, and present summaries without minimum user intervention (Kojima et al., 2022; Schick et al., 2023; Peng et al., 2023). Figure 1 shows that users can simply issue a natural language instruction, such as “Analyze the sales trends of Arizona retail data from Q1 2021 and generate a summary report with visualizations.” The DataAgent can then locate the relevant dataset, perform necessary preprocessing, run appropriate analyses, generate plots, and output a comprehensive report. In this way, we automate the entire analytic pipeline and improving workflow efficiency. In parallel, WebAgents (Ning et al., 2025) automate web-related tasks, but there is increasing interest in transferring the WebAgent concept to data to automate data-related tasks for better data knowledgization. To bridge this gap, we provide a comprehensive overview of DataAgents by summarizing representative methods from the perspectives of architecture, training, applications, and challenges. Specifically, we first introduce the background knowledge of traditional agents and the fundamental pipeline of DataAgents. We then review the data perception, task planning, action space, action reasoning, memory management, action grounding, and action execution of data agents. We summarize two crucial aspects (i.e., training data and training strategies) in DataAgents training. Finally, we discuss promising future research directions in DataAgents. 2. Background of Autonomous Data Agents Data-related Tasks. Data-driven applications rely on diverse data tasks, including data collection, engineering, retrieval, analysis, and visualization. Specifically, data engineering involves data cleaning, data preprocessing, feature extraction, feature selection, feature transformation, feature generation. Data retrieval focuses on identifying and extracting relevant information from databases, APIs, and other storage systems, thus, require complex query formulation and schema understanding. Data analysis includes exploratory data analysis, predictive modeling, and visualization. These tasks are labor-intensive and require domain-specific skills and tools. The Need and Feasibility of Automating Data Tasks. The data tasks, like data selection, transformation, generation, retrieval, prediction, summary, QA, visualization, are repetitive and time-consuming. For instance, analysts often rewrite similar SQL queries across projects, manually clean and reconcile messy datasets, or repeatedly configure dashboards for recurring reports. Automating data tasks can improve data quality, make data AI-ready, reduce human effort, increase data usability, and accelerate time-to-insight. Like self-driving vehicles learn to perceive and act in physical environments, many data tasks share the logical procedural structure of data workflows, thus, people can code and execute the logical procedures for repetitive uses. Reinforcement Learning and Generative AI for Automating Data Engineering, Retrieval, and Analysis To enable automation, recent efforts have explored reinforcement learning and generative AI for data tasks. Many data tasks can be framed as a decision process. Reinforcement learning can learn optimal policies for selecting features, transforming data, making decisions to perform feature crossing, or composing data pipelines, by interacting with the environment and receiving feedback. As one example, reinforcement agents have been trained to optimize query plans (Xiong et al., 2024; Tzoumas et al., 2008; Heitz and Stockinger, 2019), detect anomalies (Arshad et al., 2022; Müller et al., 2022), and automate data cleaning steps (Abdelaal et al., 2024; Peng et al., 2024). As another example, researchers have formulated self optimizing feature selection, transformation, and generation as decision sequences generated by reinforcement policy networks (Liu et al., 2021a; Fan et al., 2020, 2021; Liu et al., 2019, 2021b; He et al., 2025; Liu et al., 2021b; Wang et al., 2022). In parallel, many data tasks can be seen as a sequence of data operations or actions, for instance, $f_{1}*f_{2},f_{1}/f_{2},f_{2}/f_{3},\sqrt{f4}$ as a generated token sequence. These operations can be seen as natural language or a sequence of special tokens. Generative AI models have demonstrated strong abilities in learning patterns from natural languages and generate token responses. Similarly, generative AI models can be trained to learn from these data operations and corresponding performance scores from verifiers, to generate what actions we should take (executable python code, SQL queries, or direct operations) to complete data tasks to maximize data operations utilities. For instance, researchers have developed generative feature selection (Gong et al., 2025d; Ying et al., 2024a; Xiao et al., 2023b; Gong et al., 2025d), generative feature transformation and generation (Wang et al., 2023; Xiao et al., 2023a; Ying et al., 2023, 2024b), generative data programming (Bai et al., 2025). However, these generative models directly generate final answers at one step, thus, ignoring the power of many existing tools for data selection, transformation, and augmentation. Besides, there is no reasoning across intermediate steps to identify the high-confidence candidate solutions. For complex data tasks, generative models either require a huge depth of neural networks, or fail to generate valid and effective data operations. LLMs for Data Tasks. Recently, LLMs transforms this landscape. LLMs exhibit advanced reasoning and language comprehension, and can interact and adapt to external environments and verifier feedback. Researchers have generalized LLMs to translate ambiguous instructions from humans into concrete data operations and integrate with data tools to address feature selection (Gong et al., 2025a), feature transformation (Gong et al., 2025c), feature engineering (Abhyankar et al., 2025; Ko et al., 2025; Hollmann et al., 2023), data generation (Hsieh et al., 2025), texts to SQL and data retrieval (Liu et al., 2024), tabular data QA (Zhu et al., 2024c, a; Nguyen et al., 2024), data labeling (Wang et al., 2024a, a; Lu et al., 2025; Zhang et al., 2025), data cleaning (Biester et al., 2024; Li et al., 2024; Naeem et al., 2024; Zhang et al., 2024a), data preprocessing (Zhang et al., 2023a; Meguellati et al., 2025). LLMs can reason and generate texts given a query in a reactive fashion via single-turn interactions, however, LLMs are not goal-driven systems in an autonomous fashion, and, thus, cannot plan, decompose, reason, and act to accomplish tasks. 3. Framing Autonomous Data Agents DataAgents are a new class of autonomous tasking systems (i.e., LLM + planner + reasoning + tools, instead of just a generative model) designed to interact with data as active problem-solvers rather than passive tools. Different from LLMs (e.g., GPT model + prompt), DataAgents integrate LLMs’ language understanding, along with task planning and decomposition, action reasoning, tool calling, action grounding and execution capabilities (Schick et al., 2023; Longpre et al., 2023; Peng et al., 2023; Wang et al., 2024b). DataAgents can understand the high-level intent from the description of a data task (i.e., a query), decompose the task into multiple subtasks, reason action sequences for each subtask, execute data workflows, interact with external environments, reflect and adapt to changes. For instance, when given an instruction such as, “Identify trends in patient admissions and suggest resource allocation for next month,” a DataAgent can access hospital records, clean and structure the data, run time-series analyses, and generate a set of actionable recommendations without human inputs. Formally, given the data (e.g., a table) and a user instruction (e.g., “Identify trends in patient admissions and suggest resource allocation for next month”), DataAgents will generate a sequence of executable actions “ $A=\{a_{1},a_{2},a_{3},...a_{n}\}$ ” and interact with the environment based on these actions to complete the user-instructed data task. Specifically, at the step $t$ , DataAgents first observe the current environmental information (e.g., schema, features, instances, size and shape, data distribution) $s_{t}$ from the data, and retrieve the previous actions $(a_{1},a_{2},...,a_{t-1})$ as the short-term memory to guide the next-action prediction. After that, the user instruction $q$ , observations $s_{t}$ , and previous actions $(a_{1},a_{2},...,a_{t-1})$ , are combined as the in-context knowledge to generate the next action $a_{t}$ : $$ a_{t}=f(q,s_{t},(a_{1},a_{2},...,a_{t-1})) $$ where $f$ is an LLM based data agent. Finally, DataAgents will interact with and operate the data environment based on the generated operation $a_{t}$ . The state of the data will be updated to $s_{t+1}$ after executing the generated action, defined as: $$ s_{t+1}=S(a|t) $$ DataAgents will iteratively repeat the aforementioned steps until the user-given data task is completed. Illustrative Example. Unlike LLMs that only provide static responses, DataAgents operate through a closed-loop pipeline that integrates perception, planning, reasoning, execution, and refinement. Consider the hospital management task: “Predict ICU bed demand for next month and suggest resource allocation.” A vanilla LLM may only output general statements such as “admissions may increase in winter,” but it cannot directly perceive database schemas, decompose the task, or run executable analyses. In contrast, a DataAgent first perceives the structure and distribution of admission data, then plans and decomposes the task into subtasks (data cleaning, forecasting, attribution). Next, it reasons about the action sequence, grounds each action into executable queries or API calls, and executes them on the hospital data system. Finally, it performs refinement by incorporating feedback from intermediate results to adjust the workflow and improve accuracy. This step-by-step autonomy demonstrates why DataAgents are necessary: they enable adaptive, end-to-end problem solving in real data environments, which cannot be achieved by prompting an LLM alone. 4. DataAgents Architecture Figure 2 shows the important components of designing DataAgents for autonomous data tasking: 1) Perception: requires DataAgents to observe and quantify the current data task environment (e.g., data task description, targeted data). 2) Planning & Decomposition: requires DataAgents to understand and analyze an user-given task descriptions based on the current environment, decompose the data task into a logical structure of subtasks (e.g., sequential, parallel, selection), and reason corresponding actions to solve each subtask. 3) Grounding & Execution: requires DataAgents to translate actions into summaries, code, or tool calling, execute the generated actions, and interact with the environment. In the following, we will review the important techniques employed by DataAgents in these steps. <details> <summary>2509.18710v2/x2.png Details</summary>  ### Visual Description # Technical Document Extraction: Autonomous Data Agent System ## Data Sources - **Database**: SQL, NoSQL - **APIs**: Web, Services - **Files**: CSV, JSON, etc. ## Data Tasks - Feature Engineering - Symbolic Equation Extraction - Text2SQL - Tabular QA - Automated Data Repairs - [Additional tasks represented by icons] ## Autonomous Data Agent Core ### Core Components 1. **Perception** - Understand data - Input: Data sources (Database, APIs, Files) 2. **Planning + Decomposition** - Break tasks into subtasks - Input: Perception output 3. **Action Reasoning** - Decide action sequence - Input: Planning + Decomposition output 4. **Grounding** - Abstract action to Code/Natural Language/Calling APIs - Input: Action Reasoning output 5. **Execution** - Run queries/code - Input: Grounding output 6. **Memory** - Long/short-term storage - Input: Refinement output 7. **Refinement** - Feedback/reflection - Input: Execution output - Output: Memory and Perception (dashed feedback loop) ### Output - **Results** - Visualized output (chart icon) - Input: Refinement output ## Flow Diagram - **Directional Flow**: `Perception → Planning + Decomposition → (Grounding | Action Reasoning) → Execution → Refinement → Memory → Perception` - **Feedback Loop**: `Refinement → Results` (dashed arrow) ## Key Observations 1. **Modular Architecture**: Components operate in a cyclical workflow with feedback mechanisms. 2. **Task Decomposition**: Emphasis on breaking complex tasks into manageable subtasks. 3. **Integration Points**: - APIs and Files feed into Perception - Execution connects to both Grounding and Refinement - Memory serves as persistent storage across cycles ## Diagram Elements - **Color Coding**: - Blue boxes: Core components (Perception, Planning, etc.) - Orange box: Memory (long/short-term) - Gray box: Results output - **Arrows**: - Solid lines: Primary workflow - Dashed lines: Feedback/refinement loops ## Technical Terminology - **APIs**: Application Programming Interfaces - **NoSQL**: Non-relational database systems - **Text2SQL**: Natural language to SQL query conversion - **Tabular QA**: Question answering over tabular data </details> Figure 2. Framework of Data Agents 4.1. Perception: Representing Task Descriptions and Data Contexts DataAgents operating within complex data (e.g., tables, time series, sequences, graphs and networks, spatial data, events, texts, images, videos, audio) should perceive accurate data environment, understand task description, and perform task decomposition and reasoning based on data environments combined with the given task. When given a task description and target data, DataAgents need to (i) analyze the structure (e.g., schema), content (e.g., value distributions), and context (e.g., time range, units, domain) of the dataset, (ii) extract tasking intents, constraints, and expectations from the natural language prompt of task descriptions (Shojaee et al., 2024). For example, when given a prompt like “clean this hospital admission data for trend analysis,” DataAgents must infer and understand that the missing values in timestamps should be imputed, the categorical variables like diagnosis codes need normalization, and temporal patterns require sorting or aggregation. These inferences need the agent’s ability to link task description with concrete data structures and operations. A task (prompt) is usually described in texts, while target data can be in different modalities, thus, we can propose different types of DataAgents: Data as tokens: LLMs excel in handling natural language, thus DataAgents usually leverage the textual representation of target data (e.g., table as texts, time series as texts, sequences as texts) to perceive the data environment. Data as tokens and visualization: VLMs have enhanced agents in processing images and videos. To leverage the visual understanding capabilities of VLMs, we can integrate VLMs into DataAgents to utilize not just tokens but also visualizations to perceive the data patterns and environment. Data as multi-modal semi-structure information box: We propose to use a JSON structure to unify the representation of multi-modalities. Listing 1 shows that a JSON format not just store structured data like tables, time series, sequences, graphs, but also include unstructured data like natural languages, code in the plain text blocks, as well as store images using URLs. Listing 1: Any Data as JASON ⬇ 1 { 2 " title ": " Albert Einstein ", 3 " infobox ": { 4 " Born ": " 1 4 March 1 8 7 9 ", 5 " Died ": " 1 8 April 1 9 5 5 ", 6 " Fields ": [" Theoretical physics "], 7 " Known for ": [" Theory of relativity ", " Photoelectric effect "] 8 }, 9 " text ": " Albert Einstein was a German - born theoretical physicist...", 10 " images ": [ 11 { 12 " url ": " https: // upload. wikimedia. org / example. jpg ", 13 " caption ": " Einstein in 1 9 2 1 " 14 } 15 ] 16}} 4.2. Task Planning and Decomposition: from Data Task to Multiple Subtasks Task planning and decomposition involves dividing a high-level data task or query into multiple smaller, logical subtasks that are more manageable and executable. This decomposition enables agents to handle complex data workflows by breaking down them into multiple steps, such as, data retrieval, cleaning, analysis, visualization, and validation. In this way, we allow for iterative execution, error handling, and integration with tools including databases or APIs. For instance, a task like ”analyze sales data for trends” might be decomposed into multiple subtasks: i) query database for raw data, ii) preprocess outliers, iii) apply statistical models, iv) generate visualizations, and v) interpret results. Solutions for task decomposition in LLM-based agents typically leverage prompting techniques, search methods, and hierarchical structures to break down tasks into subtasks. Specifically, there are three solutions: 1) CoT Prompting Based Task Decomposition prompts the LLM to generate step-by-step reasoning traces. It decomposes tasks into sequential subtasks through natural language chains. This approach enhances logical breakdown for data analysis and also reduces errors in multi-step processes. 2) Recursive Task Decomposition, where the agent recursively breaks down task and subtasks into finer-grained ones until they are atomic and executable, often using programmatic or LLM-driven recursion, ideal for handling nested data queries or complex hierarchies. 3) Tree-based Search Task Decomposition, which explores a tree of possible decompositions via branching thoughts or actions, selecting optimal subtask paths through search algorithms like Monte Carlo Tree Search, effective for exploratory data tasks with multiple pathways. Table 1 show that, given a task: “From our e-commerce data warehouse, produce a weekly revenue trend for the past quarter, segmented by product category, and flag anomalies where weekly revenue drops by more than 20% compared to the prior week.”, DataAgents need to 1) parse textual task description (inputs) and ouput structured task specifications (goal, inputs, outputs, and constraints); 2) load columns, types, and relationships; 4) select relevant time range and fields via SQL; 5) join and enrich transactions with product categories; 6) aggregate weekly revenue; 7) detect anomalies — compare weekly revenue vs. prior week; 8) generate report — table + chart + anomaly highlights. Table 1. Decomposing A Task into Subtasks | Subtask | Input | Output | Dependency | | --- | --- | --- | --- | | Parse Task | Natural language task description. | Structured specs: goal, inputs, outputs, constraints. | None | | Load Schema | E-commerce database connection. | Schema: columns, types, relationships. | Parsed specs | | Plan Query | Schema, time range, fields. | SQL query plan. | Schema | | Select Data | Query plan. | Raw data: date, revenue, product_id, category. | Query plan | | Join Data | Raw data. | Enriched dataset with categories. | Selected data | | Aggregate Revenue | Enriched dataset. | Weekly revenue by category. | Joined data | | Detect Anomalies | Weekly revenue data. | Flagged ¿20% drops. | Aggregated data | | Generate Report | Data with anomalies. | Table, chart, anomaly highlights. | Anomalies | Task decomposition methods can be improved from the three aspects: 1) decomposition strategies: creating recursive, adaptive methods that allow agents to decompose tasks on-the-fly to generate task graphs or trees for complex, multi-hop queries while incorporating feedback loops for refinement in uncertain data scenarios; 2) cost efficiency: exploring ensembles of fine-tuned, smaller models for decomposition to reduce computational costs and improve affordability, particularly for data-intensive tasks, while maintaining performance comparable to larger LLMs. 3) safety: understanding how decomposition can bypass safety guardrails in LLMs and developing aligned methods that ensure decomposed subtasks remain safe, verifiable, and resistant to misuse in sensitive data applications. 4.3. Action Reasoning: from Subtask to Action Sequence 4.3.1. Action Space The actions of DataAgents are three fold: tool calling (e.g., invoke APIs, database engine, python data preprocessing tools, python feature engineering libs), symbolic expressions (e.g., produce structured formal queries, code, or transformation specs), direct generation (e.g., output natural language summaries, insights, or computations in-model). This action space serves as the set of all possible “moves” the DataAgents can make to fulfill a data task. Tool calling as actions. A tool calling action is defined as the action that the agent prepare valid inputs (e.g., arguments) and invoke an external tool (e.g., pandas, sklearn, or SQL engines) to complete the work and doesn’t directly produce the result itself, but issues commands (Schick et al., 2023). For instance, a data agent can call a database connector to run a SQL query and fetch data, call a data profiling tool (e.g., Pandas Profiling, Great Expectations) for data quality metrics, call a machine learning toolkit (e.g., scikit-learn, TensorFlow) to train or evaluate a model, or call a plotting library (e.g., Matplotlib, Plotly) to generate a chart from query results. Tool calling introduces constraints (e.g., versioning, resource access), so agents must reason about action feasibility and fallback options. Symbolic expressions as actions. A symbolic expression action is defined as when the agent generates formal symbolic declarative representations (e.g., structured formal queries, code, or transformation specs) that are then executed by some systems (Kamienny et al., 2022). One example is to generate SQL for filtering, joining, aggregating, or sampling data: “SELECT customer_id, SUM(sales) FROM orders WHERE order_date ¿= ’2025-01-01’ GROUP BY customer_id;”. Another example is to generate Pandas/PySpark transformation code. We next discuss symbolic expression actions in two essential data tasks: feature selection and generation. Data task 1: feature selection. Feature selection is a common symbolic task where the agent chooses a subset of informative features based on statistical metrics or model-based criteria. Symbolic actions include expressions like $\text{select}(f_{i}\,|\,\text{MI}(f_{i},y)>\theta)$ or $\text{rank}(f_{i},\text{importance})$ . The agent evaluates feature importance using mutual information, correlation coefficients, or model weights (Abhyankar et al., 2025; Hollmann et al., 2023). Data task 2: feature transformation. In feature transformation, agents modify raw features to create discriminative patterns. Symbolic actions include normalization $z=\frac{x-\mu}{\sigma}$ , log scaling $x^{\prime}=\log(x+1)$ , or binning $\text{bin}(x,5)$ . These expressions can be automatically generated and applied based on feature distribution characteristics. Data task 3: feature generation. Feature generation involves constructing new variables by crossing existing ones. Symbolic generation includes interaction terms $f_{1}· f_{2}$ , ratios $\frac{f_{1}}{f_{2}}$ , or non-linear combinations $\sqrt{f_{3}}+\log(f_{4})$ . Agents can learn feature crossing patterns, and generate optimal feature transformations via optimization. Direct generation as actions. When the agent directly produces the end output without intermediate tool invocation — the result is computed, reasoned, or drafted entirely within the LLM or AI runtime (Zhu et al., 2024b). One example is to summarize dataset insights in natural language from already-provided data, like: “Sales in Q1 increased by 15% compared to Q4, mainly driven by product category A.” Another example is responding to analytical questions using only the visible dataset, like: Q: “Which product had the highest sales in March?” A: “Product B with 3,240 units sold.” Generally speaking, simple tasks are executed symbolically, while complex ones leverage external tools. 4.3.2. Guiding Next Action Generation via Memory Management Memory management refers to how DataAgents with LLM as reasoning core keep track of context and past interactions within a high-level task and across subtasks. Memory mechanisms can help data agents to maintain contextual awareness and sequence consistency. There are two types of memories, including short-term and long-term memories, that can enable agents to trace historical actions and anticipate next actions (Sun et al., 2018). (1) Short-term Memory: Recent Actions. Short-term memory is the most recent actions within a single subtask. For example, after encoding a categorical feature, the agent can use short-term memory to avoid re-encoding or applying incompatible feature transformations. Short-term memory is subtask-specific and cleared when task is completed in order to optimize agents for reactive task handling. (2) Long-term Memory: Action Trajectories. Long-term memory is historical action trajectories across tasks. Similar to reinforcement learning, it allows agents to learn the appropriateness of an action for a task type. For instance, if an outlier detection method is effective on financial datasets, long-term memory recommends this method strategy in similar tasks. Memory management can be improved by: 1) memory representation and retrieval optimization to lower retrieval latency while maximizing relevance tp retrieve relevant past interactions or facts; 2) memory selection and forgetting, by developing algorithms to decide what memory should be kept, summarized, or discarded; 3) integration of short-term and long-term memory for coherent multi-turn reasoning. 4.3.3. Action Reasoning. Once a complex task is broken down into logical subtasks (e.g., data querying, analysis, visualization), action reasoning combines planning, search, and reinforcement learning principles, and usually involves iterative cycles of thinking about the subtask, selecting appropriate actions (such as tool calls or code generation), observing outcomes, and refining based on feedback. There are three major categories of action reasoning methods: (1) Reasoning and Acting (ReAct), which interleaves reasoning (generating thoughts about a target subtask) with action execution and observation, in order to create iterative loops to refine sequences until completion. It’s widely used for dynamic subtasks requiring tool integration, like sequential data queries. Recent research has been focused on self-reflection mechanisms (e.g., linguistic feedback) to adjust action sequences based on real-time observations, reducing errors and improving success rates in long-horizon subtasks like data analysis chains. (2) Chain-of-Thought (CoT): By prompting the data agent to build step-by-step reasoning trajectories, CoT formalizes action sequences as logical chains, to enhance performance in symbolic or mathematical subtasks such as data computation. (3) Monte Carlo Tree Search: A lookahead search algorithm that simulates potential action sequences, balancing exploration and exploitation to select optimal paths. It’s ideal for uncertain subtasks, like optimizing data processing paths in complex environments. Action-action dependency is critical. For instance, in a subtask requiring outlier removal and normalization, the agent must reason to remove outliers first to avoid distorting normalization. Such reasoning ensures logical coherence and robustness in data workflows (Wei et al., 2021). 4.4. Action Grounding and Execution 4.4.1. Action Grounding. action grounding refers to the process of mapping an abstract action (derived from task decomposition and reasoning) to concrete, executable operations in the real-world environment or tools. This involves translating an abstract symbolic or generated action into specific, grounded actions like generating SQL queries, calling APIs, executing Python code for data processing, or interacting with databases. The agent must ensure that variable names, data types, and function signatures are all matched to their execution context. Without proper grounding, even a syntactically correct action may fail during runtime. We summarize three types of action grounding strategies: (1) Ground an action to executable code: which involves translating an agent’s action into executable code, typically Python, that is then run in an interpreter to interact with the environment. Today’s LLM can generate code snippets that can include control flows (e.g., loops, conditionals), data manipulation, and tool integrations. For instance, the CodeAct consolidates agent actions into executable code (e.g., Python) as a unified space, enabling grounding of diverse tasks like data analysis by generating and running code snippets, with built-in error handling and observation. (2) Ground an action to structured tool invocations: which invokes predefined tools or APIs through structured formats like JSON-based tool calling. The LLM outputs a specific call (e.g., tool name and arguments), which is parsed and executed externally. (3) Ground an action to direct natural language generation, which grounds actions directly in natural language outputs generated by the LLM, without external execution or tools. The agent produces text responses, explanations, or decisions as the ”action,” often for user interaction or simple reasoning tasks. For instance, LLM-Planner (Song et al., 2023), is a few-shot grounding approach that leverages LLMs to generate executable plans and actions from natural language, focusing on embodied or data tasks with minimal examples for efficient execution. 4.4.2. Action Execution. Execution entails the actual invocation of these actions, observation of outcomes (e.g., query results or errors), and iterative refinement or error handling to complete subtasks. This phase often incorporates feedback loops, such as reflection on results or replanning, to adapt to dynamic data environments and mitigate issues like hallucinations or invalid operations. For instance, after decomposing a task into subtasks like ”retrieve data” and ”compute statistics,” grounding might convert ”retrieve data” to a precise database API call, and execution would run it, process the output, and pass it to the next subtask. Table 2. Data sources and training instances for multi-skill data AI agents | Task | Data Sources | Example Training Instance (Instruction $→$ Input $→$ Output) | | --- | --- | --- | | Data Preprocessing | Public noisy datasets (Kaggle, UCI), open-source cleaning scripts | “Remove rows with missing age” $→$ Raw CSV $→$ Cleaned CSV + code snippet | | Feature Engineering | Kaggle notebooks, FEAST tutorials, synthetic tabular data | “Create an indicator if income $>$ 50K” $→$ Table $→$ New table + feature code | | Data Augmentation | NLP: backtranslation corpora; CV: Albumentations scripts; Tabular: SMOTE datasets | “Add Gaussian noise to the ‘price’ column” $→$ Table $→$ Augmented table + code | | Data Visualization | Matplotlib/Plotly examples, ChartQA datasets | “Plot sales over time” $→$ Table $→$ Chart image + plotting code | | Text-to-SQL | Spider, WikiSQL, real SQL logs with schema | “List average salary by department” $→$ Schema $→$ SQL query | | Data-to-Equation | Symbolic regression benchmarks (SRBench), physics datasets | “Fit a linear model for $y$ vs. $x$ ” $→$ CSV $→$ Equation + coefficients | | Tool Calling | Logs from Jupyter, SQL IDEs, BI dashboards, CLI usage | “Summarize column ‘revenue’ statistics” $→$ Table $→$ Tool call JSON + expected output | 5. DataAgents Training 5.1. Preliminaries of Instruction Tuning As a type of Supervised FineTuning (SFT), instruction tuning aims to align pre-trained LLMs with diverse data operation tasks by conditioning them on task instructions (Peng et al., 2023; Longpre et al., 2023). The idea is to teach LLMs to be prompted by natural language inputs and generate structured multi-step action sequences or executable operations for tasking. This process involves adjusting the model’s internal parameters to better align its behavior with the given instructions. Instruction tuning can train agents with basic capabilities for understanding instructions, decomposing tasks, and producing preliminary action sequences. However, to achieve reliable multi-step planning, tool usage, and environment-adaptive execution, reinforcement-based fine-tuning (RFT) is necessary to further enhance the reasoning and operational capabilities of the agents. 5.2. Preparing Training Data for Skills and Action Reasoning To train DataAgents with diverse skills (e.g., data preprocessing, feature engineering, data augmentation, data visualization, text-to-SQL translation, data-to-equation mapping), it is essential to construct a multi-task, instruction-oriented dataset grounded in real-world workflows. Table 2 shows that the training dataset should adopt an instruction–input–output format, in order to allow agents to learn from natural language commands and corresponding execution traces. Skill 1: Data Preprocessing Training Data. For data preprocessing, training samples can be derived from public datasets from Kaggle or the UCI Machine Learning Repository containing noise, missing values, duplicates, or heterogeneous formats, paired with human-curated cleaning results and executable code snippets. Skill 2: Feature Engineering Training Data. Feature engineering examples may be sourced from open repositories, competition notebooks, and synthetic datasets, along with code covering feature creation, transformation, and selection. Skill 3: Data Augmentation Training Data. Data augmentation samples should span textual (e.g., back translation, synonym replacement), visual (e.g., geometric or color-space transformations), and tabular (e.g., SMOTE, noise injection) modalities. Skill 4: Data Visualization Training Data. For data visualization, examples can be obtained from public plotting libraries and annotated chart-generation tasks, linking raw data to generated visualizations and their underlying code. Skill 5: Text2SQL Training Data. Text-to-SQL training data can be drawn from established benchmarks such as Spider and WikiSQL, as well as domain-specific SQL query logs, each paired with schema definitions and validated queries. Skill 6: Data2Equation Training Data. Data-to-equation examples can be generated from physics, engineering, and regression datasets with known analytical forms, or sourced from symbolic regression benchmarks, for instance, SRBench. Skill 7: Tool Calling Training Samples. Tool calling examples (Listing 2) should pair natural language requests with tool metadata, parameterized invocation formats, and corresponding execution results. Such datasets can be sourced from instrumented Jupyter notebooks, business intelligence platforms, or query-generation interfaces, where both the intermediate tool calls and final outputs are logged. Listing 2: Example of a tool calling training instance ⬇ 1 Instruction: " Draw a histogram of the ’ age ’ column." 2 Input: CSV schema: name, age, salary 3 Tool Call: { 4 " tool ": " matplotlib. hist ", 5 " args ": { 6 " data ": " age ", 7 " bins ": 1 0 8 } 9} 10 Output: < image file or base64 - encoded chart > To ensure broad generalization, data collection should combine multiple strategies: mining open-source code repositories and competition platforms for high-quality task–solution pairs; generating synthetic datasets with controlled transformations to establish precise ground truth; crowdsourcing expert annotations for complex or ambiguous tasks; and logging human–tool interactions in authentic analytical workflows. 5.3. Preparing Training Data for Task Decomposition Collecting training data for task decomposition requires curating multi-stage examples in which a complex data analysis request is broken down into a logical sequence of heterogeneous subtasks such as data preprocessing, feature engineering, data augmentation, data visualization, text-to-SQL translation, data-to-equation mapping, and tool calling. Each training instance should pair the original high-level instruction with an explicit decomposition plan specifying the ordered plan of subtasks, the descriptions of each subtask, their dependencies, and the corresponding inputs and outputs, enabling the agent to learn both structural reasoning and skill invocation. Listing 3 shows an example task decomposition from a task description to multiple subtasks to actions. Such data can be sourced from annotated Jupyter notebooks, BI dashboards, competition notebooks, and open-source repositories that explicitly document intermediate steps, inputs, and outputs for each stage. Listing 3: An example of task decomposition ⬇ 1 { 2 " complex_instruction ": " Analyze customer purchase data to find seasonal trends and forecast next quarter ’ s sales.", 3 " plan ": [ 4 { 5 " step ": 1, 6 " skill ": " preprocessing ", 7 " instruction ": " Remove duplicates and standardize date formats.", 8 " input ": " raw_transactions. csv (columns: id, date, amount, category)", 9 " output ": " clean_transactions. csv; Python code used; artifact hash " 10 }, 11 { 12 " step ": 2, 13 " skill ": " feature_engineering ", 14 " instruction ": " Create month, year, and holiday flag features.", 15 " input ": " clean_transactions. csv ", 16 " output ": " features. csv; code snippet; preview head " 17 }, 18 { 19 " step ": 3, 20 " skill ": " augmentation ", 21 " instruction ": " Synthesize data for missing holiday periods.", 22 " input ": " features. csv ", 23 " output ": " augmented_features. csv; generation parameters " 24 }, 25 { 26 " step ": 4, 27 " skill ": " visualization ", 28 " instruction ": " Plot monthly sales trends for the last 3 years.", 29 " input ": " aggregated table: month, sales ", 30 " output ": " matplotlib code; rendered chart (image ref)" 31 }, 32 { 33 " step ": 5, 34 " skill ": " text_to_sql ", 35 " instruction ": " Aggregate sales by month and category from the database.", 36 " input ": " schema: sales (order_id, date, amount, category)", 37 " output ": " SQL query; execution result snippet " 38 }, 39 { 40 " step ": 6, 41 " skill ": " data_to_equation ", 42 " instruction ": " Fit a seasonal model to forecast next quarter.", 43 " input ": " monthly sales time series ", 44 " output ": " equation form + coefficients; R ^ 2 / MAE " 45 }, 46 { 47 " step ": 7, 48 " skill ": " tool_call ", 49 " instruction ": " Export forecast results to CSV.", 50 " input ": " forecasted series ", 51 " output ": { 52 " tool ": " file. export_csv ", 53 " args ": {" path ": " forecast_q_next. csv ", " data ": " forecast_table "} 54 } 55 } 56 ] 57} <details> <summary>2509.18710v2/x3.png Details</summary>  ### Visual Description # Technical Document Extraction ## Data Table Analysis ### Table Structure | Date | Region | Product | Sales ($) | |------------|---------|-----------|-----------| | 2021-01-15 | Arizona | Electronics | 9,230 | | 2021-01-18 | Arizona | Clothing | 5,600 | | ... | ... | ... | ... | | 2021-03-20 | Utah | Grocery | 8,200 | ### Key Observations 1. **Temporal Coverage**: Data spans Q1 2021 (Jan 15 to Mar 20) 2. **Geographic Scope**: Multi-region analysis (Arizona, Utah) 3. **Product Categories**: Electronics, Clothing, Grocery 4. **Sales Variance**: - Electronics ($9,230) > Grocery ($8,200) > Clothing ($5,600) - No clear temporal trend due to sparse data points ## Query Analysis **Original Text**: "Analyze the sales trends of Arizona retail data and generate a summary report with visualizations." **Key Components**: - **Primary Objective**: Sales trend analysis - **Geographic Focus**: Arizona - **Output Requirements**: - Summary report - Visualizations (unspecified type) ## Process Diagram Analysis ### Component Breakdown 1. **Feedback Loop** (Blue Box) - Position: Left side - Function: Iterative input mechanism 2. **Central Processing Unit** (Green Square) - Logo: White interlocking knot design - Function: Core data processing 3. **Refinement Module** (Blue Box) - Position: Right side - Function: Output optimization ### Workflow </details> Figure 3. Single agent design. 5.4. Single Agent Based Design and Instruction Tuning If we aim to train a single DataAgent to decompose, reason, and execute a complex data task, we can adopt a unified supervised instruction tuning approach. Each training instance includes the high-level task description, contextual information (e.g., schema snippets, table samples, constraints), and a complete task-subtask-action–execution trace. The trace begins with a structured plan in JSON format (Listing 3) that details an ordered sequence of subtasks with associated skill types (e.g., preprocessing, feature engineering, data augmentation, data visualization, text-to-SQL, data-to-equation, tool calling) and step-specific instructions. This is followed by a sequence of action blocks, in which the agent produces grounded, executable outputs such as Python code, SQL queries, tool call JSON objects, or equations, and observation blocks containing deterministic execution results (e.g., preview tables, chart hashes, error logs). We can finetune the model end-to-end on these concatenated action traces using next-token cross-entropy loss, optionally with structure-aware loss weighting to improve the syntactic correctness of JSON, SQL, and code outputs. We can collect training data from verified multi-step task decompositions, to ensure that each action–observation pair is executable in a controlled sandbox environment, and include both successful and failure-recovery examples to promote robustness. At inference time, the same model iteratively generates a plan and then executes each step, incorporating tool execution feedback into subsequent actions, thereby enabling closed-loop reasoning and grounded multi-skill execution within a single generative architecture. <details> <summary>2509.18710v2/x4.png Details</summary>  ### Visual Description # Technical Document Extraction ## Data Table | Date | Region | Product | Sales ($) | |------------|----------|-----------|-----------| | 2021-01-15 | Arizona | Electronics | 9,230 | | 2021-01-18 | Arizona | Clothing | 5,600 | | ... | ... | ... | ... | | 2021-03-20 | Utah | Grocery | 8,200 | ### Key Observations: - **Temporal Scope**: Data spans from January 15, 2021, to March 20, 2021. - **Geographic Focus**: Arizona (primary) and Utah (single entry). - **Product Categories**: Electronics, Clothing, Grocery. - **Sales Values**: - Electronics: $9,230 (highest) - Clothing: $5,600 - Grocery: $8,200 ## Query **Text**: "Analyze the sales trends of Arizona retail data and generate a summary report with visualizations." ### Breakdown: - **Objective**: Analyze sales trends. - **Scope**: Arizona retail data. - **Deliverables**: Summary report with visualizations. ## Flowchart Components ### 1. Planner - **Responsibilities**: - Understand requirements. - Decompose tasks. - Sequence steps. - Assign to Actor. - Refine if needed. - **Symbol**: Blue rectangle with white text. ### 2. Actor - **Responsibilities**: - Execute SQL/code. - Process data. - Generate output. - **Symbol**: Blue rectangle with white text. ### 3. Feedback Loop - **Direction**: Actor → Planner. - **Label**: "Feedback." ## Diagram Flow 1. **Planner** initiates task decomposition. 2. **Actor** executes assigned tasks (SQL/code). 3. **Feedback** ensures iterative refinement. ## Spatial Grounding - **Data Table**: Positioned at the top-left of the image. - **Query**: Located in the top-right corner. - **Flowchart**: Occupies the lower half, with directional arrows indicating process flow. ## Trend Verification - **Data Series**: No explicit trends visible in the table (only three entries). The ellipsis suggests additional data points exist but are not shown. - **Hypothesis**: Sales trends may vary by product category and date, but further analysis is required. ## Component Isolation - **Header**: Query text (top-right). - **Main Chart**: Data table (top-left). - **Footer**: Flowchart (bottom half). ## Final Notes - **Language**: All text is in English. - **Missing Elements**: No legends, axis titles, or numerical trends explicitly depicted in the image. - **Assumptions**: The ellipsis in the table implies incomplete data; the flowchart suggests an iterative process between Planner and Actor. </details> Figure 4. Planner-actor dual agent design. 5.5. Planner-Actor Dual Agents Based Design and Instruction Tuning Besides, we can adopt a two-module training paradigm comprising a planner and an actor, supervised on the task decomposition and subtask action datasets respectively. We can train the planner module to map a high-level natural-language instruction to an ordered sequence of subtasks, each annotated with its skill type (e.g., preprocessing, feature engineering, data augmentation, data visualization, text-to-SQL, data-to-equation mapping, tool calling) and a concise sub-instruction. We can train the actor module to condition on a single subtask specification and its associated input context (e.g., table snippet, database schema, chart specification) to produce the corresponding executable output, such as code, SQL, structured tool call JSON, or fitted equations. Both modules are fine-tuned on curated and synthetic multi-skill workflows, with the planner optimized using sequence modeling loss over serialized decomposition plans and the actor optimized using next-token prediction loss over serialized subtask outputs. In this way, we allow the agent to generalize decomposition strategies to novel tasks while maintaining high fidelity in tool-grounded action generation, in order to enable robust end-to-end performance in heterogeneous, multi-step data tasks. Multiple multi-agent paradigms could be applied in data agents (e.g., role-specialized agents, hierarchical controllers, or critic-based supervision). We select the planner–actor design, as it offers conceptual clarity and aligns naturally with data-centric workflows, where task decomposition and reliable execution are the two most critical components. Other multi-agent designs can also be incorporated into the data-agent framework, but we use this paradigm mainly to illustrate the idea clearly. 5.6. Reinforcement Fine-Tuning of DataAgents <details> <summary>2509.18710v2/x5.png Details</summary>  ### Visual Description # Technical Document Extraction: Sales Analysis Diagram ## Diagram Overview The image presents a comparative analysis of two approaches for sales trend analysis: **Single Agent/Actor** and **Planner**. The diagram includes textual queries, responses, and flowcharts illustrating system components and optimization processes. --- ## Single Agent/Actor Section ### Query ``` Analyze the sales trends of Arizona retail data and generate a summary report with visualizations. ``` ### Response (Report) ``` Sales in Arizona increased steadily, with a 50% growth from January (10k) to March (15k). This indicates strong seasonal recovery. ``` ### Data Table | Date | Sales ($) | |------------|-----------| | 2021-01-15 | 9,230 | | ... | ... | | 2021-03-20 | 8,200 | **Note**: The report claims a 50% growth from January (10k) to March (15k), but the data shows a decline from $9,230 to $8,200. This discrepancy suggests either: 1. Data normalization (e.g., 10k = $10,000 baseline) 2. Typographical error in the report 3. Different measurement periods ### Flowchart Components 1. **Reward Model** (Orange) - Inputs: Execution success rates, visualization correctness, SQL query results - Outputs: Reward signal 2. **LM (Active)** (Blue) - Processes: Log-probabilities calculation 3. **LM (Reference)** (Gray) - Processes: Log-probabilities calculation 4. **Reward** (Green) - Calculated via: Log-ratio + KL-divergence 5. **PPO** (Dark Blue) - Final optimization step **Flow**: Reward Model → [LM (Active) & LM (Reference)] → Log-probs → Reward → PPO --- ## Planner Section ### Query ``` Analyze the sales trends of Arizona retail data and generate a summary report with visualizations. ``` ### Response (Subtasks) ``` [ {"step": 1, "skill": "data_retrieval", "sub_instruction": "Load Arizona retail sales data"}, {"step": 4, "skill": "report_generation", "sub_instruction": "Summarize key sales trends in text"} ] ``` ### Flowchart Components 1. **Reward Model** (Orange) - Inputs: Skill type selection, logical ordering consistency - Outputs: Reward signal 2. **LM (Active)** (Blue) - Processes: Log-probabilities calculation 3. **LM (Reference)** (Gray) - Processes: Log-probabilities calculation 4. **Reward** (Green) - Calculated via: Log-ratio + KL-divergence 5. **PPO** (Dark Blue) - Final optimization step **Flow**: Reward Model → [LM (Active) & LM (Reference)] → Log-probs → Reward → PPO **Key Difference**: Explicit handling of subtask dependencies and skill selection logic. --- ## Color Legend & Spatial Grounding - **Orange**: Reward Model - **Green**: Reward - **Blue**: LM (Active) - **Gray**: LM (Reference) - **Pink**: KL-divergence **Legend Position**: Not explicitly shown, but colors are consistently applied across both flowcharts. --- ## Trend Verification 1. **Single Agent Data Trend**: - Visual: Steady increase (per report) - Numerical: $9,230 → $8,200 (decrease) - Conflict: Report claims 50% growth vs. data showing 10.9% decline 2. **Planner Flow**: - Emphasizes logical ordering between subtasks - Introduces KL-divergence for policy optimization --- ## Language Analysis - **Primary Language**: English - **No additional languages** detected in the diagram --- ## Critical Observations 1. Data inconsistency between report narrative and numerical values 2. Both approaches use similar core components (LM, Log-probs, Reward, PPO) 3. Planner adds explicit subtask dependency management 4. Reward calculation methodology differs between sections (Log-ratio + KL-div vs. unspecified) This extraction provides a complete technical specification of the diagram's components, data, and potential inconsistencies for further analysis. </details> Figure 5. Reinforcement finetuning of LLM generative agent RFT Framework. To further improve the DataAgents’ ability to perform accurate task decomposition and coherent action reasoning beyond supervised instruction tuning, we can employ reinforcement fine-tuning (Figure 5). If this is a single agent design, we can exploit a single reinforcement policy as generative agent. If this is a planner-actor dual agent design, we can exploit a hierarchical, two-policy setting with one policy as a task planner and the other policy as an subtask actor. Reward Model. DataAgents generate a decomposition plan and corresponding subtask actions for a given high-level data task, and each output is evaluated using a composite reward function that captures both structural and execution quality. For the planning stage, rewards are assigned based on the correctness and completeness of the subtask sequence, including proper skill type selection, logical ordering, and dependency consistency between subtasks. For the action reasoning stage, the action sequence of a subtask output is executed in a sandboxed environment, and rewards are computed from execution success rates, correctness of final artifacts (e.g., table hashes, chart specifications, SQL query results, equation fit metrics), and adherence to tool schema constraints. Policy Optimization. Reinforcement optimization, implemented via policy gradient methods such as Proximal Policy Optimization (PPO), iteratively updates the model to maximize these rewards, enabling it to refine both the decomposition structure and the reasoning behind action selection. This approach allows the agent to learn from real or simulated execution feedback, improving its robustness, adaptability, and end-to-end success in solving complex, multi-step analytical tasks. 6. A Study of DataAgents 6.1. Primary Workflow Overview. We evaluate a modular DataAgent that executes tabular ML tasks via a stepwise pipeline: (i) cleaning / preprocessing using a small rule-based controller (if–else rules over schema/profiled stats); (ii) routing by a large LLM (e.g., GPT family) from a natural-language dataset card to one of three solution modes: classical linear/sparse model (e.g., Lasso (Tibshirani, 1996)), neural model (RL trained), or LLM-based sequence generator; (iii) planning + tool calling (merged): for classical/neural, it calls a fixed tool chain to shape a better feature set; for LLM mode, it generates a sequence of operations (plan-as-sequence (Yao et al., 2023; Schick et al., 2023)) and calls tools accordingly; (iv) grounding that validates the called tools or the generated operation sequence (schema checks, dry-run, unit tests); (v) execute to produce downstream predictions/plots; (vi) evaluator that performs automatic sanity checks and triggers at most $K$ self-repair rounds (Shinn et al., 2023; Madaan et al., 2023; Gu et al., 2024). (vii) summary from the log of each step and generate a readable report for non-LLM-experts. Figure 6 summarizes the overall workflow. <details> <summary>2509.18710v2/fig/case_workflow.png Details</summary>  ### Visual Description # Technical Document Extraction: Flowchart Analysis ## Diagram Overview The image depicts a **process flowchart** for a data processing system. It illustrates the flow of data through multiple stages, decision points, and outputs. The diagram uses color-coded paths and labeled components to represent the system's architecture. --- ## Key Components and Flow ### 1. **Data Input** - **Component**: `Data` (orange icon) - **Flow**: - Enters the system at the leftmost node. - Connects directly to the `Cleaning` stage. ### 2. **Cleaning Stage** - **Component**: `Cleaning` (black box with checkmark ✅ and cross ❌) - **Function**: - Processes raw data. - Outputs a **Summary** (book icon) and a **Log** (yellow notepad). - **Flow**: - Dashed arrow to `Summary`. - Solid arrow to `Routing`. ### 3. **Routing Stage** - **Component**: `Routing` (blue diamond) - **Function**: - Splits data into two paths: - **Classical Path** (red cube icon). - **LLM Path** (orange polyhedron icon). - **Flow**: - Dashed arrows to both paths. - Converges into `Action` via solid arrows. ### 4. **Decision Paths** #### a. **Classical Path** - **Component**: `Classical` (red cube) - **Flow**: - Directly connects to `Action`. #### b. **LLM Path** - **Component**: `LLM` (orange polyhedron) - **Flow**: - Directly connects to `Action`. ### 5. **Action Stage** - **Component**: `Action` (tower icon) - **Function**: - Processes outputs from both paths. - **Flow**: - Solid arrow to `Grouping`. ### 6. **Grouping Stage** - **Component**: `Grouping` (shield icon with ✅) - **Function**: - Validates or groups processed data. - **Flow**: - Solid arrow to `Executor`. - Dashed arrow to `Log`. ### 7. **Executor Stage** - **Component**: `Executor` (person with hammer icon) - **Function**: - Executes actions based on grouped data. - **Flow**: - Solid arrow to `Evaluator`. - Dashed arrow to `Log`. ### 8. **Evaluator Stage** - **Component**: `Evaluator` (person with lightbulb icon) - **Function**: - Evaluates outcomes. - **Flow**: - Solid arrow to `Log`. --- ## Outputs 1. **Summary**: - Generated from the `Cleaning` stage. - Represented by a book icon. 2. **Logs**: - Produced at every stage (`Cleaning`, `Routing`, `Action`, `Grouping`, `Executor`, `Evaluator`). - Represented by yellow notepads with red lines. 3. **Readable Report**: - Final output derived from the `Summary`. - Represented by a document icon. --- ## Color Coding Legend - **Blue**: Routing stage and classical path. - **Orange**: LLM path. - **Red**: Cross (invalid data) and classical path icon. - **Yellow**: Logs. - **Green**: Checkmark (valid data) and grouping stage. --- ## Spatial Grounding - **X-axis**: Left-to-right progression of data flow. - **Y-axis**: Vertical alignment of components (e.g., `Cleaning` above `Routing`). - **Legend Position**: Implicitly defined by color associations (no explicit legend box). --- ## Notes - **No Numerical Data**: The diagram represents a process flow, not quantitative trends. - **Dashed Arrows**: Indicate auxiliary outputs (e.g., logs). - **Solid Arrows**: Represent primary data flow. --- ## Conclusion This flowchart outlines a multi-stage data processing system with parallel paths (classical vs. LLM), validation checkpoints, and iterative logging. The system emphasizes modularity, with each component handling specific tasks before passing data to the next stage. </details> Figure 6. Overall workflow of the proposed DataAgent, consisting of sequential modules for data cleaning, routing, planning/action, grounding, execution, and evaluation. Why this design. The primary workflow is structured to mirror the evaluation dimensions of our study. Each module corresponds to a potential failure mode in end-to-end data analysis. Routing tests whether LLMs can align their modeling capacity with dataset characteristics. Planning and tool-calling probe the compositional reasoning ability needed to orchestrate operations. Grounding and evaluator explicitly validate and repair intermediate outputs to ensure robustness. The workflow serves as both a pipeline and a testbed, enabling controlled evaluation of each module’s impact. 6.2. Experimental Design: Comparing Paradigms Purpose. Our goal is to use experiments as a lens to understand the strengths and weaknesses of three major paradigms for tabular data engineering: (1) classical and AutoML baselines, (2) pure LLM approaches, and (3) RL-based methods. DataAgent serves as a notable example of emerging modular agent paradigm, showing how agentic design balances reliability, autonomy, and efficiency. Datasets. We include classification tasks from UCIrvine and regression tasks from OpenML, covering both discrete and continuous prediction settings. Evaluation Aspects. We examine four aspects that highlight the trade-offs among paradigms: (i) Predictive quality, measured by 1-RAE for regression and F1-score for classification; (ii) Reliability, measured by task success rate and number of attempts needed; (iii) Automation, reflected in grounding error rates; (iv) Efficiency, measured by time and calls required. 6.3. Observations from Comparative Results Predictive Quality Across Paradigms. Table 3 summarizes results across regression and classification datasets. Classical and AutoML baselines achieve solid but limited performance. Pure LLM approaches show strong results on some datasets, but suffer from instability across tasks. RL-based policies can reach high accuracy, yet often at the expense of extensive training. In contrast, DataAgent, as a modular agent instance, consistently delivers robust accuracy while avoiding training overhead, reflecting the potential of this paradigm for practical deployment in realistic scenarios. Reliability and Automation. Figure 7 compares DataAgent with pure LLM baselines on task performance and error rates. Pure LLMs often require multiple retries to produce an executable solution and exhibit higher grounding error rates. In contrast, DataAgent achieves reliable task completion within a very small attempt budget (only 2 attempts on average), while maintaining the highest performance. This demonstrates how the modular agent design combines the reasoning ability of LLMs with structured grounding, ensuring both higher reliability and stronger automation. Efficiency Trade-offs Table 4 compares only RL-based policies with the modular agent (DataAgent). RL-Policy-1 and RL-Policy-2 incur substantial training costs and require many calls during inference. DataAgent is training-free, reaches valid solutions with only 2 calls, and attains the strongest performance, despite a modest per-run inference latency. This shows that RL-based methods require heavy training, whereas the modular agent avoids training and remains efficient with only light inference overhead. Table 3. Downstream performance comparison on regression and classification datasets. For regression, we report 1-RAE (Relative Absolute Error), and for classification F1-score (%). | Dataset | German Credit | SpectF | OpenML 586 | OpenML 618 | | --- | --- | --- | --- | --- | | Source | UCIrvine (Public, 2023b) | UCIrvine (Public, 2023b) | OpenML (Public, 2023a) | OpenML (Public, 2023a) | | Task | Classification | Classification | Regression | Regression | | Samples | 1,000 | 267 | 1,000 | 1,000 | | Features | 24 | 44 | 25 | 50 | | Original | 74.20% | 76.06% | 0.6311 | 0.4402 | | RDG | 68.01% | 76.03% | 0.5681 | 0.3720 | | LDA (Blei et al., 2003) | 63.91% | 66.29% | 0.1109 | 0.0521 | | ERG | 74.43% | 75.66% | 0.6147 | 0.3561 | | NFS (Chen et al., 2019a) | 68.67% | 79.40% | 0.5443 | 0.3473 | | AFAT (Horn et al., 2020) | 68.32% | 76.03% | 0.5435 | 0.2472 | | PCA (Maćkiewicz and Ratajczak, 1993) | 67.92% | 70.92% | 0.1109 | 0.1016 | | TTG (Khurana et al., 2018) | 64.51% | 76.03% | 0.5443 | 0.3467 | | FeatLLM (Han et al., 2024) | 76.35% | 80.07% | 0.6477 | 0.4597 | | CAAFE (Hollmann et al., 2023) | 59.92% | 70.60% | N/A | N/A | | AutoFeat (Horn et al., 2019) | 74.86% | 76.06% | 0.6329 | 0.4407 | | OpenFE (Zhang et al., 2023b) | 74.50% | 76.06% | 0.6311 | 0.4402 | | ELLM-FT (Gong et al., 2025b) | 76.39% | 86.14% | 0.6328 | 0.4734 | | Pure LLM (Llama 3.1) | 75.43% | 85.19% | 0.7811 | 0.6653 | | RL-Policy-1 (GRFG (Wang et al., 2022)) | 68.29% | 81.65% | 0.5768 | 0.4562 | | RL-Policy-2 (MOAT (Wang et al., 2023)) | 72.44% | 86.95% | 0.6251 | 0.4734 | | DataAgent | 79.60% | 86.79% | 0.7832 | 0.7488 | <details> <summary>2509.18710v2/fig/llm_f1.png Details</summary>  ### Visual Description # Model Performance Comparison ## Chart Description This image presents a **bar chart** comparing the performance of three models. The chart uses **diagonal shading** for visual distinction but does not include a legend. All textual elements are in **English**. --- ### Key Components 1. **Title**: - "Model Performance Comparison" (centered at the top). 2. **Axes**: - **X-axis**: Labeled "Models" with three categories: - Agent - Llama 3.1 8B - Llama 3 8B - **Y-axis**: Labeled "Performance" with values ranging from **0.75** to **0.78** in increments of **0.01**. 3. **Data Points**: - **Agent**: Performance = **0.7832** (highest value). - **Llama 3.1 8B**: Performance = **0.7811**. - **Llama 3 8B**: Performance = **0.7739** (lowest value). 4. **Visual Trends**: - The bars are ordered left-to-right as: **Agent > Llama 3.1 8B > Llama 3 8B**. - Performance decreases progressively from left to right. 5. **Shading**: - All bars feature **diagonal blue stripes** for visual differentiation. --- ### Notes - **No legend** is present to explain the shading pattern. - The chart focuses solely on performance metrics, with no additional annotations or contextual text. - All values are explicitly labeled on top of their respective bars. This chart emphasizes the relative performance differences between the three models, with the "Agent" model achieving the highest score. </details> (a) F1-score comparison. <details> <summary>2509.18710v2/fig/llm_error.png Details</summary>  ### Visual Description # Model Error Rate / Attempts Comparison ## Chart Structure - **Title**: "Model Error Rate / Attempts Comparison" - **X-Axis**: - Labels: `Agent`, `Llama 3.1 8B`, `Llama 3 8B` - Categories: Three distinct models - **Y-Axis**: - Label: `Error Rate (%) / Attempts (times)` - Range: 0 to 5 (linear scale) - **Bars**: - Three vertical bars, one per model - Color: Uniform brownish tone (no legend present) ## Data Points 1. **Agent** - Bar height: ~2 units on Y-axis - Embedded text: `"2 times"` - Interpretation: Likely represents attempts (not error rate percentage) 2. **Llama 3.1 8B** - Bar height: ~3.5 units on Y-axis - Embedded text: `"3.51%"` - Interpretation: Error rate percentage 3. **Llama 3 8B** - Bar height: ~5.2 units on Y-axis - Embedded text: `"5.26%"` - Interpretation: Error rate percentage ## Key Trends - **Error Rate Progression**: - Agent (`2 times`) < Llama 3.1 8B (`3.51%`) < Llama 3 8B (`5.26%`) - **Attempts vs. Error Rate**: - Agent's data is ambiguously labeled as `"2 times"` (possibly attempts), while Llama models show percentages (error rates). This inconsistency suggests a hybrid metric or visualization artifact. ## Spatial Grounding - **Legend**: Absent in the chart. - **Bar Placement**: - `Agent`: Leftmost bar - `Llama 3.1 8B`: Middle bar - `Llama 3 8B`: Rightmost bar - **Text Alignment**: Embedded labels are centered within bars. ## Component Isolation 1. **Header**: - Title only; no subheadings. 2. **Main Chart**: - Three bars with Y-axis scaling and X-axis categories. 3. **Footer**: - No explicit footer present. ## Data Table Reconstruction | Model | Error Rate / Attempts | Value | |----------------|-----------------------|-------------| | Agent | Error Rate / Attempts | 2 times | | Llama 3.1 8B | Error Rate | 3.51% | | Llama 3 8B | Error Rate | 5.26% | ## Notes - The chart combines error rate (%) and attempts (times) on the same axis, creating potential ambiguity in interpretation. - No numerical data table is explicitly provided; values are extracted from bar labels. - All text is in English; no other languages detected. </details> (b) Error rate comparison. Figure 7. Comparison of modular agent (DataAgent) and pure LLM baselines, showing higher reliability and fewer retries for the modular agent paradigm. Table 4. Efficiency comparison: time (seconds) and call times. | Metric | RL-Policy-1 (GRFG (Wang et al., 2022)) | RL-Policy-2 (MOAT (Wang et al., 2023)) | DataAgent | | --- | --- | --- | --- | | Training Time (sec) | 1493.7 | 649.4 | 0 | | Inference Time (sec) | 0.5 | 2.14 | 3.89 | | Calls | 13 | 22 | 2 | | Performance | 0.5768 | 0.6251 | 0.7832 | 6.4. Takeaways on Paradigms for Tabular Data From these comparisons, several insights emerge: (1) Classical and AutoML baselines. These methods are mature, stable, and widely used in practice. They provide a strong reference point, but their reliance on fixed model classes and handcrafted transformations limits adaptability to diverse and evolving datasets. As a result, they often plateau in performance when facing complex feature interactions. (2) Pure LLM approaches. LLMs show strong potential for automation by directly generating transformation or modeling sequences. However, their lack of grounding makes them prone to invalid outputs and silent failures, requiring multiple retries to succeed. This makes them less reliable as standalone solutions, though their flexibility remains valuable. (3) RL-based policies. RL methods can explore transformation spaces thoroughly and sometimes reach strong performance. Yet, they depend on heavy training for each dataset and require detailed environment-specific feedback loops. This investment in time and compute makes them less practical for broad deployment, despite their robustness. (4) Modular agent paradigm (DataAgent). The modular agent design strikes a balance across these trade-offs. It leverages LLMs for reasoning and exploration, but grounds outputs through explicit modules, ensuring task completion. Unlike RL, it is training-free and adapts zero-shot to new datasets, yet still retains exploratory diversity. This positions modular agents as a promising and practical paradigm for general-purpose tabular ML. 7. DataAgents Capabilities Our perspective is that attaching agentic AI to data can equip the data with actionable capabilities, including autonomous feature engineering, symbolic equation extraction, text to sql, tabular QA, data quality assessment, data repairs, and more. 7.1. Automated Feature Engineering Capability Positioned between data collection and machine learning, DataAgents leverage genAI, LLM, reasoning, tool calling to automate data-related tasks. These agents perceive data environments, reason about the space of instance, feature, target variables and multimodal data forms, and act to complete data preprocessing, integration, transformation, repairs, augmentation to streamline feature engineering. Taking feature selection as an example, DataAgents can: 1) reason and call tools of statistical relevance tests (e.g., mutual information, ANOVA) and model-based methods (e.g., L1-regularized regression, gradient boosting feature importance) to remove irrelevant or redundant variables; 2)regard feature selection as generating decision tokens and learn to generate feature selection decisions via instruction tuning from the training data of feature selection/disselection actions paired with corresponding downstream predictive accuracies. There are more studies related to generative and LLM-based feature selection, transformation, and generation studies, which can be used to finetune feature engineering-specific DataAgents (Liu et al., 2021a; Wang et al., 2022; Xiao et al., 2023a, a, b; Ying et al., 2023; Wang et al., 2023; Ying et al., 2024b, a; Gong et al., 2025d, b, c, a). 7.2. Symbolic Equation Extraction Capability Symbolic equation extraction (a.k.a., symbolic regression) aims to extract analytical expressions that explain observed input (X) and output (Y) data relationships. Traditional approaches, such as genetic programming (Burlacu et al., 2020; Gustafson et al., 2005; Haider et al., 2023; Mundhenk et al., 2021a; Uy et al., 2011) and its variants with Monte Carlo Tree Search (Sun et al., 2022) or reinforcement learning (Mundhenk et al., 2021b), explore the equation space through iterative search but often face high computational costs, limited scalability, and difficulties in transferring knowledge across datasets. Neural and Transformer-based generative models (Biggio et al., 2021; Kamienny et al., 2022) improve efficiency but rely heavily on pretraining data and token-level objectives, which are not perfectly aligned with accuracy, interpretability, and parsimony. Zero-shot LLM-based approaches (Shojaee et al., 2024) further demonstrate potential but remain unstable on small or domain-specific datasets. DataAgents offer a new perspective on equation extraction by transforming this task into a goal-directed, interactive process. Instead of performing one-off static searches, agents can iteratively hypothesize candidate expressions, query symbolic verifiers or numerical solvers for feedback, and refine equations based on data fit and prior reasoning trajectories. With memory, planning, and tool-use capabilities, DataAgents can adapt to new datasets, reuse knowledge from past discoveries, and balance exploration and parsimony, making symbolic regression more scalable, adaptive, and reliable. 7.3. Text to SQL Capability In text-to-SQL, we can train DataAgents to convert natural language queries into SQL statements by integrating user descriptions with database schemas, enabling non-experts to access structured data efficiently. Specifically, DataAgents first parses the natural language input to extract intent and entities, and then ground this interpretation to schema elements through techniques such as schema linking (e.g., matching “customer name” to a column cust_name). Next, DataAgents compose the SQL query using syntactic templates or sequence-to-sequence generation models, followed by validation against database constraints. For example, a user request “Find all orders above $500 placed in 2023” is translated into “SELECT * FROM orders WHERE amount ¿ 500 AND year=2023;”. Consider a retail database with tables for orders, customers, and products. An agent can process “Show me the average spending of customers in California” by generating a join between orders and customers filtered by location. Similarly, in a healthcare database, “How many patients were admitted with diabetes in January?” is mapped to a count query on admissions data filtered by diagnosis and date. 7.4. Tabular Question Answering Capability In tabular QA, DataAgents interpret natural language queries and derive answers from single or multiple structured tables by coordinating tasks like planning and execution. For example, DataAgents can process a query like “List employees with salaries above $50,000 in the HR department.” The agent receives the query, tokenizes it, and parses the intent as a filtering operation (salary ¿ $50,000, department = HR). It maps “salaries” and “department” to the respective table columns and generates an operation tree for execution. The steps to achieve tabular QA involve: (1) query reception and intent parsing: determine the type of operation (e.g., aggregation, filtering, joining) and the data elements (e.g., specific columns or tables) by mapping the query to the database schema or tabular structure. (2) plan generation using operation trees or chains: an operation tree is a hierarchical structure where nodes represent specific data operations (e.g., filtering, joining, aggregating) and edges define the sequence or dependency of these operations. For example, a query like “What is the average sales for stores in California?” might result in a tree where the root node is the goal (compute average sales), and child nodes include filtering rows where the state is “California” and aggregating the sales column with a mean operation. An operation chain is linear sequences of operations. (3) data retrieval and augmentation: compute the similarity between query and table schema to identify relevant data, and augment the retrieved tables by incorporating additional context or derived information from LLMs or web sources. (4) step-by-step execution, and (5) result evaluation with refinement. In existing studies, AutoTQA (Zhu et al., 2024a) employs multi-agent LLMs for multi-table QA, and agents like the Planner create execution plans, while the Executor handles text-to-SQL tasks; TQAgent (Zhao et al., 2025) integrates knowledge graphs to enhance reasoning over tables and agents like Planner samples operations by confidence scores, and the Worker executes them using pandas dataframes. 7.5. Data Quality Assessment Capability Data quality assessment refers to the efforts of evaluating the integrity of datasets, including completeness (proportion of non-missing values), accuracy (conformity to true values), consistency (uniformity across entries), and validity (adherence to defined rules). This process identifies issues like duplicates or outliers to ensure reliable analysis. New requirements arising from large data volumes, continuing assessments in streaming data, hybrid, heterogeneous, semi-structure formats. These required automation beyond manual tools, making AI agents essential for scalable, adaptive processing. For instance, Acceldata’s Data Quality Agent automates issue detection in pipelines, identifying anomalies like duplicate entries in sales data. Similarly, Alation’s agentic AI recommends monitoring checks for enterprise datasets, prioritizing assets based on usage patterns. Traditionally, analysts manually examine outliers, noises, null ratios; agents use LLMs and tool calling to scan entire datasets, flagging issues like skewed distributions in sales records or inconsistencies in healthcare entries. Data quality report generation involves: (1) extracting statistical summaries, (3) anomaly detection using rules or tool calling, (4) scoring via metrics like validity rates, and (5) report synthesis. 7.6. Automated Data Repairs Capability Automated data repairs aim to identify and correct quality issues in datasets, such as, imputing mean substitutions to replace missing values, removing outliers, merging duplicates, eliminating noises, fixing inconsistent attribute format, avoiding privacy disclosures, to ensure reliability for downstream tasks like machine learning. Traditionally, analysts manually profile and correct errors; DataAgents shift traditional manual scripting and rule-based repairs to autonomous, learning-driven processes that leverages machine learning tools and LLMs to detect and apply fixes proactively. The key steps of agentic data repairs include: (1)issue detection via tool calling and LLMs token based QA, (2) repair action planning and generation (e.g., imputation), (3) application and validation. 8. Call to Actions As research on DataAgents remains in its nascent stages, we discuss several promising research directions in the future. 8.1. Open Datasets and Benchmarks for Training DataAgents on Diverse Skills Open datasets and benchmarks are essential for training data AI agents on task decompositions, action reasoning, action grounding, and training advanced skills like data preprocessing, data quality assessment, feature engineering, text-to-SQL, symbolic regression, tabular QA, and data repairs. There are benchmark datasets for specific skills: tabular QA (Zhong et al., 2017; Yu et al., 2018; Pasupat and Liang, 2015; Chen et al., 2019b; Nan et al., 2022), text-to-SQL (Pasupat and Liang, 2015; Gan et al., 2021), symbolic equation extraction (Matsubara et al., 2022; de Franca et al., 2024). However, there is limited datasets and benchmarks for training agents to learn how to decompose data-related tasks, and other skills like feature engineering, data quality assessment, data repairs. The research community should curate diverse datasets reflecting real world data-related tasks. 8.2. Action Workflow Optimization for DataAgents Action workflow optimization involves structuring and ordering decomposed actions, defined as discrete operations reasoned from subtasks within a larger task, in order to maximize efficiency and performance in DataAgents. This capability can organize actions into coherent workflows, minimize computational costs, and improves accuracy by prioritizing critical operations. For instance, in tabular QA, we can optimize filtering before aggregation for faster query resolution, or in data repairs, we can prioritize duplicate detection over imputation for consistency. Typical methods for action workflow optimization include: (1) search-based optimization (e.g., MCTS in AFLOW (Zhang et al., 2024b)), which explore action combinations, and (2) heuristic-based optimization, which leverages predefined rules. Aside from existing studies, we call to develop new solutions to reduce computational overhead in large search spaces and bias in action prioritization, and advance multi-agent collaborative workflow optimization. 8.3. Privacy Preservation in DataAgents Privacy preservation in DataAgents refers to techniques that protect sensitive information when handling vast datasets, like data preprocessing, quality assessment, and text-to-SQL, thus, is essential to comply with regulations like GDPR (Sharma, 2019). DataAgents process data without exposing personal details, such as preventing leakage of user identities in tabular QA on customer datasets or safeguarding health records in feature engineering for medical analytics. There are two scenarios that related to privacy preservation. First, there is sensitive information in the training data of finetuning DataAgents, and we do not want DataAgents to generate sensitive information as responses to users. In this case, appropriate solutions include data editing by detecting sensitive information in reprogram data to finetune DataAgent models, or knowledge editing by machine unlearning to modify DataAgent model parameters to unlearn sensitive information and avoid including sensitive information in generated answers. Second, in the post-training QA process, users provide data with sensitive information. In this case, we can add a sensitive information screening step, in order to detect and ignore sensitive information in prompts, or develop a prompt rewriting function to ensure a prompt will not relate DataAgents to sensitive information. 8.4. Guardrailing DataAgents Against Malicious Actions Action guardrails in data AI agents are mechanisms designed to detect, prevent, or mitigate unauthorized or harmful actions during tasks like tabular QA or text-to-SQL, in order to ensure that outputs align with safety protocols. For example, in healthcare, DataAgents should be able to safeguard patient records from unauthorized access during quality assessments Guardrails are critical to protect against vulnerabilities, such as prompt manipulation leading to data breaches or malicious code execution. Typical solutions include prompt injection detectors (e.g., classifiers for jailbreaks) which use fine-tuned models to flag direct injections, alignment auditors (chain-of-thought inspectors) which examine reasoning for misalignment, code analyzers (static analysis engines), action monitoring (real-time inspection and blocking) which employs rule-based filters to halt destructive operations in symbolic regression, and model safety training by enforcing alignment via reinforcement learning from human feedback. References - (1) - Abdelaal et al. (2024) Mohamed Abdelaal, Anil Bora Yayak, Kai Klede, and Harald Schöning. 2024. ReClean: Reinforcement Learning for Automated Data Cleaning in ML Pipelines. In 2024 IEEE 40th International Conference on Data Engineering Workshops (ICDEW). IEEE, 324–330. - Abhyankar et al. (2025) Nikhil Abhyankar, Parshin Shojaee, and Chandan K Reddy. 2025. LLM-FE: Automated Feature Engineering for Tabular Data with LLMs as Evolutionary Optimizers. arXiv preprint arXiv:2503.14434 (2025). - Arshad et al. (2022) Kinza Arshad, Rao Faizan Ali, Amgad Muneer, Izzatdin Abdul Aziz, Sheraz Naseer, Nabeel Sabir Khan, and Shakirah Mohd Taib. 2022. Deep reinforcement learning for anomaly detection: A systematic review. Ieee Access 10 (2022), 124017–124035. - Bai et al. (2025) Haoyue Bai, Wangyang Ying, Nanxu Gong, Xinyuan Wang, and Yanjie Fu. 2025. Privacy-preserving data reprogramming. npj Artificial Intelligence 1, 1 (2025), 10. - Biester et al. (2024) Fabian Biester, Mohamed Abdelaal, and Daniel Del Gaudio. 2024. Llmclean: Context-aware tabular data cleaning via llm-generated ofds. In European Conference on Advances in Databases and Information Systems. Springer, 68–78. - Biggio et al. (2021) Luca Biggio, Tommaso Bendinelli, Alexander Neitz, Aurelien Lucchi, and Giambattista Parascandolo. 2021. Neural symbolic regression that scales. In International Conference on Machine Learning. Pmlr, 936–945. - Blei et al. (2003) David M Blei, Andrew Y Ng, and Michael I Jordan. 2003. Latent dirichlet allocation. Journal of machine Learning research 3, Jan (2003), 993–1022. - Burlacu et al. (2020) Bogdan Burlacu, Gabriel Kronberger, and Michael Kommenda. 2020. Operon C++: an efficient genetic programming framework for symbolic regression. In Proceedings of the 2020 Genetic and Evolutionary Computation Conference Companion (Cancún, Mexico) (GECCO ’20). Association for Computing Machinery, New York, NY, USA, 1562–1570. doi: 10.1145/3377929.3398099 - Chen et al. (2019b) Wenhu Chen, Hongmin Wang, Jianshu Chen, Yunkai Zhang, Hong Wang, Shiyang Li, Xiyou Zhou, and William Yang Wang. 2019b. Tabfact: A large-scale dataset for table-based fact verification. arXiv preprint arXiv:1909.02164 (2019). - Chen et al. (2019a) Xiangning Chen, Qingwei Lin, Chuan Luo, Xudong Li, Hongyu Zhang, Yong Xu, Yingnong Dang, Kaixin Sui, Xu Zhang, Bo Qiao, et al. 2019a. Neural feature search: A neural architecture for automated feature engineering. In 2019 IEEE International Conference on Data Mining (ICDM). IEEE, 71–80. - de Franca et al. (2024) Fabricio O de Franca, Marco Virgolin, M Kommenda, MS Majumder, M Cranmer, G Espada, L Ingelse, A Fonseca, M Landajuela, B Petersen, et al. 2024. SRBench++: principled benchmarking of symbolic regression with domain-expert interpretation. IEEE transactions on evolutionary computation (2024). - Fan et al. (2021) Wei Fan, Kunpeng Liu, Hao Liu, Yong Ge, Hui Xiong, and Yanjie Fu. 2021. Interactive reinforcement learning for feature selection with decision tree in the loop. IEEE Transactions on Knowledge and Data Engineering 35, 2 (2021), 1624–1636. - Fan et al. (2020) Wei Fan, Kunpeng Liu, Hao Liu, Pengyang Wang, Yong Ge, and Yanjie Fu. 2020. Autofs: Automated feature selection via diversity-aware interactive reinforcement learning. In 2020 IEEE International Conference on Data Mining (ICDM). IEEE, 1008–1013. - Gan et al. (2021) Yujian Gan, Xinyun Chen, Qiuping Huang, Matthew Purver, John R Woodward, Jinxia Xie, and Pengsheng Huang. 2021. Towards robustness of text-to-SQL models against synonym substitution. arXiv preprint arXiv:2106.01065 (2021). - Gong et al. (2025a) Nanxu Gong, Sixun Dong, Haoyue Bai, Xinyuan Wang, Wangyang Ying, and Yanjie Fu. 2025a. Agentic feature augmentation: Unifying selection and generation with teaming, planning, and memories. arXiv preprint arXiv:2505.15076 (2025). - Gong et al. (2025b) Nanxu Gong, Chandan K Reddy, Wangyang Ying, Haifeng Chen, and Yanjie Fu. 2025b. Evolutionary large language model for automated feature transformation. In Proceedings of the AAAI conference on artificial intelligence, Vol. 39. 16844–16852. - Gong et al. (2025c) Nanxu Gong, Xinyuan Wang, Wangyang Ying, Haoyue Bai, Sixun Dong, Haifeng Chen, and Yanjie Fu. 2025c. Unsupervised feature transformation via in-context generation, generator-critic llm agents, and duet-play teaming. arXiv preprint arXiv:2504.21304 (2025). - Gong et al. (2025d) Nanxu Gong, Wangyang Ying, Dongjie Wang, and Yanjie Fu. 2025d. Neuro-symbolic embedding for short and effective feature selection via autoregressive generation. ACM Transactions on Intelligent Systems and Technology 16, 2 (2025), 1–21. - Gu et al. (2024) Jiawei Gu, Xuhui Jiang, Zhichao Shi, Hexiang Tan, Xuehao Zhai, Chengjin Xu, Wei Li, Yinghan Shen, Shengjie Ma, Honghao Liu, et al. 2024. A survey on llm-as-a-judge. arXiv preprint arXiv:2411.15594 (2024). - Gustafson et al. (2005) S. Gustafson, E.K. Burke, and N. Krasnogor. 2005. On improving genetic programming for symbolic regression. In 2005 IEEE Congress on Evolutionary Computation, Vol. 1. 912–919 Vol.1. doi: 10.1109/CEC.2005.1554780 - Haider et al. (2023) Christian Haider, Fabricio Olivetti de Franca, Bogdan Burlacu, and Gabriel Kronberger. 2023. Shape-constrained multi-objective genetic programming for symbolic regression. Applied Soft Computing 132 (2023), 109855. - Han et al. (2024) Sungwon Han, Jinsung Yoon, Sercan O Arik, and Tomas Pfister. 2024. Large Language Models Can Automatically Engineer Features for Few-Shot Tabular Learning. arXiv preprint arXiv:2404.09491 (2024). - He et al. (2025) Tianqi He, Xiaohan Huang, Yi Du, Qingqing Long, Ziyue Qiao, Min Wu, Yanjie Fu, Yuanchun Zhou, and Meng Xiao. 2025. Fastft: Accelerating reinforced feature transformation via advanced exploration strategies. arXiv preprint arXiv:2503.20394 (2025). - Heitz and Stockinger (2019) Jonas Heitz and Kurt Stockinger. 2019. Join query optimization with deep reinforcement learning algorithms. arXiv preprint arXiv:1911.11689 (2019). - Hollmann et al. (2023) Noah Hollmann, Samuel Müller, and Frank Hutter. 2023. Large language models for automated data science: Introducing caafe for context-aware automated feature engineering. Advances in Neural Information Processing Systems 36 (2023), 44753–44775. - Horn et al. (2019) Franziska Horn, Robert Pack, and Michael Rieger. 2019. The autofeat python library for automated feature engineering and selection. In Joint European Conference on Machine Learning and Knowledge Discovery in Databases. Springer, 111–120. - Horn et al. (2020) Franziska Horn, Robert Pack, and Michael Rieger. 2020. The autofeat python library for automated feature engineering and selection. In Machine Learning and Knowledge Discovery in Databases: International Workshops of ECML PKDD 2019, Würzburg, Germany, September 16–20, 2019, Proceedings, Part I. Springer, 111–120. - Hsieh et al. (2025) Chihcheng Hsieh, Catarina Moreira, Isabel Blanco Nobre, Sandra Costa Sousa, Chun Ouyang, Margot Brereton, Joaquim Jorge, and Jacinto C Nascimento. 2025. DALL-M: Context-aware clinical data augmentation with large language models. Computers in Biology and Medicine 190 (2025), 110022. - Kamienny et al. (2022) Pierre-Alexandre Kamienny, Stéphane d’Ascoli, Guillaume Lample, and François Charton. 2022. End-to-end symbolic regression with transformers. Advances in Neural Information Processing Systems 35 (2022), 10269–10281. - Khurana et al. (2018) Udayan Khurana, Horst Samulowitz, and Deepak Turaga. 2018. Feature engineering for predictive modeling using reinforcement learning. In Proceedings of the AAAI Conference on Artificial Intelligence, Vol. 32. - Ko et al. (2025) Jeonghyun Ko, Gyeongyun Park, Donghoon Lee, and Kyunam Lee. 2025. FeRG-LLM: Feature engineering by reason generation large language models. arXiv preprint arXiv:2503.23371 (2025). - Kojima et al. (2022) Takeshi Kojima, Shixiang Shane Gu, Machel Reid, Yutaka Matsuo, and Yusuke Iwasawa. 2022. Large language models are zero-shot reasoners. Advances in neural information processing systems 35 (2022), 22199–22213. - Li et al. (2024) Lan Li, Liri Fang, and Vetle I Torvik. 2024. Autodcworkflow: Llm-based data cleaning workflow auto-generation and benchmark. arXiv preprint arXiv:2412.06724 (2024). - Liu et al. (2019) Kunpeng Liu, Yanjie Fu, Pengfei Wang, Le Wu, Rui Bo, and Xiaolin Li. 2019. Automating feature subspace exploration via multi-agent reinforcement learning. In Proceedings of the 25th ACM SIGKDD International Conference on Knowledge Discovery & Data Mining. 207–215. - Liu et al. (2021a) Kunpeng Liu, Yanjie Fu, Le Wu, Xiaolin Li, Charu Aggarwal, and Hui Xiong. 2021a. Automated feature selection: A reinforcement learning perspective. IEEE Transactions on Knowledge and Data Engineering 35, 3 (2021), 2272–2284. - Liu et al. (2021b) Kunpeng Liu, Pengfei Wang, Dongjie Wang, Wan Du, Dapeng Oliver Wu, and Yanjie Fu. 2021b. Efficient reinforced feature selection via early stopping traverse strategy. In 2021 IEEE International Conference on Data Mining (ICDM). IEEE, 399–408. - Liu et al. (2024) Xinyu Liu, Shuyu Shen, Boyan Li, Peixian Ma, Runzhi Jiang, Yuxin Zhang, Ju Fan, Guoliang Li, Nan Tang, and Yuyu Luo. 2024. A Survey of NL2SQL with Large Language Models: Where are we, and where are we going? arXiv preprint arXiv:2408.05109 (2024). - Longpre et al. (2023) Shayne Longpre, Le Hou, Tu Vu, Albert Webson, Hyung Won Chung, Yi Tay, Denny Zhou, Quoc V Le, Barret Zoph, Jason Wei, et al. 2023. The flan collection: Designing data and methods for effective instruction tuning. In International Conference on Machine Learning. PMLR, 22631–22648. - Lu et al. (2025) Yao Lu, Zhaiyuan Ji, Jiawei Du, Yu Shanqing, Qi Xuan, and Tianyi Zhou. 2025. From LLM-anation to LLM-orchestrator: Coordinating Small Models for Data Labeling. arXiv preprint arXiv:2506.16393 (2025). - Maćkiewicz and Ratajczak (1993) Andrzej Maćkiewicz and Waldemar Ratajczak. 1993. Principal components analysis (PCA). Computers & Geosciences 19, 3 (1993), 303–342. - Madaan et al. (2023) Aman Madaan, Niket Tandon, Prakhar Gupta, Skyler Hallinan, Luyu Gao, Sarah Wiegreffe, Uri Alon, Nouha Dziri, Shrimai Prabhumoye, Yiming Yang, et al. 2023. Self-refine: Iterative refinement with self-feedback. Advances in Neural Information Processing Systems 36 (2023), 46534–46594. - Matsubara et al. (2022) Yoshitomo Matsubara, Naoya Chiba, Ryo Igarashi, and Yoshitaka Ushiku. 2022. Rethinking symbolic regression datasets and benchmarks for scientific discovery. arXiv preprint arXiv:2206.10540 (2022). - Meguellati et al. (2025) Elyas Meguellati, Nardiena Pratama, Shazia Sadiq, and Gianluca Demartini. 2025. Are Large Language Models Good Data Preprocessors?. In Companion Proceedings of the ACM on Web Conference 2025. 2129–2132. - Müller et al. (2022) Robert Müller, Steffen Illium, Thomy Phan, Tom Haider, and Claudia Linnhoff-Popien. 2022. Towards anomaly detection in reinforcement learning. In Proceedings of the 21st International Conference on Autonomous Agents and Multiagent Systems. 1799–1803. - Mundhenk et al. (2021b) Terrell Mundhenk, Mikel Landajuela, Ruben Glatt, Claudio P Santiago, Brenden K Petersen, et al. 2021b. Symbolic regression via deep reinforcement learning enhanced genetic programming seeding. Advances in Neural Information Processing Systems 34 (2021), 24912–24923. - Mundhenk et al. (2021a) T Nathan Mundhenk, Mikel Landajuela, Ruben Glatt, Claudio P Santiago, Daniel M Faissol, and Brenden K Petersen. 2021a. Symbolic regression via neural-guided genetic programming population seeding. arXiv preprint arXiv:2111.00053 (2021). - Naeem et al. (2024) Zan Ahmad Naeem, Mohammad Shahmeer Ahmad, Mohamed Eltabakh, Mourad Ouzzani, and Nan Tang. 2024. RetClean: Retrieval-Based Data Cleaning Using LLMs and Data Lakes. Proceedings of the VLDB Endowment 17, 12 (2024), 4421–4424. - Nan et al. (2022) Linyong Nan, Chiachun Hsieh, Ziming Mao, Xi Victoria Lin, Neha Verma, Rui Zhang, Wojciech Kryściński, Hailey Schoelkopf, Riley Kong, Xiangru Tang, et al. 2022. FeTaQA: Free-form table question answering. Transactions of the Association for Computational Linguistics 10 (2022), 35–49. - Nguyen et al. (2024) Giang Nguyen, Ivan Brugere, Shubham Sharma, Sanjay Kariyappa, Anh Totti Nguyen, and Freddy Lecue. 2024. Interpretable llm-based table question answering. arXiv preprint arXiv:2412.12386 (2024). - Ning et al. (2025) Liangbo Ning, Ziran Liang, Zhuohang Jiang, Haohao Qu, Yujuan Ding, Wenqi Fan, Xiao-yong Wei, Shanru Lin, Hui Liu, Philip S Yu, et al. 2025. A survey of webagents: Towards next-generation ai agents for web automation with large foundation models. In Proceedings of the 31st ACM SIGKDD Conference on Knowledge Discovery and Data Mining V. 2. 6140–6150. - Pasupat and Liang (2015) Panupong Pasupat and Percy Liang. 2015. Compositional semantic parsing on semi-structured tables. arXiv preprint arXiv:1508.00305 (2015). - Peng et al. (2023) Baolin Peng, Chunyuan Li, Pengcheng He, Michel Galley, and Jianfeng Gao. 2023. Instruction tuning with gpt-4. arXiv preprint arXiv:2304.03277 (2023). - Peng et al. (2024) Jinfeng Peng, Derong Shen, Tiezheng Nie, and Yue Kou. 2024. RLclean: An unsupervised integrated data cleaning framework based on deep reinforcement learning. Information Sciences 682 (2024), 121281. - Public (2023a) Public. 2023a. OpenML Dataset Download. [EB/OL]. https://www.openml.org - Public (2023b) Public. 2023b. UCI Dataset Download. [EB/OL]. https://archive.ics.uci.edu/ - Schick et al. (2023) Timo Schick, Jane Dwivedi-Yu, Roberto Dessì, Roberta Raileanu, Maria Lomeli, Eric Hambro, Luke Zettlemoyer, Nicola Cancedda, and Thomas Scialom. 2023. Toolformer: Language models can teach themselves to use tools. Advances in Neural Information Processing Systems 36 (2023), 68539–68551. - Sharma (2019) Sanjay Sharma. 2019. Data privacy and GDPR handbook. John Wiley & Sons. - Shinn et al. (2023) Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, and Shunyu Yao. 2023. Reflexion: Language agents with verbal reinforcement learning. Advances in Neural Information Processing Systems 36 (2023), 8634–8652. - Shojaee et al. (2024) Parshin Shojaee, Kazem Meidani, Shashank Gupta, Amir Barati Farimani, and Chandan K Reddy. 2024. Llm-sr: Scientific equation discovery via programming with large language models. arXiv preprint arXiv:2404.18400 (2024). - Song et al. (2023) Chan Hee Song, Jiaman Wu, Clayton Washington, Brian M Sadler, Wei-Lun Chao, and Yu Su. 2023. Llm-planner: Few-shot grounded planning for embodied agents with large language models. In Proceedings of the IEEE/CVF international conference on computer vision. 2998–3009. - Sun et al. (2022) Fangzheng Sun, Yang Liu, Jian-Xun Wang, and Hao Sun. 2022. Symbolic physics learner: Discovering governing equations via monte carlo tree search. arXiv preprint arXiv:2205.13134 (2022). - Sun et al. (2018) Jingyuan Sun, Shaonan Wang, and Chengqing Zong. 2018. Memory, show the way: Memory based few shot word representation learning. In Proceedings of the 2018 Conference on Empirical Methods in Natural Language Processing. 1435–1444. - Tibshirani (1996) Robert Tibshirani. 1996. Regression shrinkage and selection via the lasso. Journal of the Royal Statistical Society Series B: Statistical Methodology 58, 1 (1996), 267–288. - Tzoumas et al. (2008) Kostas Tzoumas, Timos Sellis, and Christian S Jensen. 2008. A reinforcement learning approach for adaptive query processing. History (2008), 1–25. - Uy et al. (2011) Nguyen Quang Uy, Nguyen Xuan Hoai, Michael O’Neill, Robert I McKay, and Edgar Galván-López. 2011. Semantically-based crossover in genetic programming: application to real-valued symbolic regression. Genetic Programming and Evolvable Machines 12 (2011), 91–119. - Wang et al. (2022) Dongjie Wang, Yanjie Fu, Kunpeng Liu, Xiaolin Li, and Yan Solihin. 2022. Group-wise reinforcement feature generation for optimal and explainable representation space reconstruction. In Proceedings of the 28th ACM SIGKDD Conference on Knowledge Discovery and Data Mining. 1826–1834. - Wang et al. (2023) Dongjie Wang, Meng Xiao, Min Wu, Yuanchun Zhou, Yanjie Fu, et al. 2023. Reinforcement-enhanced autoregressive feature transformation: Gradient-steered search in continuous space for postfix expressions. Advances in Neural Information Processing Systems 36 (2023), 43563–43578. - Wang et al. (2024b) Lei Wang, Chen Ma, Xueyang Feng, Zeyu Zhang, Hao Yang, Jingsen Zhang, Zhiyuan Chen, Jiakai Tang, Xu Chen, Yankai Lin, et al. 2024b. A survey on large language model based autonomous agents. Frontiers of Computer Science 18, 6 (2024), 186345. - Wang et al. (2024a) Xinru Wang, Hannah Kim, Sajjadur Rahman, Kushan Mitra, and Zhengjie Miao. 2024a. Human-llm collaborative annotation through effective verification of llm labels. In Proceedings of the 2024 CHI Conference on Human Factors in Computing Systems. 1–21. - Wei et al. (2021) Jason Wei, Maarten Bosma, Vincent Y Zhao, Kelvin Guu, Adams Wei Yu, Brian Lester, Nan Du, Andrew M Dai, and Quoc V Le. 2021. Finetuned language models are zero-shot learners. arXiv preprint arXiv:2109.01652 (2021). - Xiao et al. (2023a) Meng Xiao, Dongjie Wang, Min Wu, Ziyue Qiao, Pengfei Wang, Kunpeng Liu, Yuanchun Zhou, and Yanjie Fu. 2023a. Traceable automatic feature transformation via cascading actor-critic agents. In Proceedings of the 2023 SIAM International Conference on Data Mining (SDM). SIAM, 775–783. - Xiao et al. (2023b) Meng Xiao, Dongjie Wang, Min Wu, Pengfei Wang, Yuanchun Zhou, and Yanjie Fu. 2023b. Beyond discrete selection: Continuous embedding space optimization for generative feature selection. In 2023 IEEE International Conference on Data Mining (ICDM). IEEE, 688–697. - Xiong et al. (2024) Xiaoqiao Xiong, Jiong Yu, and Zhenzhen He. 2024. AutoQuo: An Adaptive plan optimizer with reinforcement learning for query plan selection. Knowledge-Based Systems 306 (2024), 112664. - Yao et al. (2023) Shunyu Yao, Jeffrey Zhao, Dian Yu, Nan Du, Izhak Shafran, Karthik Narasimhan, and Yuan Cao. 2023. React: Synergizing reasoning and acting in language models. In International Conference on Learning Representations (ICLR). - Ying et al. (2024a) Wangyang Ying, Dongjie Wang, Haifeng Chen, and Yanjie Fu. 2024a. Feature selection as deep sequential generative learning. ACM Transactions on Knowledge Discovery from Data 18, 9 (2024), 1–21. - Ying et al. (2024b) Wangyang Ying, Dongjie Wang, Xuanming Hu, Yuanchun Zhou, Charu C Aggarwal, and Yanjie Fu. 2024b. Unsupervised generative feature transformation via graph contrastive pre-training and multi-objective fine-tuning. In Proceedings of the 30th ACM SIGKDD Conference on Knowledge Discovery and Data Mining. 3966–3976. - Ying et al. (2023) Wangyang Ying, Dongjie Wang, Kunpeng Liu, Leilei Sun, and Yanjie Fu. 2023. Self-optimizing feature generation via categorical hashing representation and hierarchical reinforcement crossing. In 2023 IEEE International Conference on Data Mining (ICDM). IEEE, 748–757. - Yu et al. (2018) Tao Yu, Rui Zhang, Kai Yang, Michihiro Yasunaga, Dongxu Wang, Zifan Li, James Ma, Irene Li, Qingning Yao, Shanelle Roman, et al. 2018. Spider: A large-scale human-labeled dataset for complex and cross-domain semantic parsing and text-to-sql task. arXiv preprint arXiv:1809.08887 (2018). - Zhang et al. (2023a) Haochen Zhang, Yuyang Dong, Chuan Xiao, and Masafumi Oyamada. 2023a. Large language models as data preprocessors. arXiv preprint arXiv:2308.16361 (2023). - Zhang et al. (2025) Haodi Zhang, Junyu Yang, Jinyin Nie, Peirou Liang, Kaishun Wu, Defu Lian, Rui Mao, and Yuanfeng Song. 2025. Efficient data labeling by hierarchical crowdsourcing with large language models. In Proceedings of the 31st International Conference on Computational Linguistics. 11290–11303. - Zhang et al. (2024b) Jiayi Zhang, Jinyu Xiang, Zhaoyang Yu, Fengwei Teng, Xionghui Chen, Jiaqi Chen, Mingchen Zhuge, Xin Cheng, Sirui Hong, Jinlin Wang, et al. 2024b. Aflow: Automating agentic workflow generation. arXiv preprint arXiv:2410.10762 (2024). - Zhang et al. (2024a) Shuo Zhang, Zezhou Huang, and Eugene Wu. 2024a. Data cleaning using large language models. arXiv preprint arXiv:2410.15547 (2024). - Zhang et al. (2023b) Tianping Zhang, Zheyu Aqa Zhang, Zhiyuan Fan, Haoyan Luo, Fengyuan Liu, Qian Liu, Wei Cao, and Li Jian. 2023b. Openfe: Automated feature generation with expert-level performance. In International Conference on Machine Learning. PMLR, 41880–41901. - Zhao et al. (2025) Jianbin Zhao, Pengfei Zhang, Yuzhen Wang, Rui Xin, Xiuyuan Lu, Ripeng Li, Shuai Lyu, Zhonghong Ou, and Meina Song. 2025. TQAgent: Enhancing Table-Based Question Answering with Knowledge Graphs and Tree-Structured Reasoning. Applied Sciences (2076-3417) 15, 7 (2025). - Zhong et al. (2017) Victor Zhong, Caiming Xiong, and Richard Socher. 2017. Seq2sql: Generating structured queries from natural language using reinforcement learning. arXiv preprint arXiv:1709.00103 (2017). - Zhu et al. (2024c) Fengbin Zhu, Ziyang Liu, Fuli Feng, Chao Wang, Moxin Li, and Tat Seng Chua. 2024c. Tat-llm: A specialized language model for discrete reasoning over financial tabular and textual data. In Proceedings of the 5th ACM International Conference on AI in Finance. 310–318. - Zhu et al. (2024a) Jun-Peng Zhu, Peng Cai, Kai Xu, Li Li, Yishen Sun, Shuai Zhou, Haihuang Su, Liu Tang, and Qi Liu. 2024a. Autotqa: Towards autonomous tabular question answering through multi-agent large language models. Proceedings of the VLDB Endowment 17, 12 (2024), 3920–3933. - Zhu et al. (2024b) Xiaohu Zhu, Qian Li, Lizhen Cui, and Yongkang Liu. 2024b. Large language model enhanced text-to-sql generation: A survey. arXiv preprint arXiv:2410.06011 (2024).