04/MLOps

EpochsLab

Describe an ML goal in plain English; get back a trained model, its artifacts, and a live notebook you can export.

Domain: Developer tools · MLOps
Status: In development

The challenge

Most people who need a trained model for a real problem are not blocked on ideas. They are blocked on the pipeline. Finding a usable dataset, cleaning it, choosing an architecture, deciding whether to train from scratch or fine-tune something that already exists, getting a GPU job to run, and saving the result in a form you can use later — every one of those is a specialist step, and together they are days of setup before you learn whether the idea was any good.

The tools that exist mostly automate the modelling and leave the rest. AutoML will search architectures once you already have clean data and know what you are predicting. It will not go and find the dataset, and it will not tell you that fine-tuning a pretrained model is the better call for what you actually have.

EpochsLab is built to close the whole gap: someone with basic ML knowledge should be able to go from a problem described in a sentence to a trained, stored model, without writing the pipeline by hand — and without the process being a black box they have to take on faith.

Our role

A solo build covering product vision, the agent architecture, backend, frontend and system design end to end.

That means the LangGraph multi-agent graph — an orchestrator hub plus specialists for data, preprocessing, model selection, training and evaluation — the FastAPI backend with MongoDB and Redis, the Jupyter kernel execution engine, on-platform training against cloud GPU providers, model and artifact storage, and the React frontend carrying real-time monitoring, chat, approval UIs, the notebook and the file views. Plus the human-in-the-loop flow, credential encryption, auth and pipeline lifecycle underneath all of it.

What we built

The workflow — describe the task, approve the decisions that matter, get a model.

An orchestrator agent routes the pipeline — collect data, preprocess, select a model, train or fine-tune, evaluate, finish — and the user can steer it by chat at any point. Specialist agents run each stage and write real code into a live Jupyter notebook as they go.

The pipeline pauses at approval gates on the dataset, the preprocessing plan, and the model and training strategy. Then the model is trained on the platform, locally or on cloud GPUs, and stored with its artifacts for reuse and one-click export.

Natural-language project setup — describe what you want to predict or classify; the platform takes it from there.
Dataset discovery, or your own data — search and rank datasets from Kaggle and Hugging Face, or upload your own CSV, JSON or Parquet.
Preprocessing — profile the data, propose a cleaning plan, then generate and run the code that carries it out.
Model selection with an explicit mode — recommend architectures suited to the task and choose the approach per case — train from scratch, fine-tune a pretrained model, or use a custom Hugging Face model.
On-platform and cloud GPU training — run the job inside EpochsLab with live progress, reaching for cloud GPU providers such as RunPod when the work is heavy enough to need one.
Model storage and one-click export — the trained model and its artifacts stay in project storage, downloadable as a package with the notebook, scripts and evaluation output.
Live notebook and a post-run copilot — every agent step becomes executable notebook cells you can inspect, and afterwards you can chat to run more code or add cells in the same kernel.
Human-in-the-loop approvals — approve, revise or reroute at each critical decision point.
Evaluation — metrics, visualisations and a readable report of how the model actually performed.
Multi-LLM and encrypted credentials — choose Azure OpenAI, Gemini or OpenAI per project; Kaggle and Hugging Face keys stored AES-encrypted.

The AI is load-bearing rather than decorative. It ranks datasets, generates the preprocessing and training code, recommends train-versus-fine-tune, diagnoses and retries its own failed code, and powers the copilot after the run. It is not a chat wrapper around a form.

Stack

Technology stack, by layer
Layer	What we used
AI / ML	LangGraph for stateful multi-agent graphs Azure OpenAI · Gemini 2.5 Flash · OpenAI LLM code generation and repair Train-from-scratch and fine-tuning flows Jupyter (ipykernel) execution Kaggle and Hugging Face dataset and model APIs
Frontend	React 19 · TypeScript · Vite Tailwind CSS Zustand · TanStack Query WebSockets for live progress
Backend	Python 3.11+ · FastAPI Beanie / Motor (MongoDB) Redis JWT auth AES-encrypted credentials
Infrastructure / DevOps	Cloud GPU providers (RunPod and similar) for training jobs Platform storage for datasets, notebooks, trained models and artifacts MongoDB Atlas-ready Redis for rate limits, token blacklist and LLM cache

Decisions

Decision01

Pipelines that survive the wait

Approvals take as long as a person takes, and a training job can run for hours. A graph held in memory loses all of it on a restart — which on a long pipeline means losing precisely the expensive part.

So the graph is checkpointed: LangGraph with MongoDB-backed state, an interrupt before every approval node, and a coordinator that resumes from stored state when the approval eventually arrives over WebSocket or REST. A restart mid-pipeline becomes an inconvenience rather than a lost run.

Decision02

Train from scratch, fine-tune, or neither — decided per case

Defaulting to one training strategy is what makes automated ML tools produce bad models confidently. A small dataset fine-tuned onto a pretrained backbone will beat the same data thrown at a fresh architecture, and the reverse holds when the task is genuinely unlike anything pretrained.

Model selection weighs dataset size, task type and stated intent, then recommends candidates with the mode attached — from scratch, fine-tune, or a specific custom model. The mode is part of the recommendation the user approves, not a hidden default they never see.

Decision03

Automation that stays inspectable

The fastest way to make an automated ML platform untrustworthy is to hand back a model with no account of how it was produced. A number without a method is not a result, and a user who cannot check the work cannot defend it to anyone else.

Every specialist writes its own cells into a live notebook, so the pipeline leaves a readable trail of the actual code that ran. The orchestrator routes with guardrails rather than pure model discretion, and approvals support continue, revise or reroute. The user can always see what was done, and change it.

Decision04

Failed generated code is a state to handle, not an error to surface

LLM-generated code fails often enough that treating every failure as a dead end would make the product unusable. Most of those failures are also shallow — a wrong column name, a missing import, a shape mismatch — and a human would fix them without thinking.

So a failure is fed back with its traceback for diagnosis and retry, and only escalates to the user when repair does not converge. That is the difference between a pipeline that finishes and one that stops halfway with a stack trace.

Results

EpochsLab is an own product still in development. No production metrics — users, revenue, latency — are published, so none are claimed here. What follows is what the platform does end to end.

Results
Path covered	Describe the problem, find or upload data, preprocess, select a model, train or fine-tune, store the model, evaluate, export
Training strategy	Chosen per case — from scratch, fine-tune a pretrained model, or a custom Hugging Face model
Compute	On-platform training, with cloud GPU providers such as RunPod for heavier jobs
Transparency	Every agent step written as executable notebook cells, with human approval gates at dataset, preprocessing and model selection
Production metrics	None tracked, and none claimed

Building something like this?Get a quote