BambooAI: Conversational Data Analysis With Generated Python
A Python library powered by Language Models (LLMs) for conversational data discovery and analysis.
At a glance
- What is it?
- BambooAI turns natural language questions into executed pandas and Plotly code, with optional planning, search and a Pinecone-backed solution memory. It is a research-grade agent, not a hardened analyst product, and the README itself calls it experimental.
- Who is it for?
- Adopt BambooAI if you are comfortable reading generated pandas and Plotly code before trusting its output, you already hold API keys for at least one supported provider, and you want planning and a solution memory in the same loop. Do not adopt it if you need a governed semantic layer, a hosted BI product, or an analysis path that never executes model-written code.
- 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 last received commits 105 days ago.
- 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 BambooAI targets between a question and a working pandas script
Most people who have a dataframe and a question can describe the question in a sentence. Far fewer can write the groupby, the join against a second file, and the Plotly call that answers it. BambooAI sits in that gap. The README describes it as an experimental tool that processes natural language queries about datasets, generates and executes Python code for analysis and visualisation, and is meant to augment analysts at all levels rather than replace them. The stated audience is anyone who wants insights from data without extensive coding knowledge, which in practice means analysts, data scientists and engineers who can still read the code the model writes. The library accepts a pandas DataFrame directly through the df parameter, or, if none is supplied, it will attempt to source data from the internet or from auxiliary datasets. That second path matters: the project is not only a wrapper around a dataframe you already have. It can pull context from external sources and APIs, which is why search_tool and auxiliary_datasets exist as separate switches.
Six stages, from task routing to a ranked answer in the vector store
The README lays out the loop in six named steps. Initiation starts from a user question, or from a prompt that asks the user for one, and then continues as a conversation until exit. Task routing classifies the question with an LLM and sends it either to a plain text response or to code generation. If the instruction is vague, or if the model hits ambiguity mid-solution, it pauses and asks for direction, sometimes offering a few options. The dynamic prompt build step evaluates what data is needed, may call tools for more context, formulates an analysis plan, performs a semantic search for similar questions already answered, and only then generates code with the selected model. Debugging and execution runs that code, and when it fails, an LLM-based correction pass retries until it succeeds or hits a limit. Finally, results are ranked for quality, high-quality solutions are written to the vector database, and the answer or chart is presented. Two storage layers back this. The dataframe ontology is described as semantic memory, and the vector database as episodic memory, holding prior solutions that the semantic search step can retrieve. That retrieval step is what makes the same question cheaper on a second pass, and it is also the part most likely to surprise you, because a stored solution from an earlier session can shape the code written in a later one.
Configuration surface: constructor flags, JSON agent config and environment variables
Installation is a single pip command, or a clone plus pip install -r requirements.txt. The quick start then copies two files: .env.example to .env for settings, and LLM_CONFIG_sample.json to LLM_CONFIG.json for the combination of agents, models and parameters. The constructor takes df, auxiliary_datasets, max_conversations, search_tool, planning, webui, vector_db, df_ontology, exploratory and custom_prompt_file. Defaults are conservative: planning, search_tool, vector_db and webui are all False, max_conversations is 4, and exploratory is True. The README states that max_conversations controls how many user-assistant pairs stay in context and therefore affects context window and token usage, so raising it is a direct cost decision rather than a quality dial. auxiliary_datasets takes a list of paths and is described as complementary to the main dataframe, pulled in when the generated code executes. custom_prompt_file lets you point at modified prompt templates, which is the escape hatch if the default prompts do not fit your domain. The README example enables planning and search_tool while leaving vector_db off, which is a reasonable first configuration because it avoids the Pinecone dependency entirely.
Running it in a notebook, a Flask web UI or a container
The basic example reads a CSV with pandas, imports BambooAI, sets the Plotly renderer to jupyterlab, constructs the object with planning=True, vector_db=False and search_tool=True, then calls bamboo.pd_agent_converse(). Three deployment paths are documented. The Docker route is marked recommended in the README's own heading. The pip package route installs the library and runs it in your own process. The complete repository route clones the source, which is what you need if you intend to edit prompts or the agent flow itself. Enabling webui=True runs BambooAI as a web application backed by a Flask API. Enabling vector_db=True requires a Pinecone API key, and the README is explicit that search_tool requires appropriate API keys when switched on. Model support spans OpenAI, Anthropic, Gemini, Mistral, Groq, local Ollama, and vLLM, with the exact combination selected in LLM_CONFIG.json rather than in code. That split is the main operational fact to internalise: Python code chooses behaviour, JSON chooses which model performs it.
Where the design bites: code execution, memory contamination and the Pinecone dependency
The library executes model-generated Python. That is the mechanism, not a side effect, and it is the reason the README labels the project experimental. There is no described sandboxing layer, so the boundary is whatever your process, container or notebook already provides. Treat the Docker path as the safer default for that reason alone. The second sharp edge is the vector database. With vector_db=True, ranked solutions are stored and later retrieved by semantic search, which means a wrong answer that scored well can be pulled back into a future prompt and shape new code. The README does not describe an eviction policy, a confidence threshold or a manual review step for what enters that store, so the quality of your memory is only as good as the ranking step. Third, the self-healing retry loop has a limit, and the README does not state what happens when the limit is reached beyond the fact that it stops. Fourth, the optional planning agent is documented as improving solution quality for complex queries, which implies a token cost that the README does not quantify. None of these are reasons to avoid the project. They are reasons to run it on data you are willing to have leave your machine, against an API key you are willing to spend.
How it differs from LangChain's pandas agent and from hosted BI copilots
The closest comparison in the Python ecosystem is LangChain's pandas dataframe agent, which also wraps a DataFrame, generates code through an LLM and executes it. The difference is in what surrounds the generation step. LangChain leaves memory, planning and retrieval to you, assembling them from separate components. BambooAI ships them as constructor flags: planning for a planning agent, vector_db for episodic memory, df_ontology for semantic memory, exploratory for expert selection, custom_prompt_file for prompt overrides, and a Flask web UI behind webui. That is a more opinionated, more integrated loop, and it comes with more moving parts to configure before the first question works. Against hosted BI copilots, the split is different again. Those products keep the model inside a governed semantic layer and return queries against that layer, so the model never writes arbitrary Python. BambooAI does the opposite: it writes and runs real code, which is why it can reach auxiliary datasets, external APIs and internet search, and also why its blast radius is your Python environment rather than a constrained query language.
Maintenance, licence and what an upgrade actually costs you
The project is MIT licensed, which permits commercial use and modification, but the README does not discuss third-party terms, and the model providers and Pinecone carry their own. If you deploy BambooAI commercially, the licence question is not the MIT text, it is your provider agreements and where query data and generated code end up. On cadence, releases are irregular rather than scheduled: v0.4.24 in July 2025, v0.4.25 in August 2025, v0.4.26 in October 2025, with repository activity recorded into June 2026. There is no deprecation policy in the material, so pinning bambooai in requirements.txt and reading the release notes before bumping is the practical approach. The upgrade surface is wider than a normal library because LLM_CONFIG.json is yours to maintain and the prompt templates can be overridden, so a version bump can change behaviour without any change to your own code. Budget for re-running a fixed set of questions after each upgrade and comparing the generated code, not just the answers.
Editorial conclusion
Adopt BambooAI if you are comfortable reading generated pandas and Plotly code before trusting its output, you already hold API keys for at least one supported provider, and you want planning and a solution memory in the same loop. Do not adopt it if you need a governed semantic layer, a hosted BI product, or an analysis path that never executes model-written code. Before committing, verify three things: that your chosen provider appears in the agent and model configuration, that Pinecone is provisioned if you intend to enable vector_db, and that your environment can sandbox the code the library runs.
Community notes