[Question] Integration: OpenClaw (host) + OpenSpace (worker) single-shot task architecture

[liuzianws]

Question: How to properly integrate OpenClaw (host) with OpenSpace (worker)?

Context

We are trying to integrate OpenClaw as the main AI assistant with OpenSpace running as a background task executor.

Our setup:

• OpenClaw (our main assistant) runs as a persistent session in Feishu (messaging platform)
• OpenSpace is deployed locally at /Users/liuzian/OpenSpace
• We use a Python wrapper (openspace_runner.py) that calls OpenSpace CLI via subprocess
• OpenSpace has 49 skills trained in its own environment

The challenge:

OpenSpace tasks are single-shot (one task = one subprocess = one recording). There is no cross-task memory. The key question is: how should OpenClaw pass complete context to OpenSpace in a single query?

Specifically:

1. Context packaging for single-shot tasks
Since OpenSpace has no session memory, all context (user background, task description, constraints, available tools/references) must be included in a single query. Is there a recommended prompt structure or template for packaging rich context into a single OpenSpace query?

2. Skill compatibility and selection
OpenSpace has 49 skills trained in the OpenSpace environment. OpenClaw also has its own skill system. When OpenClaw calls OpenSpace:

• Does OpenSpace automatically select appropriate skills based on the query?
• Or does OpenClaw need to explicitly specify which skills to use?
• Are OpenSpace skills and OpenClaw skills compatible, or are they separate systems?

3. Architecture: OpenClaw as host, OpenSpace as worker
OpenSpace runs as a standalone subprocess, separate from OpenClaw environment. Is this the intended architecture (OpenClaw as host/controller, OpenSpace as skill execution worker)? Or should OpenSpace skills be imported directly into OpenClaw?

4. Reliable recording when called via subprocess
When running OpenSpace via Python subprocess (as opposed to direct CLI), some recording directories were not being created — logs showed "Recording completed" but no directory existed on disk. This was traced to asyncio subprocess pipe handling differences. Is there a recommended way to call OpenSpace from Python that ensures reliable recording?

Any guidance on the intended integration pattern would be greatly appreciated. We are excited about combining OpenClaw persistent session/context with OpenSpace self-evolving skills. Happy to contribute documentation back.

---

Environment: macOS, Python 3.14, OpenSpace v0.1.0, OpenClaw (latest)

[tluma]

Hi liuzian,

Based on the OpenSpace integration documentation, the intended architecture for OpenClaw + OpenSpace integration is MCP protocol via mcporter, not subprocess calls. This is likely the root cause of your recording issues.

Recommended Architecture

The documented approach for OpenClaw integration is:

mcporter config add openspace --command "openspace-mcp" \
  --env OPENSPACE_HOST_SKILL_DIRS=/path/to/openclaw/skills \
  --env OPENSPACE_WORKSPACE=/path/to/OpenSpace \
  --env OPENSPACE_API_KEY=sk-xxx

Then copy the two host skills into OpenClaw's skills directory:

cp -r host_skills/skill-discovery/ /path/to/openclaw/skills/
cp -r host_skills/delegate-task/ /path/to/openclaw/skills/

Context Packaging (Question 1)

OpenSpace exposes 4 MCP tools, with execute_task being the primary task execution tool. Pass all context (background, constraints, references) in the task_query parameter — the grounding agent handles skill injection internally via BM25 + embedding hybrid ranking.

Skill Selection (Question 2)

Skills are automatically selected by OpenSpace's skill registry using pre-filtering and LLM selection. You don't need to explicitly specify skills — OpenSpace's skill discovery runs automatically within execute_task.

OpenSpace skills and OpenClaw skills are separate systems — OpenSpace has its own skill library (165 evolved skills from benchmarks), while OpenClaw has its own skill system.

Recording Reliability (Question 4)

The local_server mode is recommended when subprocess handling causes issues — it uses HTTP → Flask → subprocess instead of asyncio subprocess pipes directly. However, the cleanest solution for your use case is the MCP integration, which avoids subprocess issues entirely.

Alternative: Python API

For direct Python integration, the documented API is:

from openspace import OpenSpace

async with OpenSpace() as cs:
    result = await cs.execute("your task with full context")

This handles recording reliably without subprocess wrapper complexity.

Would you like more detail on migrating from subprocess to the MCP integration?