AGILab Documentation
AGILAB turns experimental AI/ML notebooks and scripts into executable,
portable, evidence-backed applications that can run locally or on distributed
workers. Workflows stay portable: export them back to runnable agi-core
notebooks, keep reproducibility evidence, and hand off tracking evidence to
MLflow when that integration is enabled. The notebook export is an agi-core
runtime handoff: you can continue to run the saved project and stage contract
with only the stable core runtime, without depending on the AGILAB UI or
distributed worker layer. That stable, production-grade core technology remains
the smallest supported handoff surface.
If you are new to AGILab, choose one route first:
See the UI now: open AGILAB Demo for the public Hugging Face Space.
Prove it locally: follow Quick-Start with the built-in
flight_telemetry_projector start from a notebook through PROJECT. Default target: pass the flight first proof in 10 minutes.Use the API/notebook: follow agi-core Demo for the smaller
AgiEnv/AGI.run(...)surface.
The fastest adoption ladder is browser preview, one local first-proof lane, evidence manifest, then expansion into package mode, external apps, or cluster work.
AGILAB is not locked to one web frontend. App projects can declare app-owned
UI surfaces so the same runtime, artifacts, and evidence contract can be opened
through the local Streamlit UI, a hosted Hugging Face backend, or browser-native
agi-web UI islands with React-ready component contracts. See
Page Bundles for the [app_surface] contract and the generic
agilab app surface launcher.
If the local first proof fails, use Newcomer First-Failure Recovery before branching into cluster mode, external app repositories, or broader workflows.
For release-level evidence, use Release Proof; it points to the latest public GitHub release, package proof, CI guardrails, and hosted demo status.
This documentation then expands into architecture, service mode, API references, and example projects.
Start
- Newcomer guide
- Local first proof
- Release proof
- Beta readiness
- Evidence claims policy
- Evidence taxonomy
- First-failure recovery
- Before anything else
- Failure 1:
uvis missing - Failure 2:
./install.sh --install-appsfails - Failure 3: the built-in app path is not found
- Failure 4: the web UI or Main Page/ORCHESTRATE smoke fails
- Failure 5: no fresh output appears under
~/log/execute/flight_telemetry/ - When you are past the newcomer hurdle
- Compatibility matrix
Product
Notebooks and API
Build
- Architecture in 5 minutes
- Product architecture
- Three-plane mental model
- Component view
- Pipeline example
- agilab.py navigation
- Manager vs worker responsibilities
- Runtime ownership
- Package names versus runtime roles
- Manager and worker dependency rule
- Execution back-plane boundary
- Runtime flow
- Repository map
- Core vs optional apps
- Documentation map
- See also
- Architecture scorecard
- Maintenance playbook
- Extension contracts
- Architecture decisions
- AGI Core architecture
- MLOps positioning
- Executive review summary
- MLflow strategy
- Best fit and limits
- Research experimentation evidence
- Engineering prototyping evidence
- Production readiness evidence
- Strategic potential evidence
- Where AGILab helps
- What AGILab does not aim to cover
- Positioning vs. other tools
- Framework comparison
- Selection guide
- Suggested workflow
- See also
- Learning workflows
- Project file structure
- Agent workflows
- Contributor guide
Web UI pages
Operations
- Cluster setup
- Trusted shared deployment
- Kubernetes Job preview
- Parallel stages
- Distributed workers
- Prerequisites
- Stage 1: Configure Distributed Execution in ORCHESTRATE
- Stage 2: Let ORCHESTRATE Generate the Snippet
- Reading
modeandmodes_enabled - Quick UI Walkthrough
- Equivalent Generated Snippets
- Stage 3: Validate the Distribution Before Running
- Stage 4: Reuse the Generated Snippet in WORKFLOW
- Best Practices
- Troubleshooting
- SSH keys for workers
- Service mode
- Service install paths
- Service health schema
- Environment variables
- Troubleshooting
- Known Limitations And Deprecations
- <install.sh> does not generate Run/Debug configurations after worker install failure
- <install.sh> appears frozen while building heavy dependencies
- <UV> VIRTUAL_ENV Warning
- <Python> pip resolver warning during ensurepip
- <UV> Sync Failed
- <DASK> Debug Issue
- <PYCHARM> Run/Debug Configuration is Broken
- <PYCHARM> Can’t open your project
- Failed to read pydantic metadata
- FAQ
Examples
Reference
- Project and packages
- Security and adoption
- Package publishing policy
- User-facing install surfaces
- Internal runtime packages
- Published UI support packages
- Published page-bundle packages
- Published page-bundle umbrella package
- App project packages
- Published app/example umbrella package
- Why keep them published
- Release rule
- Release synchronization contract
- Publishing authentication
- GitHub deployment environments
- Release cadence and post releases
- Typing policy
- Packaging notes
- Framework submodule contract
- Module reference
- Strategic potential
- Licenses