Introduction

This page gives background and terminology.

If you are new to AGILab, do not start here. Start with Newcomer Guide and Quick-Start.

What AGILab is

AGILab turns experimental AI/ML notebooks and scripts into executable, portable, evidence-backed applications that can run locally or on distributed workers, while keeping a handoff path to runnable agi-core notebooks and MLflow tracking evidence.

You do not need a cluster to get that core value. The primary adoption path is local: turn a notebook or script into a replayable app with evidence, artifacts, analysis views, and a notebook or MLflow handoff. Cluster execution is a scale-out option after the local proof works.

It is a framework and web UI for running Python data, ML, and RL projects through one visible workflow: create the app, execute it under controlled runtime choices, inspect artifacts and evidence, then export the result to a notebook or MLflow handoff when needed.

The flagship loop is:

  1. import or create a notebook, script, or app project;

  2. run it through a controlled local environment first;

  3. capture artifacts plus run_manifest.json evidence;

  4. inspect and compare outputs in ANALYSIS, notebook export, MLflow handoff, or proof-pack tools;

  5. promote the result only when the evidence, package contract, and release proof are coherent.

That loop is the practical boundary for AGILAB as an ML workbench: it makes exploratory work replayable before a team chooses a heavier tracker, registry, cluster, or production platform.

It has two main user interfaces:

  • agi-core: the Python API you can call directly from code or notebooks

  • agilab: the web UI that helps select projects, install them, run them, and inspect outputs

Shared components include:

  • agi-env for headless environment setup

  • agi-gui for the Streamlit UI dependency bundle and page helpers

  • agi-web for portable, evidence-backed rich web component payloads

  • agi-node for worker/runtime packaging

  • agi-cluster for local and distributed execution

Historical note

AGILab started as a playground around agi-core.

That is still visible in the product structure today:

  • you can use the web UI for an app-oriented workflow

  • or you can use agi-core directly when you only need the execution layer

Why the project is built this way

The design goal is not to replace every MLOps or orchestration tool. The design goal is to make experimentation easier to run, replay, and inspect before a team commits to heavier platform choices.

The technical choices are driven by three practical goals:

  • Portability: keep projects runnable across local machines and SSH-accessed workers without full VM or container infrastructure as a starting point

  • Simplicity: keep environment setup, execution, and analysis visible in one workflow

  • Performance: allow different execution modes such as pure Python, Cython, and local or distributed runs

Main dependencies

AGILab relies on a small set of core technologies:

  • uv for Python environment management

  • Streamlit for the web UI

  • Dask for distributed execution support

  • asyncssh for SSH-based remote execution

  • Cython for optional compiled execution paths

Optional helpers include OpenAI-compatible models and local assistants such as Ollama and GPT-OSS when configured.

Note

Native Windows is covered for the released package CLI first-proof smoke. Source-checkout installer scripts, cluster workflows, and some local-assistant features still work best through WSL2 or platform-specific setup while native parity continues.