It drives thewhole lifecycle,under guard.

Getting a raw, messy dataset to a model in production normally means wiring together pandas, scikit-learn, a pile of notebooks, an experiment tracker, and serving code by hand. Every handoff is manual, every step is a place to lose state, and nothing keeps a record of why a given transform happened.

The question I asked is narrow and concrete. Can an LLM agent drive that entire lifecycle, from exploration through NL querying, preprocessing, training, experiments, and deployment, while a human stays in the loop at every commit and no model-generated Python ever runs in-process? That last constraint is the hard part. An agent that writes and runs arbitrary code is a remote-code-execution surface by construction, so the whole design has to treat the model's output as hostile.

Every ML stage is an LLM agent that proposes an action, generates Python into a notebook cell, and validates the result through MCP tool calls, gated on operator approval. The agent never touches a Python process directly. It writes code into a cell, then a hardened Docker container with a persistent Jupyter kernel executes it. Kernel state survives across cells, so a scaler fitted early is still in memory many cells later, the same way a human's notebook session works.

When a cell fails, the agent does not silently emit bad output. The failure feeds a bounded auto-repair loop: the error context goes back into code generation, the agent rewrites the cell, and it re-runs, up to a hard cap, after which control returns to the operator. Validation is its own state in the graph, not an afterthought, so "the code ran" and "the code did the right thing" get checked separately.

The control surface is the Model Context Protocol. 12 tools (get_dataset_profile, run_cell, edit_cell, search_documents and the rest) are exposed to the model over the official MCP SDK with an InMemoryTransport, after schema sanitization strips internal fields the model has no business seeing.