# OpenSpace: Skill Lifecycle Management for AI Agents Across Retrieve, Evaluate, Share, and Evolve

> OpenSpace is a Python skill management layer for AI agents. It gives agents a shared library to find the right skill for a task, evaluate which skills actually work through real task outcomes, share successful workflows across agents and team members, and improve skills with each run.

**HKUDS/OpenSpace** — "OpenSpace: The Skill Management Layer for AI Agents" -- https://open-space.cloud/

- Repository: https://github.com/HKUDS/OpenSpace
- Stars: 7,740 · Forks: 922
- Language: Python
- License: MIT
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/hkuds-openspace

## The Problem OpenSpace Solves: Skill Libraries That Cannot Find Themselves

As an AI agent accumulates skills, finding the right skill at the right time becomes a search problem. An agent with dozens of stored skills must match the current task to the most relevant workflow, and that match degrades without a retrieval layer. Skills that worked in previous runs may be silently outdated or broken in new contexts. Successful workflows developed by one agent or team member are invisible to others unless explicitly shared.

OpenSpace addresses this with a dedicated lifecycle layer. The README frames the problem as four questions: 'Find the right skill at the right time? Know which skills actually work in real-world tasks? Learn from failures instead of repeating the same mistakes? Share successful workflows across agents and team members?'

The four lifecycle stages map directly to those questions: Retrieve (find the right skill), Evaluate (know what works), Share (team knowledge from successful workflows), and Evolve (improve with every run). These are not simply a conceptual framework. They correspond to concrete system components: a search and recall service for retrieval, a task-trace upload and quality summary system for evaluation, group and public sharing scopes, and an evolution mechanism that updates skills based on quality evidence.

Version 2.0.0, released on 2026-07-17, introduced the full v2 experience: package-based skill browsing, quality summaries, task-trace uploads, a refreshed dashboard, and a terminal user interface (TUI). The v2 changelog entries in the README document an extended history of incremental additions from April through July 2026.

## Architecture: MCP, CLI, and Local Server Entry Points

The pyproject.toml defines three entry points that correspond to three interaction modes. The CLI entry point, openspace, runs through openspace.entrypoints.cli.main:run_main. The local server entry point, openspace-server, runs through openspace.local_server.main:main. The MCP entry point, openspace-mcp, runs through openspace.entrypoints.mcp.server:run_mcp_server.

The MCP entry point is designed for integration with AI agents like Claude Code and Codex that support the Model Context Protocol. The README mentions 'One Skill Management Layer to Power Them All: Claude Code, Codex, OpenClaw, Hermes, nanobot' as supported agents. Through MCP, an agent can invoke OpenSpace's search and skill retrieval tools as part of its own tool-calling loop without the user managing the integration manually.

The CLI provides a direct command-line interface for humans managing skills, browsing packages, and uploading task traces. The local server handles API endpoints for the dashboard and TUI, and potentially for inter-agent communication via WebSocket (the requirements.txt includes websockets >= 13.0).

The apps/ directory in the repository likely contains the dashboard and TUI applications. The examples/ directory includes examples/my-daily-monitor/, which suggests OpenSpace supports scheduled or recurring agent workflows beyond on-demand skill lookup.

The openspace/entrypoints/ path in the source reflects the architecture: each consumer type (CLI, MCP, server) has its own entry point, keeping the integration surface for each client type separate.

## Installing OpenSpace and Platform Requirements

The pyproject.toml specifies Python >= 3.12 as the minimum version. The package name is openspace, version 2.0.0. Installation installs the core dependencies from requirements.txt, which include litellm (pinned to >=1.70.0,<1.82.7), anthropic (>=0.71.0), openai (>=1.0.0), flask (>=3.1.0), pydantic (>=2.12.0), aiohttp (>=3.10.0), websockets (>=13.0), and several others.

The litellm version pin is documented explicitly in both pyproject.toml and requirements.txt with a comment: 'pinned to avoid PYSEC-2026-2 supply-chain compromise (1.82.7/1.82.8 were malicious).' This is a direct reference to a specific security vulnerability in two litellm releases that were found to contain malicious code. Teams installing OpenSpace should be aware that this constraint intentionally prevents upgrading litellm to those versions.

Platform-specific dependencies are optional. The pyproject.toml defines macos, linux, and windows extra groups. macOS requires pyobjc-core, pyobjc-framework-cocoa, pyobjc-framework-quartz, and atomacos. Linux requires python-xlib and pyatspi. Windows requires pywinauto, pywin32, and PyGetWindow. These are listed as optional extras (commented out in requirements.txt), suggesting the core functionality works without them but platform-specific features such as screen capture or accessibility integration require them.

The communication optional extra adds lark-oapi for Lark/Feishu integration. The dev extra adds pytest, pytest-asyncio, black, flake8, and mypy.

## Private Deployment and the Cloud Option

The README describes OpenSpace as supporting private deployment: 'Deploy OpenSpace privately and keep your workflows, data, and reusable skill assets fully under your own control.' The local server entry point (openspace-server) supports running the full skill management infrastructure within an organization's own environment.

A public cloud option also exists at open-space.cloud, mentioned in the repository description URL. The README changelog describes features that distinguish cloud-hosted from locally-deployed operation: public pages can be browsed without login, private skill endpoints require authentication, and v2 added anonymous browsing of public skills.

The v2 changelog entries describe a progression from local-only operation toward a shared cloud experience: group-scoped skill sharing (2026-05-09), public skill promotion (2026-04-18), anonymous public browsing (2026-06-19), and a 'more complete' cloud experience (2026-06-18). This suggests the cloud path received sustained development through 2026.

