# 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 - Create or answer a poll: - Browse existing poll discussions: 2. Structured roadmap vote in GitHub Issues - Submit a vote: - Browse submitted votes: 3. Open roadmap discussion in Issues - Central roadmap thread: - Use this thread if you want visible engineering discussion in the normal issue workflow. ### Comment template for `issues/2` ```text Vote: Why: Expected value: Constraints or dependencies: ``` ### 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 - Streamlit gallery: - `st.metric`: - `st.fragment`: - `st.pydeck_chart`: - OpenSearch FAQ: - AWS OpenSearch background: - Grafana Elasticsearch datasource: - Superset Elasticsearch support: - Metabase data sources: