Auto-Analyst: a DSPy-based open source AI data science platform

What Auto-Analyst actually solves, and for whom

Most chat-with-your-data tools hide the analysis. You get a number and no way to check it. Auto-Analyst takes the opposite position: the README describes a chat interface paired with a code editor where you can "inspect and edit generated code", with AI-assisted edits and an auto-fix path for code that breaks. That pairing is the whole pitch. The product is aimed at people who already write pandas and statsmodels code and want an LLM to draft the first pass, not at people who want the code kept out of sight.

The second audience is developers building vertical agents. The README lists extensions for marketing, quantitative finance and web APIs such as Slack and Notion, and the agent contract is a DSPy signature class, so a new agent is a Python class rather than a fork of the routing layer. If your team has a domain-specific analysis pattern it repeats every week, that extension point is more interesting than the four built-in agents.

What it is not: a hosted BI tool. The README points at a live app for trying it, but the repository itself is the deliverable, and the enterprise analytics dashboard for usage limits, credits and roles is marked as an enterprise feature, not something the open source tree promises to give you.

How the planner routes a question to a DSPy agent

The flow has three inputs and one router. You upload a .csv or .xlsx file through the attachment icon, then type a short description of the dataset. That description matters more than it looks: the README says Auto-Analyst uses it to generate a cleaned, structured metadata summary optimized for LLM workflows, and it explicitly advises renaming generic columns such as var_1 to price or category before analysis. The metadata summary is what the agents see, so a lazy description degrades every downstream answer.

Routing is then either explicit or automatic. Prefixing a query with @agent_name pins it to one agent; leaving the prefix off hands the query to the planner, which the README says selects the right agents, generates plan instructions, coordinates inter-agent workflows and collects results including plots and summaries. The four documented agents map to libraries: preprocessing_agent uses pandas and numpy, statistical_analytics_agent uses statsmodels for regression, correlation and ANOVA, sk_learn_agent trains models such as Random Forest, KMeans and Logistic Regression, and data_viz_agent generates plotly charts with a retriever that picks chart formats.

Two design consequences follow. First, the planner is a single point of failure for unattributed queries: if it misroutes, you get a plausible answer from the wrong toolchain. Second, because agents emit code and the UI lets you edit it, the system is closer to a code generator with a review surface than to a query engine. The README does not describe a sandbox for that generated code.

Installing Auto-Analyst and running a first query

The README does not give installation steps. It points to the live app at autoanalyst.ai/chat and describes the in-product flow, so the repository itself is where a self-hosted setup has to start. The top-level layout separates the work: auto-analyst-backend/ and auto-analyst-frontend/ are the two applications, docs/ holds documentation, terraform/ holds infrastructure definitions, and package-lock.json sits at the root.

Because no install commands are published, the honest first step is to read the package manifests inside those two directories rather than guess at a command. What the README does document is the usage sequence once a deployment exists. Uploading is done from the chat input: the README says to click the paperclip icon near the chat input and upload .csv or .xlsx files. After upload you supply a dataset description, and the README's own advice is to rename ambiguous columns first. Then you either pin an agent or let the planner choose, for example by typing @preprocessing_agent to specify which agent should handle the query, or by typing no agent tag at all so the planner routes it automatically. For a developer adding an agent, the README gives this shape, and it is the clearest piece of API documentation in the file:

class google_ads_analyzer_agent(dspy.Signature):
    goal = dspy.InputField(desc="User goal")
    dataset = dspy.InputField(desc="DataFrame")
    plan_instructions = dspy.InputField(desc="Instructions")
    code = dspy.OutputField(desc="Python code")
    summary = dspy.OutputField(desc="Analysis summary")

Note the contract: the agent returns code and a summary as separate outputs, which is why the editor can show you one and the chat the other.

Where Auto-Analyst is the wrong tool

The README is silent on execution safety. Generated Python that touches pandas, statsmodels and scikit-learn runs somewhere, and nothing in the documentation describes a container, a resource cap, or a confirmation step before that code executes. If your dataset contains regulated data, or if the environment the backend runs in has network access and credentials, that silence is the deciding factor. A tool that writes and runs code on your behalf needs an isolation story before it needs more agents.

Scale is the second boundary. The roadmap lists multi-CSV and multi-sheet Excel analysis as a short-term goal, which means the current state is one dataset per analysis. Multi-file joins are not something the README claims. If your work is joining six exports before you can ask anything, this is not the layer to do it in.

Third, the connector list is a request form, not a shipped catalogue. The README names Google Ads, Meta, LinkedIn Ads, HubSpot, Salesforce and SQL sources including Postgres, MySQL, Oracle and DuckDB, but the same section says "Want more? Submit a request" and the upload flow mentions that more connectors are "available upon request". Treat the connector table as a direction of travel rather than a verified inventory.

Auto-Analyst compared with a notebook assistant

The nearest alternative in practice is an AI assistant embedded in a notebook environment, where the model suggests a cell and you run it yourself. The difference is who holds the execution loop. In the notebook model, you press run, so the blast radius of a bad suggestion is a cell you can see and delete. In Auto-Analyst, the planner coordinates agents and collects results, so the loop is inside the product and the code editor exists to let you audit after the fact rather than gate before it.

That trade buys real speed on exploratory work. Describing a dataset once and then asking four agents in sequence to clean, test, model and chart is faster than writing four cells. It costs you the natural checkpoint. A team that wants the notebook model can still get part of the way there by pinning agents with @agent_name and reading every generated block before trusting the summary, but the README does not describe a mode where execution waits for approval.

The second alternative is writing DSPy pipelines directly. Auto-Analyst is essentially a UI, a planner and a set of signatures over DSPy, so a team with strong Python skills could build the same chain without the frontend. What you would lose is the metadata summarisation step and the chart-format retriever, which are the parts the README treats as built-in value rather than examples.

Maintenance, licence and the real upgrade cost

The repository is not archived and the last push was on 2026-08-20, so the project is current as of this writing. There are no retrieved releases, which means there is no published version history to pin against and no changelog to read before upgrading. That absence is the main maintenance cost: without tagged releases, an upgrade is a pull of the default branch, and the README does not document rollback.

The dependency surface is where drift will show up. The backend depends on DSPy for orchestration, pandas and numpy for cleaning, statsmodels for tests, scikit-learn for models and plotly for charts. A breaking change in any of those, particularly DSPy, lands directly in the agent signatures. The README's own roadmap commits to improved code-editing and auto-debugging, which suggests that area is still moving.

On licensing, the README states the project is released under the MIT License. The repository root listing spells the licence file as LICENCE rather than LICENSE, which is a normal regional spelling but worth noting if you script licence detection in CI, since some scanners look for the US spelling. MIT is permissive and imposes no copyleft on your own code, but the licence covers this repository only. Your LLM provider's terms, and the terms of any connector you wire up, are separate agreements, and the README's bring-your-own-key model means you are the one holding them.

Editorial conclusion

Adopt Auto-Analyst if you already have an LLM API key and want a modifiable agent pipeline rather than a closed notebook assistant; the MIT licence and the dspy.Signature extension point are the real draw. Skip it if you need a documented self-host procedure, a rollback story, or any guarantee about what generated code does before it runs. Verify three things before committing: whether the planner can be forced to a fixed agent, how the code editor's auto-fix path is gated, and what the licence file at the repository root actually says, since the README and the file name differ in spelling.

Frequently asked questions

Official sources

1. FireBird-Technologies/Auto-Analyst on GitHub
2. Issues
3. License: MIT
4. Project website
5. README