For teams that want to keep skills proprietary, the local server path avoids any data leaving the organization. For teams that want to share skills publicly or collaborate across organizations, the cloud path provides a hosted registry. The pyproject.toml's package structure supports both by keeping the local server as one of multiple entry points rather than coupling the entire tool to a cloud service.

## Evidence-Based Skill Evolution

One of the v2 features described in the README changelog is evidence-based skill evolution: skills improve based on real task outcomes rather than manual updates. The README changelog describes 'task-trace uploads' as a mechanism: agents upload records of task execution, and OpenSpace uses those records to evaluate skill quality.

The changelog entry from 2026-04-29 describes this as 'telemetry-backed search, package pull, skill-use sessions, and evolution telemetry for later quality summaries.' A later entry from 2026-04-16 notes that 'evolution candidate status became trackable,' meaning OpenSpace can record which skills are under consideration for update before committing to a change.

The 'Evaluate' lifecycle stage means skills are not assumed to work indefinitely once created. If a skill consistently fails or underperforms in task traces, OpenSpace marks it accordingly. Skills that succeed are promoted; skills that no longer deliver value can be retired. The README describes this as: 'Use real task outcomes to keep what works, improve what falls short, and confidently retire what no longer delivers value.'

This is the meaningful design difference from a static skill directory. A directory of skill definitions in a markdown file or a JSON config does not know whether any of them work in practice. OpenSpace's quality tracking creates a feedback loop between task execution and skill management.

## Limitations and Cases Where OpenSpace Is Not Needed

OpenSpace requires Python 3.12. Environments running Python 3.11 or earlier are excluded. This is not a soft requirement; the pyproject.toml enforces it with requires-python = '>=3.12'.

The dependency footprint is substantial for a management layer. The core requirements include flask, aiohttp, pydantic, litellm, anthropic, openai, and websockets, among others. Teams deploying in constrained environments or managing transitive dependency conflicts will find the installation heavier than a minimal tool.

OpenSpace is designed for agents that have a growing, reusable skill library. A single-purpose agent with three hard-coded tools has no skill discovery or lifecycle management problem. The overhead of a skill management layer with retrieval, evaluation, and evolution is not justified for simple automation scripts.

The Windows communication gateway startup had documented reliability issues, addressed in changelog entries from 2026-05-27 and 2026-06-03, which switched to Windows API-specific PID checks. Teams on Windows should verify they have the latest version and test the gateway startup path before relying on it in a production workflow.

The closest alternative is a plain file-based skills directory: a folder of scripts or YAML definitions with descriptive names, managed manually by the developer. This has zero dependencies and works with any agent, but provides no retrieval, no quality tracking, and no sharing across agents or team members. OpenSpace's value appears as the skill library grows beyond what a developer can manually keep track of.

## Project Status, Dependency Security Note, and MIT License

OpenSpace v2.0.0 was released on 2026-07-17. The last push to the repository was on 2026-08-12, approximately 47 days before this review. The README's news section covers development from April through July 2026, showing active development during that period. The repository has no additional releases after v2.0.0.

The security note in requirements.txt about litellm 1.82.7 and 1.82.8 being identified as malicious under PYSEC-2026-2 is a factual constraint with operational implications. Teams that manage their dependencies with automated update tools should add an explicit version exclusion for those two litellm releases to avoid pulling them in via a transitive path, not just through OpenSpace.

The benchmarks/ and tests/ directories in the repository suggest evaluation and testing infrastructure exists. The MANIFEST.in at the root controls what is included in the source distribution.

The license is MIT. Use in commercial products, modification, and redistribution are permitted. The authors are listed as 'OpenSpace Team@HKUDS' in the pyproject.toml, indicating an origin at Hong Kong University of Science (HKUDS).

For teams evaluating adoption: the v2 release represents a substantial feature addition over v1, and the README provides a v1 branch link for those who need to compare. The Python 3.12 requirement is the most common blocker for teams whose infrastructure has not yet upgraded.

## Conclusion

Teams building multi-agent systems where agents need to reuse skills across runs and learn from failures should evaluate OpenSpace v2.0.0. Individual developers running a single agent with a small fixed toolset have no need for a skill management layer. Before adopting, check that Python 3.12 is available in the environment and review the pinned litellm version in requirements.txt, which is constrained below 1.82.7 to avoid a documented supply-chain compromise.

## FAQ

### What is OpenSpace and what problem does it solve for AI agents?

OpenSpace is a skill management layer for AI agents. It solves the problem of finding the right skill in a growing library, knowing which skills work through real task evidence, sharing successful workflows across agents and teams, and improving skills based on outcomes.

### What Python version does OpenSpace require?

OpenSpace requires Python 3.12 or later, enforced in the pyproject.toml with requires-python = '>=3.12'. Earlier Python versions are not supported.

### What is the litellm version constraint in OpenSpace and why does it exist?

OpenSpace pins litellm to >=1.70.0,<1.82.7, explicitly to avoid PYSEC-2026-2, a documented supply-chain compromise in litellm versions 1.82.7 and 1.82.8, which were identified as malicious. This is noted directly in both requirements.txt and pyproject.toml.

## Sources

- [HKUDS/OpenSpace on GitHub](https://github.com/HKUDS/OpenSpace)
- [Issues](https://github.com/HKUDS/OpenSpace/issues)
- [License: MIT](https://github.com/HKUDS/OpenSpace/blob/main/LICENSE)
- [README](https://github.com/HKUDS/OpenSpace/blob/main/README.md)
- [Releases](https://github.com/HKUDS/OpenSpace/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/hkuds-openspace