DagFlow-AI: Agentic Synthetic Data Generation for Personalized Statistics Learning

Synthesis: Arthur, Grove, Kmail and Atkisson (2026) describe DagFlow-AI, an agentic tool that generates personalized synthetic datasets for statistics courses. The design problem is narrow and real: an instructor wants a dataset that suits a student's interests, fits a specific learning objective, and matches their skill level, and real datasets rarely hit all three. Rather than asking an LLM to invent observations or to imitate an existing table, DagFlow-AI has LLM agents specify the components of an explicit data-generating mechanism — a variable list, a directed acyclic graph, a distribution per variable, and linear or generalized-linear formulas with coefficients — which a program then executes. The agents never generate data and never write the generation code; a validation script checks their output and errors route back for correction until simulation succeeds. A single case study builds a climate-and-health dataset for an introductory course, and the paper argues alignment with statistical investigation frameworks (GAISE and PPDAC). It is a feasibility and design paper: there are no learning outcomes, no comparison, and the authors state that synthetic data must complement rather than replace real data.

Tool availability: DagFlow-AI itself is not released. The authors withhold the application, source code and access instructions during anonymous review and state they will be included in the final version. It is built on OpenCode, which is openly available, and is model-agnostic, so a released version could run against locally hosted open-weight models.

Key Findings

1. Agents specify; programs generate. The architectural commitment is a separation of labour: agents contribute language understanding, reasoning and world knowledge to define the mechanism, while a program samples from it and a validation script enforces the expected structure. The authors argue this reduces the failure modes of unsupported output, erroneous generated code, and instruction-following drift.
2. The pipeline has six inspectable stages. Dataset Description (domain, learning objectives, extra requirements), Variable Creation, DAG Creation, Distribution Selection, Formula Generation, and Dataset Simulation. Each stage's output is visible in a tab, so an instructor can inspect and correct the agents' choices before committing to a dataset.
3. The mechanism is explicit and reproducible. Because the DAG fixes which variables influence which and the formulas fix direction and magnitude, the resulting data-generating process is a document rather than an opaque model. This is the deliberate contrast with GAN- and VAE-based synthesis, which needs a seed dataset and yields a process users cannot inspect.
4. Generation order comes from the graph. Exogenous variables are sampled from their selected distributions; endogenous variables are generated from their model formulas in the order the DAG implies. Incompatible specifications, such as invalid bounds or coefficients producing numerically unstable values, surface as errors routed to the responsible agent for correction.
5. The tool is model-agnostic but not yet released. Built in Python with Streamlit and the OpenCode agent harness, it runs in GitHub Codespaces or any development container and can be pointed at hosted providers or locally hosted open-weight models. The DagFlow-AI application, its source code and access instructions are withheld to preserve anonymity during review, so as of this preprint the tool is neither publicly available nor open source.
6. The case study needed iteration to work. For the climate-and-health example, the final formula for the response variable was reached only after several rounds of adjustment to achieve stable generation, and the selected distribution for the response was likewise revised before the dataset would generate.
7. Two different learning uses are proposed. Students can analyze a finished synthetic dataset with appropriate methods, or they can inspect, critique and modify the generating mechanism itself, which the authors argue supports treating statistical models as representations of phenomena rather than as given.

The case study

A student in a calculus-based introductory statistics course covering exploratory data analysis, distributions, confidence intervals and simple linear regression states an interest in climate change and its effects on environment and health. From that, the Variable Manager proposes a set of discrete, continuous and categorical variables; the DAG Manager builds a graph in which six variables are direct influences on "Respiratory Hospitalization Rate Per 100K"; the Distribution Manager assigns each variable a distribution and bounds; and the Formula Manager proposes a model for each endogenous variable.

The response variable is specified as right-skewed, which the authors note is pedagogically usable rather than a flaw: an instructor can keep it so students must assess regression assumptions, or swap in a less skewed variable such as "Drought Severity Index" as the response. The final formula uses a log link, and the paper walks through the interpretation — a coefficient of 0.0114 for extreme heat days means each additional such day multiplies the expected rate by e^0.0114 = 1.011, a 1.1% increase adjusted for the other variables. With the cooling-centre programme the only factor associated with a decrease, the signs and relative magnitudes are consistent with the cited literature on heat, wildfire smoke and respiratory hospitalisation.

That "largely consistent with" is the honest hedge in the middle of a design paper, and it is doing real work. The coefficient signs were produced by an LLM drawing on what it knows about the published relationships, then adjusted until the simulation would run. The result looks like the literature because the model was asked to make it look like the literature, and the DAG's edges "appear to be grounded" in the cited sources rather than being verified against them by a check the tool performs.

What the tool does not establish

The paper's own framing is worth holding onto, because the artefact invites a stronger reading than the evidence supports. This is a demonstration of design and feasibility through a single case study. No students used the generated dataset, no learning was measured, and no comparison is reported against a real dataset, against an instructor building a generator by hand, or against an LLM asked to simply produce a table of numbers.

Two claims in the discussion bound the contribution more tightly than the abstract does. First, synthetic data "cannot support substantive conclusions about the world or provide experience with all aspects of data collection, measurement, and study design" — so a student trained on these datasets gains practice in analysis and interpretation while learning nothing about how data come to exist, which is a substantial part of statistical competence. Second, the tool is "intended to complement rather than replace real datasets," which is the right posture but also concedes that the personalization problem it solves is solved by substitution — an infinite supply of tailored synthetic data in place of the harder search for a real dataset a student cares about.

A third limit is practical. The application, source code and access instructions are withheld to preserve anonymity during review and will appear in the final version, so at the time of writing the tool cannot be used or inspected by anyone reading the preprint.

What this means for practice

• Instructors. Treat a generated dataset as a specification to inspect before use, not a product to download: the DAG and formula tabs are where you find out what relationships the data will actually contain, and where you decide whether they are the ones you want students to discover.
• Instructional designers. Decide which of the two uses you are designing for, because analyzing a finished dataset and critiquing its generating mechanism are different tasks with different objectives, and the tool's stage outputs only become learning material in the second.
• Curriculum designers. Keep real datasets in the course, since the authors hold that synthetic data cannot teach measurement, study design, or the provenance of data, and a course built entirely on generated data would leave those unaddressed.
• Educational technology developers. Copy the separation of concerns rather than the pipeline: having agents define a validated specification that a deterministic program executes is the reusable idea, and it is what lets the tool avoid depending on an LLM to produce correct code or correct numbers.
• Researchers. Evaluate this against the alternatives before treating it as an advance — the missing comparisons are a real dataset and an LLM writing the generation script directly, and both are the obvious baselines the design implicitly claims to beat.

Limitations

• The paper reports a single case study demonstrating design and feasibility; it measures no student learning, no usability, and no instructor workload, and the authors state that classroom evaluation is future work.
• No comparison is reported against the salient alternatives: an existing real dataset, an instructor hand-building a data-generating process, or prompting an LLM to write the generation code directly. Without those, the claimed advantage of agent-specified mechanisms over agent-written code is a design argument rather than a measured result.
• The DAG relationships and coefficient magnitudes are described as "largely consistent with" and "appear to be grounded" in the literature, but the tool performs no literature check; correctness of the encoded relationships rests on the instructor inspecting the stages and on the LLM's training knowledge.
• Synthetic data cannot support conclusions about the real world or teach data collection, measurement and study design, which the authors state plainly and which bounds what a course using this tool can claim to cover.
• The application and source code are withheld during anonymous review, so the workflow, the supported distributions, and the reliability of the validation loop could not be independently examined from the preprint.
• The practical work is heavier than the framing suggests: the case study required several iterations to reach stable generation, and adjusting formulas and distributions until simulation succeeds is expertise the tool routes through the user rather than removing.

Citation

Arthur, D., Grove, R., Kmail, Z., & Atkisson, C. (2026). DagFlow-AI: Agentic synthetic data generation for personalized statistics learning. arXiv preprint arXiv:2610.30580.