Flow

Flow stores experiment data locally on your machine by default. Nothing is uploaded until you choose to sync it with LUML, where the experiment becomes a versioned artifact in the registry.

Flow captures everything you need to understand and reproduce an experiment: parameters, metrics, model artifacts, files, traces, evaluation results, and human annotations. What gets captured depends on whether you’re working with predictive ML or generative AI.

Upload experiments or models to turn them into versioned artifacts in the LUML Registry. From there, you can share, compare, deploy, and monitor them across the rest of the platform.

Flow is framework-agnostic, with native support for popular ML frameworks including scikit-learn, XGBoost, LightGBM, CatBoost, PyTorch, TensorFlow, JAX, and Keras, as well as LLM applications built with OpenAI, Anthropic, LangChain, LlamaIndex, DSPy, and LangGraph, and it's easy to add a custom integration.

No. Flow can work with existing MLflow instrumentation through the luml-mlflow plugin. Point your tracking URI to LUML and your existing logging calls are mapped to Flow automatically.

Both. Flow supports custom scorers as well as built-in LLM-as-a-judge scorers for tasks such as correctness, relevancy, completeness, summarization, and prompt alignment. Use them directly with Flow’s evaluation API.

You don’t have to run the UI at all. Flow includes a built-in text interface for exploring and working with experiments directly from your environment. If you prefer the UI, run it where your Flow data is stored; for remote machines, you can access it through SSH port forwarding.

Yes, three ways. lumlflow mcp starts an MCP server and registers itself in the user-level config of Claude Code, Codex and other harnesses; the agent gets context, status, diff and run. luml-inspect from the Prisma package is a read-only CLI: list, show, metrics. And the daemon's REST API, the same one the UI uses.

There’s no automatic import, but moving existing code is straightforward. Split your workflow into steps, define what each step consumes and produces, and keep shared logic in regular Python modules. Flow’s built-in guide can help an agent convert an existing script or notebook into a Flow notebook.

Yes. Flow steps run as Python code with the same permissions as your environment. Flow does not sandbox execution, so an agent working in a Flow notebook should be trusted like an agent running commands directly in your terminal.

MLflow is great for local experimentation but self-hosting it for a team can be painful. Weights & Biases is a hosted product with no equivalent of the simple mlflow ui workflow. Flow combines the strengths of both: lumlflow ui is local and easy to start, and experiments can be uploaded to LUML when you're ready, which brings multi-user collaboration and the rest of the platform (registry, deployments, monitoring, and more) on top of experiment tracking.

Yes. Flow is designed to be Git-friendly, making your workflows easy to version, review, and maintain. Changes can be tracked through Git, while separate lanes let you explore different approaches without duplicating your workflow. This makes it easier for humans and coding agents to collaborate, iterate on experiments, and keep development reproducible.

Notebooks can hide state, make execution order implicit, and make it difficult to compare alternative versions. Flow turns the workflow into a versioned graph with a clear, non-linear view of cell dependencies, while keeping track of the inputs behind each result.

Yes. Flow provides both Notebook and Canvas views of the same workflow, so you can switch between a familiar linear view and a non-linear view of cell dependencies. You can also work with an AI coding agent directly in the Flow workspace.

Flow lets humans and agents work on the same workflow while keeping a shared history. Changes are tracked, and conflicting edits can be kept in a separate lane rather than silently overwriting existing work.