DATAGEN: a LangGraph multi-agent pipeline for hypothesis-driven data analysis
DATAGEN: AI-driven multi-agent research assistant automating hypothesis generation, data analysis, and report writing.
At a glance
- What is it?
- DATAGEN wires eight named agents into a LangGraph state machine that turns a CSV path and a research question into code, charts and a written report. It is a research scaffold, not a product: expect to edit YAML, supply five or more API keys, and babysit a ChromeDriver.
- Who is it for?
- Adopt DATAGEN if you already run Python 3.10 with Conda, have keys for at least one LLM provider, and want a readable eight-agent LangGraph skeleton you can edit rather than a finished tool. Do not adopt it if you need a hosted service, a stable API, or a pipeline that runs without a browser driver and a working directory on disk.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository received new commits within the last day.
- What is it written in?
- Mainly Python, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The gap DATAGEN targets: from a CSV to a written report without a human writing the glue
Most analysis work is not modelling. It is the sequence around it: propose an angle, write the loading code, chart the result, search for context, write it up, check it. DATAGEN's README frames the project as automating exactly that chain through a multi-agent system, and the repository's earlier name, AI-Data-Analysis-MultiAgent, is a more honest description than the current brand. The intended user is someone who has a data file and a question and wants a first pass at all five stages, not someone who wants a dashboard or a scheduled job. The entry point reflects that: you place a file in the data directory and edit a user_input string in main.py that contains a datapath line and a natural-language instruction. There is no CLI, no web UI mentioned in the material, and no packaging as a library. That is the scope. It is a scaffold for a single analyst-driven run, and the README's own example instruction, asking for machine learning analysis and complete graphical reports, is the level of task it is built for.
Eight named agents and the state graph that orders them
The mechanism is a LangGraph state graph over eight agents listed in the README: hypothesis_agent, process_agent, visualization_agent, code_agent, searcher_agent, report_agent, quality_review_agent and note_agent. The division is legible. hypothesis_agent proposes research directions. process_agent supervises the run. code_agent writes the analysis code, which is why the setup instructions require a Conda environment name and a ChromeDriver path: generated code is executed, not merely displayed. searcher_agent reaches the web, which is why Firecrawl, fastCRW, Tavily and GitHub tokens appear in the environment template. report_agent produces prose, quality_review_agent critiques it, and note_agent records state across phases. The workflow order given in the README is hypothesis generation, then a human choice to continue or regenerate, then processing (analysis, visualisation, search, report writing), then quality review, then revision as needed. Two details matter more than the roster. First, the human sits inside the loop at step two, so the graph is not fully autonomous. Second, note_agent exists because context has to survive across phases; the README calls this smart memory management without describing the storage, so how notes are persisted is not verifiable from the supplied material.
Configuration is the real interface: agent_models.yaml and CONFIG_DIRECTORY
The most concrete design decision in DATAGEN is that model choice is data, not code. Each agent's provider and model are declared in agent_models.yaml, resolved relative to a CONFIG_DIRECTORY environment variable whose default is config. The README's example assigns gpt-5-nano to hypothesis_agent, gemini-2.5-pro to note_agent and claude-haiku-4-5 to code_agent, each with its own temperature, and lists openai, google, anthropic, ollama and groq as valid providers. That mix is the interesting part: you can put a cheap model on hypothesis generation and a stronger one on note-taking, or route everything to a local Ollama instance and drop the hosted keys. The README also notes that CONFIG_DIRECTORY can point at config_local, which is already in .gitignore, so development settings do not get committed. The README mentions a Progressive Disclosure architecture for agent configuration, but the text is truncated mid-sentence and the mechanism behind that phrase cannot be confirmed from the material. Treat the YAML as the contract and the marketing term as unverified.
Getting it running: the commands and the keys you must supply
Setup follows the README literally. Clone, then create the environment with conda create -n datagen python=3.10 and conda activate datagen, then pip install -r requirements.txt. The Python floor is 3.10. Next, rename .env Example to .env and fill it. Four values are marked required: WORKING_DIRECTORY, which the README says is also used by the filesystem MCP server, CONDA_ENV, CHROMEDRIVER_PATH, and the working directory itself. Everything else is optional in the template but consequential in practice: OPENAI_API_KEY, ANTHROPIC_API_KEY and GOOGLE_API_KEY for the providers you actually configure, FIRECRAWL_API_KEY for scraping, TAVILY_API_KEY for the web-search MCP server, GITHUB_TOKEN for the GitHub MCP server, and the LANGCHAIN_TRACING_V2, LANGCHAIN_PROJECT and LANGCHAIN_API_KEY trio for tracing. The README warns that a missing Firecrawl key reduces query capabilities. CRW_API_KEY and CRW_API_URL cover fastCRW, a Firecrawl-compatible scraper that defaults to a managed cloud endpoint and can be pointed at a self-hosted instance such as http://localhost:3000. Then run python main.py after editing user_input. Note the CHROMEDRIVER_PATH in the template points at a Linux binary, chromedriver-linux64/chromedriver, so non-Linux users must supply their own driver.
Where DATAGEN breaks down
The failure modes are structural rather than incidental. Generated code that executes is generated code that can fail, and the README gives no sandbox, no rollback and no error-handling story; a failed code_agent step lands in a graph that is already mid-run with state held by note_agent. The dependency surface is wide: LangChain, LangGraph, at least one hosted model provider, a browser driver, and optionally three separate search or scraping services. Any one of them failing mid-workflow is a partial run. There is also a cost shape worth naming: eight agents, several of which call a language model, plus web searches, per analysis. The README markets enterprise-grade and production-ready, and nothing in the supplied material supports either claim. There is no test suite mentioned, no benchmark, no release, and no versioning scheme in the repository description. Finally, the human-choice step is a hard constraint, not a setting. If you want unattended batch analysis across fifty files, this pipeline's design puts a person in the middle of every run, and the material offers no documented way to remove that pause.
How it differs from a notebook or a plain LangChain chain
The obvious alternative is a Jupyter notebook with the analyst writing the pandas and matplotlib calls directly. That is faster for one question and gives you full control, but it does not produce a report, a critique or a search step without you writing them. The nearer comparison is a single LangChain agent with a code-execution tool and a search tool. DATAGEN's difference is the split into named roles plus a quality_review_agent that critiques the report before revision, and a note_agent whose only job is carrying state. Whether that separation improves output is not something the supplied material establishes. What it does establish is that the roles are individually configurable, so you can, for example, run hypothesis generation on a small model and report writing on a large one, which a single-agent chain does not let you do without prompt surgery. The trade is orchestration overhead: more model calls, more places for a step to fail, and a graph whose behaviour you have to read in the source rather than in a prompt.
Licence, maintenance and what upgrading actually costs
DATAGEN is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained. That is the permissive end of the spectrum, but MIT says nothing about the models you call: OpenAI, Anthropic, Google, Groq or a self-hosted Ollama instance each carry their own terms, and the README's own note that the Firecrawl key is optional with reduced query capability is a reminder that some functionality is gated behind third-party accounts. The repository is not archived and the last push recorded is 2026-08-16, but no releases were retrieved, so there is no tagged version to pin and no changelog to read. Upgrading means tracking the main branch. Practically, that means your agent_models.yaml, your .env and any local edits to main.py are the things that can break, because provider and model names move faster than the graph structure. Because the model identifiers in the README example are already provider-specific strings, a provider deprecating one is a config edit, not a code change, which is the design working as intended. Nothing here is legal advice; read the MIT text and each provider's terms yourself.
Editorial conclusion
Adopt DATAGEN if you already run Python 3.10 with Conda, have keys for at least one LLM provider, and want a readable eight-agent LangGraph skeleton you can edit rather than a finished tool. Do not adopt it if you need a hosted service, a stable API, or a pipeline that runs without a browser driver and a working directory on disk. Before committing, verify three things in the repository: that requirements.txt installs cleanly on your platform, that the agent_models.yaml provider list covers the model you intend to call, and that the workflow's human-choice step is acceptable in your context, because the pipeline pauses for a person between hypothesis generation and processing.
Community notes