DA-Studio: An Agentic System for End-to-End Data Analysis
Source: arXiv:2606.31423 · Published 2026-06-30 · By Yizhe Liu, Shaolei Zhang, Ju Fan
TL;DR
DA-Studio addresses real-world data analysis as a complex multi-step workflow involving heterogeneous inputs, rather than single-step outputs. Existing large language model (LLM) based tools tend to focus on isolated subtasks such as visualization or code generation, lacking integrated end-to-end execution and traceability. To solve this, DA-Studio integrates an autonomous backend that iteratively generates structured analysis actions, a sandboxed Docker-based execution environment for running generated code safely, and an interactive web interface for inspecting intermediate artifacts, revising code, and exporting reports. Through a generation–execution–feedback loop, the system incrementally builds executable analysis steps from raw files and natural language instructions, revealing transparent execution traces and artifacts throughout the process. This design enables fully autonomous, inspectable, and reproducible data analysis workflows from heterogeneous data inputs to final deliverables.
Key findings
- DA-Studio orchestrates multi-step workflows entirely autonomously from raw data and natural language tasks, without pre-specified pipelines.
- The Docker-based sandbox environment confines code execution to session-scoped isolated workspaces, ensuring safe and reproducible runs.
- Action-structured backend supports unified analysis actions including planning, data inspection, code generation, execution, interpretation, and final answer formulation.
- The system streams incremental action traces and feedback continuously to the user interface, enhancing real-time inspectability (Fig. 3).
- Users can interactively edit and rerun generated code within the same sandboxed session environment.
- Exported reports include both final results and comprehensive analysis traces, along with all intermediate artifacts and generated files.
- The layering design decouples inspection/UI interaction, autonomous action generation, context management, data artifact handling, and environment sandboxing, enabling modular robustness.
- The system supports heterogeneous multi-format inputs (e.g., CSV, JSON, Markdown) and incrementally produces cleaned data, visualizations, and summaries.
Threat model
The adversary is an arbitrary user submitting natural language instructions and data to the system that generate executable analysis code. This code could be erroneous or malicious. The system protects against unsafe execution by sandboxing each session in isolated Docker containers confined to session-rooted filesystems, preventing code from escaping the sandbox or affecting other sessions. The adversary cannot break isolation boundaries or access data outside their session workspace, but the system does not elaborate on advanced threat vectors such as side channels.
Methodology — deep read
The threat model considers the need to safely execute arbitrary LLM-generated analysis code provided by users on their private data, mitigating risks of unsafe or malicious code by sandboxing. Data provenance involves heterogeneous user-uploaded datasets including tabular (CSV), JSON, and document files, with no fixed size limits mentioned. Data and generated outputs are session-scoped with isolated workspace root directories. Architecture consists of five layers: (1) Application Layer managing the web UI and user sessions; (2) Model Layer emitting structured analysis actions (<Analyze>, <Code>, <Execute> etc.) based on user tasks; (3) Context Layer maintaining the evolving session state and prompt context without embedding raw file contents directly, allowing on-demand data retrieval via code execution; (4) Data Layer handling file storage, artifacts, and indexing for inputs and generated outputs; and (5) Environment Layer executing generated code inside Docker containers with Python data science stacks. The system uses a generation–execution–feedback loop where the model outputs an action, code is executed in the sandbox, results returned and incorporated back into context for next steps. This iterative approach avoids one-shot code generation. Training regime or LLM model details are unspecified, but compatibility layers enable using DeepAnalyze native action formats or general LLMs with prompt-constrained formats. No mention of hyperparameters or training epochs. Evaluation is demonstrated via an interactive user demo shown with a merchant-payment dataset containing 2000 rows and multiple files, showing stepwise unfolding of the analysis workflow. Quantitative metrics or user studies are not reported. Reproducibility is facilitated by open-sourcing the demo code and artifacts at the linked GitHub repository. A concrete example: user uploads merchant payment CSV, JSON, and Markdown files, issues a natural-language instruction. The model plans, inspects data, generates code that executes in sandbox returning outputs. These outputs feed back to the model which analyzes and refines subsequent steps, incrementally building visualizations and summaries. The user views streamed action traces and intermediate artifacts, can edit code live, rerun in sandbox, then exports a final Markdown/PDF report bundling artifacts and analysis trace.
Technical innovations
- Unified action-structured backend enabling fully autonomous multi-step generation–execution–feedback analysis workflows without predefined pipelines.
- Session-scoped sandboxed Docker runtime environment managing isolated, controllable execution of generated code tied to session workspaces.
- Inspectability via streamed incremental action traces, execution feedback, and artifact previews integrated into an interactive web UI allowing real-time review and code iteration.
- Data-oriented context management maintaining lightweight file descriptors rather than full raw content in prompts, enabling on-demand data retrieval via code execution.
Datasets
- Merchant payment dataset — ~2000 rows, 5 columns — multi-format inputs (CSV, JSON, Markdown) provided by user uploads for demonstration.
Figures from the paper
Figures are reproduced from the source paper for academic discussion. Original copyright: the paper authors. See arXiv:2606.31423.
Fig 1: Overview of DA-Studio. Given user data and a
Fig 2: Five-layer architecture with three functional views. The Application Layer supports inspectable interaction, the
Fig 3: Screenshot of DA-Studio during a transaction-analysis demo. Region (1) supports task setup over heterogeneous files,
Fig 4 (page 4).
Fig 5 (page 4).
Limitations
- No quantitative evaluation metrics or benchmarks comparing DA-Studio performance with prior LLM-based data analysis tools.
- The threat model assumes sandboxed Docker execution but does not discuss defenses against covert channel or side-channel attacks.
- No user study or usability evaluation to measure benefits of inspectability and interaction workflow.
- LLM training details, exact models used, or inference cost/performance not specified.
- Scalability to very large datasets or very complex workflows not demonstrated or discussed in depth.
- No adversarial robustness tests against deliberately malicious inputs or code generation.
Open questions / follow-ons
- How does the system scale and perform on larger, more complex datasets and workflows beyond the demo case?
- What is the impact of different LLM backends and prompt engineering on the quality and safety of generated analysis code?
- How can user feedback and intervention mechanisms be optimized for better human–AI collaboration during analysis?
- What defenses can enhance sandbox security against more sophisticated adversarial code injection or environment escape attempts?
Why it matters for bot defense
For bot-defense and CAPTCHA practitioners focused on interaction analysis and misuse prevention, DA-Studio illustrates a method for tightly coupling LLM-driven autonomous workflows with execution sandboxing and granular traceability to reduce risk. The multi-layer architecture and session-isolated environment principles demonstrate how to safely integrate code-generative models without exposing backend infrastructure or user data. The inspectability features highlight the value of exposing incremental evidence of automation actions for auditability and human oversight. This approach could inform secure pipelines for ML-supported automation or interaction analysis involving suspicious programmatic behavior. However, DA-Studio targets data analysis workflows rather than adversarial security settings, so applying its execution-grounded iteration requires adapting sandbox threat models and fine-grained anomaly detection.
Cite
@article{arxiv2606_31423,
title={ DA-Studio: An Agentic System for End-to-End Data Analysis },
author={ Yizhe Liu and Shaolei Zhang and Ju Fan },
journal={arXiv preprint arXiv:2606.31423},
year={ 2026 },
url={https://arxiv.org/abs/2606.31423}
}