The Problem

AI agents quickly accumulate reusable “skills” (functions, prompts, pipelines). Teams then struggle to locate the right skill, assess its reliability, share it across projects, and keep it up‑to‑date without rebuilding everything from scratch.

What This Does

OpenSpace provides a skill‑management layer that stores skill definitions, execution traces, and quality metrics. The core Python package lives under openspace/ (≈ 440 Python files) and implements the data model, grounding, and runtime support. Two front‑ends consume this layer:

  • Dashboard UI – a React/Vite app in apps/dashboard/ (entry apps/dashboard/src/main.tsx) that visualises skill lineage, quality summaries, and workflow evolution.
  • Terminal UI (TUI) – a TypeScript‑based console client in apps/tui/ (entry apps/tui/src/bridge/index.ts) for quick skill queries and REPL interaction.

Example files:

  • openspace/utils/logging.py – central logger used by 150 modules.
  • openspace/grounding/core/types.py – defines the canonical skill‑type schema.
  • apps/dashboard/src/components/skill-detail/SkillEvolutionGraph.tsx – renders the evolution chart.

How It Is Wired

Execution starts in the UI entry point:

  1. Dashboard – apps/dashboard/src/main.tsx mounts <App/>. The first API call goes through apps/dashboard/src/api/index.ts, which uses the generated client in apps/dashboard/src/api/client.ts to hit the Python backend (the repo does not include a server starter script; the backend is expected to be launched separately, e.g., via a Django/Flask run command).
  2. The backend imports openspace/runtime/app.py (the runtime entry point). This module pulls configuration from openspace/services/runtime_support/settings.py and registers the skill store.
  3. Requests for skill data travel through openspace/services/tooling/context.py → openspace/grounding/core/tool/base.py. The latter is a hub module (40 inbound, 8 outbound imports) and participates in a circular import with openspace/services/tooling/context.py, inflating its instability (0.17) and making changes risky.
  4. All logging funnels through openspace/utils/logging.py, the most‑connected module (150 inbound imports, zero outbound). Its breadth means any modification propagates widely.
  5. The TUI follows a similar path: apps/tui/src/bridge/index.ts creates a bridge object that imports apps/tui/src/state/AppStateStore.ts. This state store imports openspace/grounding/core/tool/base.py (causing a second import cycle) and heavily uses apps/tui/src/screens/REPL.tsx (high instability 0.96).

The import graph contains 111 circular dependencies; the most unstable modules (apps/tui/src/screens/REPL, openspace/runtime/app) have > 0.9 instability, indicating they are likely to break when upstream code changes.

How To Use It

# Clone the repo
git clone https://github.com/moses-y/OpenSpace
cd OpenSpace

# Install Python dependencies (no lockfile, install from source)
pip install -r requirements.txt  # <-- missing; you must create it from imports or use a virtual env

# Install Dashboard UI
cd apps/dashboard
npm ci          # uses package-lock.json
npm run dev     # starts Vite dev server (http://localhost:5173)

# Install TUI
cd ../tui
npm ci
npm run dev     # starts TUI (node script)

Configuration – the dashboard expects an .env file matching the example apps/dashboard/.env.example. The Python backend reads settings from openspace/services/runtime_support/settings.py; you must supply any required environment variables (e.g., database URL) before launching the server (e.g., uvicorn openspace.runtime.app:app).

Running the backend – not bundled in the repo; typical entry is python -m openspace.runtime.app after installing the package.

Real‑World Use

A company deploying multiple LLM‑based agents can run a private OpenSpace instance. Each agent, after completing a task, posts its execution trace to the backend (/api/trace). The dashboard then shows a lineage graph (SkillEvolutionGraph.tsx) where analysts can see which skill versions succeeded, retire low‑quality ones, and push updated skill packages to the shared library for all agents to import.

Code Health & Issues

  • HIGH – Missing lockfile for openspace/communication/bridges/whatsapp/package.json.
  • HIGH – No CI pipeline; repository lacks any .github/workflows/*.
  • HIGH – Committed SQLite dump benchmarks/gdpval/.openspace/openspace.db leaks data.
  • MEDIUM – No Dependabot/Renovate configuration for 7 manifests.
  • MEDIUM – No pre‑commit secret‑scan hook.
  • MEDIUM – Large binary assets (frontend_3.gif, etc.) stored directly in Git.
  • LOW – Missing repository convention files (.editorconfig, formatter config).

Additional observations from static analysis:

  • 12 places use broad except: clauses (e.g., openspace/utils/logging.py).
  • 11 modules have nesting depth ≥ 6, reducing readability.
  • 13 files exceed 1 000 lines, increasing cognitive load.
  • 14 import‑cycle members increase change risk.

The Bottom Line

OpenSpace offers a functional skill‑catalogue and UI for AI agents, with a clear separation between core Python services and modern React/TS front‑ends. However, the codebase suffers from tight coupling (hub modules, import cycles), missing production safeguards (CI, lockfiles, secret scans), and some hygiene gaps (large binaries, data leaks). It is suitable for teams comfortable handling Python backend setup manually and willing to invest in refactoring the most volatile modules before using it in production.