# 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>x1.png Details</summary>
### Visual Description
# Technical Document Extraction: Data Agent Workflow Comparison
This document provides a comprehensive extraction of the information contained in the provided infographic, which compares a manual data analysis workflow ("Without Data Agent") against an automated AI-driven workflow ("With Data Agent").
## 1. Header Information
* **Query:** "Analyze the **sales trends** of **Arizona** retail data and generate a summary report with **visualizations**."
* *Note: Specific keywords are highlighted in blue in the original image.*
---
## 2. Workflow Comparison: "Without Data Agent"
This section describes the traditional, manual process of data analysis.
### A. Input 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 |
### B. Process Steps
1. **Manual Designed SQL:** A user manually writes a query.
* *Text:* "Select ... Where Region = 'Arizona' Group by ... Order By ..."
2. **Data Processing & Visualization:** Manual coding or tool usage.
* *Text:* "(Pandas / Excel / Matplotlib)"
3. **Output:** A line chart titled "Arizona Retail Sales Trends."
---
## 3. Workflow Comparison: "With Data Agent"
This section details the automated pipeline using an AI agent.
### A. Initial Processing (Left Column)
* **Perception (Query & Data Understanding):**
* **Intention:** Analyze the sales trends
* **Region:** Arizona
* **Output:** visualized report
* **Planning + Decomposition:** The agent breaks the query into a list of **Subtasks**:
1. Identify Data Source
2. Generate SQL
3. Execute SQL
4. Verify Results
5. Visualization
6. Summarize Findings
### B. Execution Pipeline (Right Column)
The agent executes the subtasks sequentially:
1. **Identify Data Source:** References the same input table as the manual process.
2. **Generate SQL:**
* *Code:* `SELECT DATE_TRUNC('month', Date) AS month, SUM(Sales) FROM retail_sales WHERE Region = 'Arizona'`
3. **Execute SQL:** Filters the data specifically for Arizona.
* *Result Table Snippet:* Includes 2021-01-15 (Electronics), 2021-01-18 (Clothing), and 2021-03-06 (Arizona, Food, 8,900).
4. **Verify Results:** Uses an LLM (represented by the OpenAI logo) to check accuracy.
* *Options:* "Need Refinement" (loops back to step 1) or "Correct" (proceeds to step 5).
5. **Visualization:** Generates the final chart.
6. **Summary:** Generates a natural language report.
* *Text:* "Arizona retail sales decreased in Feb 2021 but rebounded strongly in March, ending the quarter with a 12% growth compared to January."
---
## 4. Data Visualization Analysis
Both workflows produce a line chart titled **"Arizona Retail Sales Trends"**.
### Chart Components
* **Y-Axis:** Sales (K). Scale: 0 to 30.
* **X-Axis:** Time. Scale: 1980 to 2020 (Note: This appears to be placeholder/template data as it contradicts the 2021 query dates).
* **Legend/Labels:** Placed at the right end of the lines [x=far right, y=aligned with line ends].
* **Data Series & Trends:**
1. **Electronic (Orange Line):** Starts at ~15K, shows significant volatility with a sharp upward trend, ending as the highest category at ~28K.
2. **Clothing (Light Blue Line):** Relatively flat trend with minor fluctuations, hovering around the 12K-15K mark.
3. **Grocery (Medium Blue Line):** Flat trend, consistently positioned around 8K-10K.
4. **Food (Dark Blue Line):** The lowest value series, remaining flat near the 5K mark.
---
## 5. Component Isolation Summary
* **Header:** Defines the natural language query.
* **Top Row:** Shows the "Manual" path: Data -> SQL -> Code -> Chart.
* **Bottom Left:** Shows the "Agent Logic": Perception -> Planning -> Subtask list.
* **Bottom Right:** Shows the "Agent Execution": Step-by-step data filtering, SQL generation, LLM verification, and final summarized output.
</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>x2.png Details</summary>
### Visual Description
# Technical Document Extraction: Autonomous Data Agent Architecture
This document provides a comprehensive extraction of the components, data flow, and functional logic depicted in the provided architectural diagram.
## 1. High-Level Overview
The image illustrates a three-tier architecture for an **Autonomous Data Agent**. The system is designed to ingest various data formats, process complex data tasks through a cognitive core powered by Large Language Models (LLMs), and produce refined outputs.
---
## 2. Component Segmentation
### Region 1: Input Layer (Header)
This region is divided into two primary sections by a vertical dashed line: **Data** (Left) and **Data Task** (Right).
#### A. Data (Sources)
The system accepts three primary categories of input data:
* **Database (SQL, NoSQL):** Represented by a server/database icon.
* **APIs (Web, Services):** Represented by a monitor icon with an API tag.
* **Files (CSV, JSON, etc.):** Represented by a document icon labeled "JSON".
#### B. Data Task (Operations)
This section contains a grid of 21 icons representing various data operations (e.g., Data Analytics, Big Data, Machine Learning, Cloud Computing, Cyber Security). Below the icons, specific complex tasks are listed:
* **Textual List:** "Feature Engineering, Symbolic Equation Extraction, Text2SQL, Tabular QA, Automated Data Repairs, etc."
---
### Region 2: Autonomous Data Agent Core (Main Processing)
This central orange-shaded region describes the cognitive workflow of the agent. Most blocks contain the OpenAI logo, indicating LLM integration.
#### Workflow Components (Sequential Flow):
1. **Perception (Understand data):** The entry point for data analysis.
2. **Planning + Decomposition (Break into subtasks):** Strategic breakdown of the high-level task.
3. **Action Reasoning (Decide action sequence):** Determining the specific steps to execute the plan.
4. **Grounding (Abstract action to Code/Natural Language/Calling APIs):** Translating reasoning into executable formats.
5. **Execution (Run queries/code):** The final operational step where the task is performed.
#### Supporting Component:
* **Memory (Long/short-term):** An orange block that interacts with the core. It provides context to the *Perception* and *Planning + Decomposition* phases.
---
### Region 3: Output & Feedback (Footer)
The blue-shaded region at the bottom handles the results and iterative improvement.
* **Results:** Represented by a dashboard/browser icon. This is the direct output from the *Execution* phase.
* **Refinement (Feedback/reflection):** A process block that takes the results and feeds back into the *Action Reasoning* and *Planning* phases of the Core.
---
## 3. Data Flow and Logic Verification
### Primary Execution Path (Solid Black Arrows)
The main logic flows linearly through the core:
`Data/Task` $\rightarrow$ `Perception` $\rightarrow$ `Planning + Decomposition` $\rightarrow$ `Action Reasoning` $\rightarrow$ `Grounding` $\rightarrow$ `Execution` $\rightarrow$ `Results`.
### Feedback and Memory Loops (Dashed Orange Arrows)
The diagram utilizes dashed orange lines to indicate non-linear information sharing and iterative loops:
1. **Memory Integration:** Memory feeds upward into the `Perception` and `Planning + Decomposition` blocks.
2. **Iterative Refinement:** The `Results` are sent to `Refinement (Feedback/reflection)`.
3. **Recursive Optimization:** From `Refinement`, the flow loops back up to `Action Reasoning` and `Planning + Decomposition`, allowing the agent to self-correct or optimize its strategy based on the initial output.
---
## 4. Textual Transcription (Precise)
| Category | Transcribed Text |
| :--- | :--- |
| **Header Left** | Data; Database (SQL, NoSQL); APIs (Web, Services); Files (CSV, JSON, etc.) |
| **Header Right** | Data Task; Feature Engineering, Symbolic Equation Extraction, Text2SQL, Tabular QA, Automated Data Repairs, etc. |
| **Core Title** | Autonomous Data Agent Core |
| **Core Blocks** | Perception (Understand data); Planning + Decomposition (Break into subtasks); Action Reasoning (Decide action sequence); Grounding (Abstract action to Code/Natural Language/Calling APIs); Execution (Run queries/code); Memory (Long/short - term) |
| **Footer** | Output; Results; Refinement (Feedback/reflection) |
**Language Declaration:** All text in the image is in **English**. No other languages were detected.
</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>x3.png Details</summary>
### Visual Description
# Technical Document Extraction: Data Analysis Workflow Diagram
## 1. Component Isolation
The image is a conceptual diagram illustrating a data analysis workflow involving a Large Language Model (LLM). It is segmented into three primary regions:
* **Top-Left (Input Data):** A structured data table.
* **Top-Right (User Input):** A natural language query with highlighted keywords.
* **Bottom (Processing Loop):** A central AI processor (OpenAI logo) connected to iterative feedback loops.
---
## 2. Data Table Extraction (Top-Left)
The image contains a sample dataset representing retail sales.
| 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 |
---
## 3. Query Transcription (Top-Right)
The text represents a user prompt. Specific keywords are highlighted with a grey background and blue font, indicating entities or actions of interest to the system.
**Full Text:**
"**Query:** Analyze the **sales trends** of **Arizona** retail data and generate a summary report with **visualizations**."
**Highlighted Keywords:**
* sales trends
* Arizona
* visualizations
---
## 4. Process Flow and Diagram Components (Bottom)
The bottom section describes an iterative refinement process.
### Central Component
* **Icon:** The OpenAI logo (green square with a white stylized floral/hexagonal symbol).
* **Function:** Acts as the central processing engine that receives the data table and the query.
### Iterative Loops
There are two primary feedback mechanisms represented by blue rectangular blocks and curved black arrows:
1. **Feedback Loop (Left):**
* **Label:** "Feedback"
* **Flow:** An arrow points from the central AI icon to the "Feedback" block, and another arrow points from the "Feedback" block back to the AI icon. This indicates a continuous loop of evaluating the output.
2. **Refine Loop (Right):**
* **Label:** "Refine"
* **Flow:** An arrow points from the central AI icon to the "Refine" block, and another arrow points from the "Refine" block back to the AI icon. This indicates the process of improving or narrowing down the results based on the feedback.
---
## 5. Summary of Information
This image depicts a **Human-in-the-loop (HITL) or Automated Iterative Analysis** system.
1. **Input:** Structured tabular data and a specific natural language request (Query).
2. **Processing:** The AI interprets the query, focusing on specific parameters (Arizona, sales trends).
3. **Optimization:** The system does not produce a static result but enters a cycle of **Feedback** and **Refinement** to ensure the final "summary report with visualizations" meets the user's requirements.
</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>x4.png Details</summary>
### Visual Description
# Technical Document Extraction: AI Data Analysis Workflow
This image illustrates a conceptual workflow for an AI-driven data analysis system, utilizing a "Planner-Actor" architecture to process natural language queries against structured data.
## 1. Component Isolation
The image is divided into three primary functional regions:
* **Header (Input Layer):** Contains a sample data table and a natural language query.
* **Main Process (Logic Layer):** Two primary functional blocks ("Planner" and "Actor") connected by directional arrows.
* **Feedback Loop (Optimization Layer):** A return path from the Actor back to the Planner.
---
## 2. Data Table Extraction (Header - Left)
The image displays a structured data table representing retail transactions.
| 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 |
---
## 3. Textual Information Extraction (Header - Right)
**Query Text:**
> "**Query:** Analyze the **sales trends** of **Arizona** retail data and generate a summary report with **visualizations**."
*Note: Specific keywords ("sales trends", "Arizona", and "visualizations") are highlighted in blue bold text with grey background shading to indicate their importance as entities or instructions for the AI.*
---
## 4. Diagram Components and Flow (Main Process)
The diagram depicts a sequential and iterative process flow using two main nodes, both featuring the OpenAI logo, suggesting the use of Large Language Models (LLMs).
### Node 1: Planner
* **Location:** Bottom-left blue block.
* **Description:** Acts as the orchestrator.
* **Internal Text:** "Planner (Understand, decompose, sequence steps, assign to actor, refine if needed)"
* **Function:** Receives the input query and data schema to create a logical execution plan.
### Node 2: Actor
* **Location:** Bottom-right blue block.
* **Description:** Acts as the execution engine.
* **Internal Text:** "Actor (Execute SQL/code, process data, generate output)"
* **Function:** Performs the technical tasks (coding/querying) defined by the Planner.
### Flow Dynamics
1. **Input Path:** A black arrow points from the Header (Data/Query) down to the **Planner**.
2. **Execution Path:** A horizontal black arrow points from the **Planner** to the **Actor**, indicating the handoff of instructions.
3. **Feedback Loop:** A curved black arrow at the bottom points from the **Actor** back to the **Planner**, labeled with the text "**Feedback**". This indicates an iterative refinement process where the Actor's results or errors are sent back to the Planner for adjustment.
---
## 5. Summary of Information
The image describes an autonomous agentic workflow where a user's natural language request is first decomposed into a sequence of steps by a **Planner** module. These steps are then executed by an **Actor** module (which handles SQL or Python code). The system includes a **Feedback** mechanism, allowing the Planner to refine the strategy based on the Actor's performance or the data processed.
</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>x5.png Details</summary>
### Visual Description
# Technical Document: Reinforcement Learning Framework for Agents and Planners
This document provides a comprehensive extraction of the technical architecture depicted in the provided image. The image illustrates a comparative reinforcement learning (RL) workflow for two distinct entities: a **Single Agent / Actor** and a **Planner**.
---
## 1. High-Level Architecture Overview
The image is divided into two primary horizontal segments, both utilizing a Proximal Policy Optimization (PPO) reinforcement learning loop.
* **Top Segment (Light Blue Background):** Focuses on the "Single Agent / Actor" workflow.
* **Bottom Segment (Light Pink Background):** Focuses on the "Planner" workflow.
* **Transition:** A blue downward arrow indicates a flow or relationship from the Agent/Actor level to the Planner level.
---
## 2. Segment 1: Single Agent / Actor
This section describes the end-to-end process of an agent generating a direct response and being evaluated.
### 2.1 Input Components (Left)
* **Query (Single agent):** "Analyze the sales trends of Arizona retail data and generate a summary report with visualizations."
* **Query (Actor):** A JSON-formatted instruction:
```json
[
{"step": 1, "skill": "data_retrieval", "sub_instruction": "Load Arizona retail sales data"}
]
```
* **+ Response (Report):** A textual summary: "Sales in Arizona increased steadily, with a 50% growth from January (10k) to March (15k). This indicates strong seasonal recovery."
* **+ Response (Data Table):**
| Date | Sales ($) |
| :--- | :--- |
| 2021-01-15 | 9,230 |
| ... | ... |
| 2021-03-20 | 8,200 |
### 2.2 Processing & Reinforcement Learning Loop (Right)
The inputs and responses are fed into three primary models:
1. **Reward Model (Orange):** Outputs to a **Reward** block (Teal).
* **Evaluation Criteria:** execution success rates, correctness of table hashes, chart specifications, SQL query results, equation fit metrics.
2. **LM (Active) (Blue with Fire Icon):** Represents the model being trained. Outputs **Log-probs**.
3. **LM (Reference) (Grey with Snowflake Icon):** Represents the frozen baseline model. Outputs **Log-probs**.
**Optimization Path:**
* The Log-probs from both LMs are compared in a **Log-ratio + KL-div** block (Pink).
* The **Reward** (Teal) and **Log-ratio + KL-div** (Pink) feed into the **PPO** (Proximal Policy Optimization) block (Dark Blue).
* A feedback line labeled **Policy Gradient Optimization** returns from PPO to the **LM (Active)**.
---
## 3. Segment 2: Planner
This section describes the workflow for a model that breaks down complex queries into subtasks.
### 3.1 Input Components (Left)
* **Query:** "Analyze the sales trends of Arizona retail data and generate a summary report with visualizations." (Identical to the Agent query).
* **+ Response (Subtasks):** A JSON array defining the plan:
```json
[
{"step": 1, "skill": "data_retrieval", "sub_instruction": "Load Arizona retail sales data"},
"......",
{"step": 4, "skill": "report_generation", "sub_instruction": "Summarize the key sales trends in text"}
]
```
### 3.2 Processing & Reinforcement Learning Loop (Right)
The architecture mirrors the Agent loop but with different evaluation criteria for the Reward Model.
1. **Reward Model (Orange):** Outputs to a **Reward** block (Teal).
* **Evaluation Criteria:** proper skill type selection, logical ordering, dependency consistency between subtasks.
2. **LM (Active) (Blue with Fire Icon):** Outputs **Log-probs**.
3. **LM (Reference) (Grey with Snowflake Icon):** Outputs **Log-probs**.
**Optimization Path:**
* **Log-ratio + KL-div** (Pink) calculates the difference between Active and Reference Log-probs.
* **PPO** (Dark Blue) receives input from the **Reward** and the **Log-ratio + KL-div** blocks.
* **Policy Gradient Optimization** loop updates the **LM (Active)**.
---
## 4. Key Technical Notations & Symbols
* **Dashed Orange Arrows:** Connect the "Response (Report)" and "Response (Data Table)" to the Reward Model and LM (Active) in the Single Agent section, indicating these outputs are the subjects of evaluation.
* **Fire Icon:** Symbolizes the "Active" or "Hot" model undergoing updates.
* **Snowflake Icon:** Symbolizes the "Reference" or "Frozen" model used for KL-divergence constraints to prevent catastrophic forgetting or model collapse.
* **KL-div:** Kullback–Leibler divergence, used here as a penalty to ensure the active policy does not drift too far from the reference policy.
</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>fig/case_workflow.png Details</summary>
### Visual Description
# Technical Document Extraction: System Workflow Diagram
## 1. Overview
This image depicts a technical architectural workflow for a data processing and execution pipeline. It illustrates a sequential process starting from raw data ingestion, moving through cleaning, routing, model selection, action determination, grounding, execution, and evaluation. Parallel to the main operational flow is a comprehensive logging and reporting layer.
---
## 2. Component Isolation and Flow Analysis
The diagram is organized into two primary horizontal layers: the **Operational Pipeline** (top) and the **Logging/Reporting Layer** (bottom).
### Region A: Operational Pipeline (Main Flow)
The flow moves from left to right using solid black arrows.
1. **Data**: Represented by an icon of stacked orange layers. This is the input source.
2. **Cleaning**: Represented by a checklist icon with green checkmarks and a red 'X'. This stage filters or prepares the data.
3. **Routing**: Represented by a blue hierarchical tree/node icon. This component directs the cleaned data to specific processing models.
4. **Model Selection**: The router feeds into three potential paths:
* **Classical**: Represented by a red 3D cube icon.
* **LLM (Large Language Model)**: Represented by an orange 3D geometric icon.
* **... (Ellipsis)**: Indicates other potential model types.
5. **Action**: (Beige rounded box with a chess bishop icon). The outputs of the models converge here to determine the next step.
6. **Grounding**: (Light green rounded box with a shield/check icon). This is a validation step. Note: The text in the image contains a typo, spelled as **"Grouding"**.
* **Decision Branch**:
* **Success (Green Checkmark)**: Leads forward to the **Executor**.
* **Failure (Red X)**: A feedback loop (solid black line) returns the process back to the **Routing** stage for correction.
7. **Executor**: (Light pink rounded box with a person/gavel icon). This stage carries out the determined action.
8. **Evaluator**: (Light blue rounded box with a person/lightbulb icon). The final stage that assesses the performance or result of the execution.
### Region B: Logging and Reporting Layer
This layer runs beneath the main pipeline, connected by vertical dashed arrows indicating data capture at every stage.
* **Log Icons**: Six identical yellow notepad icons with pink lines are positioned under the following stages: Cleaning, Routing, Model Selection, Action, Executor, and Evaluator.
* **Log Flow**: Horizontal dashed arrows connect the logs from right to left, aggregating information toward the start of the chain.
* **Summary**: (Icon of an open book). The aggregated logs feed into a summary component.
* **Readable Report**: (Icon of a document with a yellow footer). The final output derived from the Summary.
---
## 3. Textual Transcription
| Label | Context | Notes |
| :--- | :--- | :--- |
| **Data** | Input Source | Starting point of the workflow. |
| **Cleaning** | Process Step 1 | Data preparation stage. |
| **Routing** | Process Step 2 | Decision point for model pathing. |
| **Classical** | Model Type | Traditional machine learning or algorithmic path. |
| **LLM** | Model Type | Large Language Model path. |
| **...** | Model Type | Placeholder for additional model types. |
| **Action** | Process Step 3 | Determination of the task to be performed. |
| **Grouding** | Process Step 4 | *Sic.* (Typo for "Grounding"). Validation/Verification step. |
| **Executor** | Process Step 5 | Implementation of the action. |
| **Evaluator** | Process Step 6 | Final assessment stage. |
| **Log** | Metadata | Repeated 6 times; represents data capture at each stage. |
| **Summary** | Reporting | Aggregation of all log data. |
| **Readable Report** | Final Output | The human-consumable end product of the logging system. |
---
## 4. Logic and Trend Verification
* **Feedback Loop**: There is a critical logic gate at the **Grounding** stage. If the grounding fails (Red X), the system does not proceed to execution but instead loops back to **Routing**. This suggests an iterative refinement process.
* **Data Provenance**: Every major functional block (except the initial Data input) has a direct dashed line to a **Log** entry, ensuring full traceability of the pipeline's logic and transformations.
* **Directionality**: The operational flow is strictly left-to-right (with one specific backward loop), while the reporting flow aggregates right-to-left toward the final "Readable Report" output.
</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>fig/llm_f1.png Details</summary>
### Visual Description
# Technical Document Extraction: Model Performance Comparison
## 1. Document Overview
This image is a vertical bar chart titled **"Model Performance Comparison"**. It compares the performance metrics of three distinct Large Language Model (LLM) configurations. The chart uses a truncated Y-axis to highlight the subtle differences in performance between the models.
---
## 2. Component Isolation
### A. Header
* **Title:** Model Performance Comparison
* **Font Style:** Bold, Serif.
### B. Main Chart Area (Data Visualization)
* **Chart Type:** Vertical Bar Chart.
* **Visual Style:** The bars are light blue with a diagonal cross-hatch (slashed) pattern.
* **Y-Axis (Vertical):**
* **Label:** Performance (Bold, Serif, rotated 90 degrees).
* **Scale:** Ranges from 0.75 to 0.78+.
* **Markers:** 0.75, 0.76, 0.77, 0.78.
* **X-Axis (Horizontal):**
* **Label:** Models (Bold, Serif).
* **Categories:** Agent, Llama 3.1 8B, Llama 3 8B.
### C. Data Labels
Numerical values are placed directly above each bar for precision.
---
## 3. Data Table Reconstruction
| Model (X-Axis) | Performance Value (Data Label) | Visual Trend Rank |
| :--- | :--- | :--- |
| **Agent** | 0.7832 | 1st (Highest) |
| **Llama 3.1 8B** | 0.7811 | 2nd |
| **Llama 3 8B** | 0.7739 | 3rd (Lowest) |
---
## 4. Trend Verification and Analysis
* **Overall Trend:** There is a clear downward slope in performance from left to right.
* **Comparative Analysis:**
* The **"Agent"** configuration shows the highest performance at **0.7832**.
* The **"Llama 3.1 8B"** follows closely with a performance of **0.7811**, representing a slight decrease of approximately 0.0021 units from the Agent.
* The **"Llama 3 8B"** shows the lowest performance of the group at **0.7739**.
* **Significant Observation:** The performance gap between Llama 3.1 8B and Llama 3 8B (0.0072) is significantly larger than the gap between the Agent and Llama 3.1 8B (0.0021). This indicates that the "Agent" and "Llama 3.1 8B" are more closely matched in performance compared to the older "Llama 3 8B" version.
---
## 5. Spatial Grounding and Metadata
* **Legend:** No separate legend box is present; the categories are identified directly on the X-axis.
* **Color Coding:** All bars utilize the same light blue border and diagonal hatch fill, indicating they are part of the same metric series.
* **Language:** The text is entirely in **English**. No other languages are detected.
</details>
(a) F1-score comparison.
<details>
<summary>fig/llm_error.png Details</summary>
### Visual Description
# Technical Document Extraction: Model Error Rate / Attempts Comparison
## 1. Document Overview
This image is a vertical bar chart comparing the performance of three different AI model configurations based on their error rates or number of attempts. The chart uses a consistent visual style with tan-colored bars filled with a circular pattern.
## 2. Component Isolation
### Header
* **Title:** Model Error Rate / Attempts Comparison
### Main Chart Area
* **Y-Axis Label:** Error Rate (%) / Attempts (times)
* **Y-Axis Scale:** Numerical markers from 0 to 5, with increments of 1.
* **X-Axis Label:** Models
* **X-Axis Categories:** Agent, Llama 3.1 8B, Llama 3 8B
* **Data Visualization:** Three vertical bars of increasing height from left to right.
## 3. Data Extraction and Table Reconstruction
The following table represents the data points extracted from the chart. Note that the Y-axis units are mixed (percentage vs. count) depending on the specific model label provided above the bar.
| Model (X-Axis) | Value (Label Above Bar) | Visual Height (Y-Axis) |
| :--- | :--- | :--- |
| **Agent** | 2 times | Exactly at the 2 mark |
| **Llama 3.1 8B** | 3.51% | Midway between 3 and 4 |
| **Llama 3 8B** | 5.26% | Slightly above the 5 mark |
## 4. Trend Verification and Analysis
* **Visual Trend:** The bars show a clear upward slope from left to right. The "Agent" configuration has the lowest value, followed by "Llama 3.1 8B", with "Llama 3 8B" showing the highest value.
* **Comparative Analysis:**
* The **Agent** is the most efficient/accurate, requiring only "2 times" (presumably attempts) or having the lowest relative error.
* **Llama 3.1 8B** shows a significant improvement over its predecessor, with an error rate of **3.51%**.
* **Llama 3 8B** has the highest error rate in this comparison at **5.26%**.
* **Unit Discrepancy:** It is important to note that the first bar is labeled in "times" (attempts), while the subsequent two bars are labeled in percentages (error rate). The Y-axis title "Error Rate (%) / Attempts (times)" accounts for this dual-unit representation.
## 5. Spatial Grounding and Labels
* **Title Placement:** Top center.
* **Y-Axis:** Located on the left vertical edge.
* **X-Axis:** Located on the bottom horizontal edge.
* **Bar Styling:** All bars share the same tan border and internal "polka-dot" or circular fill pattern. There is no color-coded legend because the categories are explicitly labeled on the X-axis.
</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).