Data-Analysis-Agent: A Conversational BI Agent That Turns Questions Into SQL and Charts

The problem is the gap between a question and a correct chart

Most people who need a number out of a spreadsheet cannot write the SQL to get it, and most BI tools ask them to learn a query builder or a semantic model first. The README frames the target plainly: say goodbye to complex SQL and Excel formulas, and let users ask things like "which region has the highest profit" or "generate a user growth chart for me" in ordinary language. The audience is the non-technical business user, and secondarily the analyst who wants a first pass before writing anything by hand. What separates this from a plain text-to-SQL wrapper is the second half of the pipeline. Getting the number right is one problem. Choosing a defensible visual encoding for that number is a different problem, and it is the one the project spends most of its surface area on.

From question to chart: the six-stage pipeline and where SSE fits

The README lays out the sequence explicitly: understand the intent, analyse the data structure or schema, generate SQL, execute the query, recommend a chart, and produce a business insight. Each stage is surfaced to the browser as a progress line, shown in the documentation as [1/4] reading the data structure through [4/4] generating the chart and insight. That streaming is done with Server-Sent Events, which is a one-way channel from server to client over plain HTTP. The choice matters for deployment: SSE reconnects automatically and needs no WebSocket upgrade handling, but it also means the client cannot push anything mid-analysis, so any follow-up correction is a new request rather than a message on the same socket. The architecture is a Flask backend with Plotly for rendering, per the badges in the README. The chart recommender is the distinctive component: the README lists 43 chart types grouped into six families (comparison, time trend, distribution, geographic, relationship, and proportion), ranging from the common Bar_Chart and Line_Chart through Marimekko_ABS, Bump_Chart, Ridgeline_Plot, Choropleth_Map, Chord_Diagram and Nightingale_Chart. A recommender that can emit a Marimekko or a ridgeline plot is making a stronger claim than one that picks between bar and line, and it is the part worth evaluating against your own data before you trust the output.

Data sources, and the DuckDB line that does not match the release notes

The capabilities section lists files (Excel and CSV) and databases (SQLite, MySQL, PostgreSQL, SQL Server), with DuckDB and Spark marked as future plans. That conflicts with the v1.3.0 changelog, which describes the Feishu bot reading multi-dimensional table records and feeding them into DuckDB or SQL analysis. The README is the older document here; treat the changelog as the more current statement and check the source before assuming DuckDB is wired up as a first-class source in the UI. The same v1.3.0 entry is the most concrete description of the project's current direction: in a Feishu group, mentioning the bot lets it read a multi-dimensional table, run the analysis, and post the conclusion back to the chat, with the same analysis context shared between mobile and web. The changelog is careful about one boundary: result tables are created, appended to, or updated only after a member explicitly asks. That is a sensible default for an agent that can write back to a shared workspace, and it is the kind of constraint you want stated rather than assumed.

Running it: what the README gives you and what it does not

The README advertises an install section but the supplied excerpt cuts off before the commands, so there is no verified pip install line, no start script, and no port number to quote here. What can be confirmed is the environment: Python 3.10 or later, Flask as the backend, Plotly for visualisation, and an OpenAI-compatible LLM endpoint. The LLM configuration section exists in the table of contents but its body is not in the material, so the exact config keys are unverified. The README also documents slash commands as a feature, again without the command list in the excerpt. If you install this, read the Information/ directory in the repository, which the changelog points to for the full version update logs in both Chinese and English, and expect the setup to involve choosing a model provider and supplying a base URL plus key for an OpenAI-compatible API. The project also recommends running it under a companion desktop tool, 智管-Agent Manager, which can start and stop the agent, show logs and port status, open the web interface, and generate a temporary public share link for demos. That last feature is the one to be careful with: a public link to an agent that holds database credentials is a deployment decision, not a convenience.

Where it breaks: generated SQL, chart fit, and the licence wall

The failure mode is inherent to the design. SQL is generated by a model from an inferred schema, so a column name that is ambiguous, a date stored as text, or a join the model invents will produce a query that runs and returns a wrong answer. The SSE progress display makes the process visible but not verified. Nothing in the material describes a validation step that checks the generated SQL against the schema before execution, and a chart recommended for a result set the model misread will look just as polished as a correct one. The second limitation is scope: 43 chart types is a long menu, and the README does not explain how the recommender decides, only that it does. If your data does not fit the encodings it knows, you get a chart from the list, not the chart you wanted. The third is the licence. The README states CC BY-NC 4.0, prohibits unauthorised commercial use, and asks commercial users to contact the author; the repository licence field reads NOASSERTION, which means GitHub could not identify a standard licence file. Those two signals do not agree, and the README also notes a Chinese software copyright registration. For any commercial deployment, that combination is a reason to stop and get terms in writing rather than a reason to proceed carefully.

How it differs from a semantic-layer BI tool

The obvious comparison is Metabase or Superset. Those tools put a modelled semantic layer between the user and the warehouse: someone defines metrics and dimensions once, and every question is answered against those definitions. The result is consistent and auditable, and it is also why adding a new question can mean adding a new model. This project inverts that. There is no semantic layer; the schema is read at question time and the SQL is written on the fly. That is faster to point at a new CSV and slower to trust at scale, because consistency comes from the model rather than from a definition. The trade is real in both directions. A semantic layer will not answer a question nobody modelled. An LLM agent will answer it, and may be wrong. If your organisation already has governed metrics, this is not a replacement for them. If you have a folder of spreadsheets and no analyst, the trade is more attractive.

Maintenance, releases, and what the changelog tells you about cost

The release cadence visible in the material is roughly one version per month: v1.2.1 in early August 2026, v1.3.0 in late August, v1.3.1 in early September, with the last push to main on 2026-09-09. The v1.3.0 changelog is unusually candid about what was broken, listing failed memory extraction caused by thinking-model output, JSON formatting and scope judgement, a local embedding model download and compatibility fix, and a change where cloud retrieval is now explicitly tested rather than displayed as available when it is not. That last item is worth noting: the project previously showed unverified cloud services as usable. If you depend on the knowledge base retrieval feature, check which version fixed it and whether the fix is in the release you install. The changelog also states that GPU compute is marked as planned and will open after end-to-end acceptance, and that existing code and configuration will not be removed. That is a commitment about backward compatibility, but it is a statement in a changelog, not a tested guarantee. Long-term memory can be switched off in the general settings, and the changelog mentions a 24-hour automatic consolidation and session recovery protection. Budget for the LLM calls: every question is at least one schema read, one SQL generation, and one insight generation, and the cost scales with how often your users ask.

Editorial conclusion

Adopt it if you are doing internal, non-commercial analysis over Excel, CSV, SQLite, MySQL, PostgreSQL or SQL Server, and you want the SQL and the chart choice to be visible as they happen rather than hidden behind a dashboard builder. Do not adopt it if the output feeds a paid product, a client deliverable, or anything you would call commercial use: the README states CC BY-NC 4.0 and asks commercial users to contact the author, and the repository carries a NOASSERTION licence field, so confirm the terms in writing before you build on it. Before installing, verify three things yourself: which chart types the recommender actually emits for your data shape, whether the DuckDB and Spark entries in the source list are implemented or still roadmap, and whether your LLM provider's OpenAI-compatible endpoint handles the streaming path the way the project expects.

Official sources

1. Issues
2. README
3. Releases
4. Zafer-Liu/Data-Analysis-Agent on GitHub