Agentic Data Scientist: a planner and a coder in one CLI
An end-to-end Data Scientist
At a glance
- What is it?
- K-Dense's MIT-licensed framework splits a data science task between an OpenRouter-backed planning agent and a Claude Code execution agent, then loops on validation. It is a two-key, two-model pipeline, and the README is honest about neither the cost nor the failure modes.
- Who is it for?
- Adopt it if you already pay for Claude Code and want a planning layer wrapped around it, and if you are comfortable sending the same dataset to two vendors. Do not adopt it if you need a deterministic pipeline, air-gapped execution, or a single bill.
- 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 28 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 between a chat prompt and a finished analysis
Most data science work is not a single question. It is a sequence: read the requirements, decide what a valid answer looks like, write code, check the output against the original question, and revise. A general coding assistant handles the middle step well and the outer steps poorly, because nothing in the loop forces it to state success criteria before it starts writing.
Agentic Data Scientist targets that outer loop. The README describes it as an "Adaptive Multi-Agent Framework for Data Science" that "separates planning from execution, validates work continuously, and adapts its approach based on progress." The intended user is someone with a real dataset and a real analysis question who would otherwise spend the first hour writing a plan and the last hour checking whether the plan was met. It is a command-line tool, not a notebook extension or a hosted service.
Two models, two vendors, one command
The architecture is a split between a planning and review layer and a coding layer. Planning and review agents run against OpenRouter, and the coding agent runs against Anthropic. That is why two keys are mandatory rather than optional: OPENROUTER_API_KEY is documented as required for the planning and review agents, and ANTHROPIC_API_KEY as required for the coding agent.
The runtime sits on Google's Agent Development Kit plus the Claude Agent SDK, according to the README. Tool access comes through Model Context Protocol servers, with Context7 named specifically for live library documentation. That last detail matters more than it sounds. A coding agent that can pull current API docs is less likely to write against a library version that no longer exists.
The workflow itself is described as iterative: plan, execute, validate, reflect. The README's stated rationale is that reviewing a plan is cheaper than reviewing finished code, and that both plans and implementations get validated. Whether the reflection step actually changes the plan mid-run is not something the README demonstrates with a transcript, so treat the adaptivity claim as design intent rather than observed behaviour.
Orchestrated versus simple mode is the only decision that matters
The README is explicit that --mode is not optional, and the stated reason is cost awareness: forcing the flag "ensures you're aware of the complexity and API costs." That is an unusually candid design choice. The two modes are not quality tiers of the same thing.
Orchestrated mode runs the full multi-agent workflow. The documented invocation is agentic-data-scientist "Perform differential expression analysis" --mode orchestrated --files data.csv. It accepts repeated -f flags for multiple files and a directory path for recursive upload, so --files data_folder/ is valid.
Simple mode skips planning entirely and goes straight to coding. The README's own examples are telling: parsing CSV files, explaining how gradient boosting works, quick data exploration. These are tasks where a plan is overhead. Choosing orchestrated mode for a one-line script wastes a planning round trip and the tokens that go with it.
Output lands in ./agentic_output/ by default and is preserved after the run finishes. --temp-dir switches to temporary storage with auto-cleanup, and --keep-files overrides the default preservation. That default is worth noting: a tool that writes to a fixed directory in your current working tree will accumulate artifacts across runs unless you point --working-dir somewhere deliberate.
Installation assumes you already live in the Claude Code ecosystem
The prerequisite list is short and non-negotiable. Claude Code CLI must be installed first, via npm install -g @anthropic-ai/claude-code. The tool itself installs from PyPI with uv tool install agentic-data-scientist, or runs without installation through uvx agentic-data-scientist --mode simple "your query here".
Keys can be exported as environment variables or placed in a .env file in the project directory. The README gives both forms and both key names. There is no configuration file beyond that, no model selection flag documented, and no way to point the planning layer at a different provider. If your organisation has approved one vendor but not the other, this tool does not have a path for you.
Network access is on by default. Setting DISABLE_NETWORK_ACCESS=true (or 1) turns off the fetch_url tool for the ADK agents and the WebFetch and WebSearch tools for the Claude Code agent. That is a real air-gap control, but a partial one: it governs tool access, not the model calls themselves, which still leave your machine. The README does not claim otherwise, and it should not be read as a data residency feature.
What the README does not tell you
There is no cost estimate anywhere in the supplied material. Two vendors, multiple agents, and an iterative review loop mean the token bill scales with how many reflection passes a task triggers, and the README does not say how many that is or what stops the loop. The --mode warning implies the authors know this is the main adoption barrier, but a warning is not a budget.
There is also no documented failure behaviour. If the planning agent produces a plan the coding agent cannot execute, or if validation never converges, the material does not describe a retry limit, a timeout, or an abort path. For a tool whose selling point is self-correction, the absence of a stated stopping condition is the most significant gap.
The README is also truncated in the supplied material, cutting off mid-sentence in the workflow rationale section. Anything about the reflection phase, the validation criteria format, or the agent definitions may exist further down and simply is not available here. Do not assume the documentation is as thin as this excerpt makes it look.
One more thing to note: the README asks readers to star the repository and points to K-Dense Web for "substantially more powerful capabilities." That is a commercial funnel around an MIT-licensed core, which is a legitimate model but worth recognising before you build a workflow on it.
Where a single coding agent is the better tool
Claude Code on its own is the obvious alternative, and the difference is structural rather than a matter of quality. Claude Code runs one model against your working directory with your files in context. Agentic Data Scientist inserts a separate planning and review stage, routed through a different provider, before and around that same coding agent.
The trade is latency and spend against structure. If your task is "rename these columns and plot the distribution," Claude Code will do it in one pass and the planning stage adds nothing. If your task is "determine whether this treatment effect is real given the study design," the upfront success criteria are the part a single agent tends to skip, and that is the case this framework is built for.
There is a second difference: reproducibility. A single-agent session is ad hoc by nature. Agentic Data Scientist writes to ./agentic_output/ and supports --log-file ./analysis.log, which gives you an artifact trail. That is a modest but real advantage for work you need to explain to someone else later.
Maintenance, licence, and what a version bump costs you
The project is MIT licensed, which permits commercial use and modification with the licence and copyright notice retained. That covers the framework code. It does not cover your usage of OpenRouter or Anthropic, which are separate commercial relationships governed by their own terms, and it does not cover the MCP servers or Claude Skills the framework connects to. Those carry their own licences and should be checked individually. None of this is legal advice.
The release cadence visible in the material is uneven: v0.2.1 and v0.2.2 landed on the same day in November 2025, then v0.2.3 arrived in May 2026. A six-month gap between patch releases on a 0.x project means you should expect interface changes rather than assume stability. The --mode flag being mandatory suggests the CLI surface is still being adjusted.
Upgrade cost is mostly environmental. Because the tool depends on the Claude Code CLI, the Claude Agent SDK, ADK, and whatever MCP servers you configure, a version bump can break through any of those layers. Pinning the PyPI version and testing one orchestrated run against a known dataset is the cheapest way to find out whether an upgrade changed your output.
Editorial conclusion
Adopt it if you already pay for Claude Code and want a planning layer wrapped around it, and if you are comfortable sending the same dataset to two vendors. Do not adopt it if you need a deterministic pipeline, air-gapped execution, or a single bill. Verify first that your OPENROUTER_API_KEY and ANTHROPIC_API_KEY both work, then run one task in simple mode and inspect ./agentic_output/ before you trust orchestrated mode with a real analysis.
Community notes