AGILab future work

This note merges three roadmap axes that came out of recent AGILab design discussions:

  • Streamlit-inspired AGILab views

  • Backend observability and audit architecture

  • Connectors and integration

The goal is not to freeze a roadmap prematurely. The goal is to make the next high-value choices explicit and easy to rank.

Streamlit-inspired AGILab views

The most promising Streamlit-style view patterns for AGILab are not generic gallery clones. They are focused application views that reinforce AGILab’s core value: orchestration, evidence, and domain-specific interaction.

1. Experiment Cockpit

Purpose:

  • compare runs quickly

  • inspect KPI summaries

  • open artefacts and benchmark results from one page

Suggested layout:

  • KPI cards on top

  • run filters and selectors on the left

  • comparison charts in the center

  • run table and artefact links below

Why it matters:

  • best value-to-effort ratio

  • directly useful across many AGILab apps

2. Evidence / Release View

Purpose:

  • decide whether a run, model, or artefact bundle is promotable

Suggested layout:

  • release decision banner

  • pass/fail gate checklist

  • baseline vs candidate KPI comparison

  • provenance and reproducibility panel

  • evidence bundle table

Why it matters:

  • strong differentiator for AGILab

  • aligns with evidence-driven engineering and promotion workflows

3. Scenario Playback View

Purpose:

  • replay a run over time

  • inspect state, actions, and KPI evolution together

Suggested layout:

  • run selector and time slider

  • map or network panel

  • current decision-state panel

  • KPI timeline and event log

Why it matters:

  • strong demonstration value

  • good fit with existing AGILab map/network views

Backend observability and audit architecture

AGILab should keep application-specific interaction inside the product and move generic observability, search, and fleet-level monitoring into tools designed for that job.

1. Elastic or OpenSearch + Grafana

Best when:

  • engineering operations and observability are the main priority

Good for:

  • run health

  • worker load

  • step latency

  • failures and alerts

  • SLA-style monitoring

Why it matters:

  • strongest near-term operational value

  • clean split between AGILab interaction and backend observability

2. OpenSearch + OpenSearch Dashboards

Best when:

  • auditability, search, and historical traceability are the main priority

Good for:

  • log exploration

  • artefact traceability

  • historical run search

  • saved audit dashboards

Why it matters:

  • lowest friction for Kibana-like usage patterns

3. Postgres + Superset

Best when:

  • structured KPI analytics and management reporting are the main priority

Good for:

  • curated dashboards

  • cross-project reporting

  • evidence trend analysis

  • management-facing analytics

Why it matters:

  • stronger fit than Elastic-native tools for BI-style reporting

Connectors and integration

Connectors should appear explicitly in the roadmap because they are not just implementation detail. They determine how AGILab reaches external systems, resolves artefacts, and keeps app workflows portable.

1. Connector framework hardening

Purpose:

  • make connector-backed workflows more predictable and portable

Focus areas:

  • path portability

  • artefact resolution

  • stable source and target contracts

  • less app-specific path glue

  • clearer connector diagnostics

Why it matters:

  • reduces friction across apps

  • makes automation more reusable

  • lowers the gap between conceptual workflows and executable steps

Connector integration change request

The concrete change request behind this roadmap item is to replace repeated raw path settings in app_settings.toml with references to reusable connector definition files.

Current problem:

  • pages such as view_maps_network rely on many low-level path keys

  • the same path logic is repeated across settings files

  • defaults are more machine-specific than they should be

  • page code must interpret too many raw path parameters directly

Proposed direction:

  • introduce a declarative Connector model

  • store connector definitions in plain-text TOML files

  • let app_settings.toml reference those connector files instead of embedding all path details inline

First connector model:

  • id

  • kind

  • label

  • description

  • base

  • subpath

  • globs

  • preferred_file_ext

  • metadata

Recommended file placement:

  • next to the app settings

  • for example src/connectors/*.toml

Recommended resolution rule:

  1. explicit query parameters

  2. current session-state widget values

  3. explicit page-level overrides in app_settings.toml

  4. connector references in app_settings.toml

  5. legacy raw path keys

  6. code-level defaults

Compatibility rule:

  • keep legacy raw path keys working in phase 1

  • let connector references win when both are defined

Expected impact:

  • view_maps_network is the primary beneficiary

  • PROJECT must expose connector references clearly enough to stay debuggable

  • PIPELINE should remain unchanged in phase 1

Suggested implementation phases:

  1. core connector model, parser, resolver, and validation

  2. connector-aware default resolution in apps-pages

  3. connector preview and navigation support in PROJECT

  4. optional connector references in PIPELINE only if needed later

Acceptance target:

  • connectors can replace path groups in app_settings.toml

  • existing apps still work without migration

  • connector definitions remain plain-text and git-friendly

2. External system connectors

Purpose:

  • connect AGILab cleanly to external systems and storage backends

Typical targets:

  • Elasticsearch or OpenSearch

  • object storage

  • GitHub or GitLab

  • simulation backends

  • shared data repositories

Why it matters:

  • expands AGILab beyond local file-driven workflows

  • makes observability, reporting, and traceability easier to industrialize

3. Connector-aware views

Purpose:

  • expose connector state and connector-derived provenance directly in the UI

Typical views:

  • import or export provenance panel

  • connector health/status panel

  • external artefact traceability panel

Why it matters:

  • makes integrations visible and debuggable

  • gives users confidence about what data came from where

Decision guidance

Use this rule of thumb:

  • choose Experiment Cockpit if the next need is better daily usability for engineers comparing runs

  • choose Evidence / Release View if the next need is promotion readiness and defensible evidence

  • choose Scenario Playback View if the next need is time-based explanation and demonstration

  • choose Elastic/OpenSearch + Grafana if the next need is operations and observability

  • choose OpenSearch + OpenSearch Dashboards if the next need is audit and historical search

  • choose Postgres + Superset if the next need is curated KPI analytics

  • choose Connector framework hardening and external integrations if the next need is portability, external system access, and reliable artefact flow

Final consolidated poll

Use both paths, because they serve different purposes:

  1. Quick popularity signal in GitHub Discussions

  2. Structured roadmap vote in GitHub Issues

  3. Open roadmap discussion in Issues

Comment template for issues/2

Vote: <one option>
Why: <why this matters now>
Expected value: <product / engineering / user impact>
Constraints or dependencies: <blocking items, staffing, sequencing>

Current candidate priorities

  • Experiment Cockpit

  • Evidence / Release View

  • Scenario Playback View

  • Connector framework hardening and external integrations

  • Elastic/OpenSearch + Grafana

  • OpenSearch + OpenSearch Dashboards

  • Postgres + Superset

If the roadmap label is not visible yet in GitHub, the issue form still works. The repository workflow will create or update that label on the next successful run.

Reference URLs