mosaicstack/stack
1
0
Fork 0
Code Issues 13 Pull Requests Actions Packages Projects Releases 11 Wiki Activity

OC-MACP: OpenClaw MACP plugin — sessions_spawn runtime:macp with Pi dispatch and completion signaling #328

New Issue
Closed
opened 2026-03-30 00:04:53 +00:00 by jason.woltje · 1 comment
jason.woltje commented 2026-03-30 00:04:53 +00:00
Owner
Copy Link

Summary

Build an OpenClaw extension that makes MACP the primary agent execution runtime in OC, as a near drop-in replacement for ACP.

Requirements

1. OC MACP Extension (openclaw/extensions/macp/)

  • Implement IAgentProvider interface: listSessions | streamSession | sendMessage | terminate | getSessionTree
  • When OC calls sessions_spawn(runtime: "macp"), route to this extension
  • Extension calls macp_dispatcher.dispatch_task() → Pi runner → model → result
  • Returns a session handle OC can poll/stream
  • Config entry: agents.providers.macp with dispatch: pi, model: zai/glm-5

2. Completion Signaling (push, not poll)

  • Pi runner calls openclaw system event --text "MACP_COMPLETE: <task_id> <result_path>" on finish
  • OC main session receives system event, resolves the pending sessions_spawn promise
  • This closes the gap where OC must poll for task completion
  • Reference: existing Forge board dispatch → system event flow (PRs #779-780)

3. MACP as ACP near drop-in

  • sessions_spawn accepts runtime: "macp" alongside existing runtime: "acp"
  • Same session lifecycle events as ACP (started, streaming, completed, error)
  • Graceful fallback to ACP if MACP unavailable
  • Config flag: agents.defaultRuntime: "macp" | "acp"

4. Pi Runner as persistent service

  • Pi runner needs to run as a background service on the host (not spawned per-task)
  • Expose HTTP endpoint for task dispatch: POST /dispatch
  • Return task ID immediately; push completion event when done
  • Manage worker pool (max concurrent per AGENTS.md limits)

Architecture

OC sessions_spawn(runtime: macp)
  → OC MACP extension
    → macp_dispatcher.dispatch_task()
      → Pi runner service (HTTP POST /dispatch)
        → model (GLM-5/Codex/Claude)
        → task executes
        → result written to .mosaic/orchestrator/results/
        → POST back to OC: openclaw system event MACP_COMPLETE
  → OC resolves session handle

Reference

  • MACP dispatcher: ~/src/mosaic-mono-v1/tools/macp/dispatcher/macp_dispatcher.py
  • Pi runner: ~/src/mosaic-mono-v1/tools/macp/dispatcher/pi_runner.ts
  • OC ACP extension (reference impl): openclaw source
  • MACP discovery: ~/src/mosaic-mono-v1/docs/discovery/MACP-discovery-map.md
  • Completed MACP PRs: #777-794

Why this matters

Without this, every automated task requires manual shell script orchestration, worktree management, and polling. With this, sessions_spawn(runtime: "macp", task: "...") handles everything — execution, tracking, completion signaling — and Jarvis gets real autonomous capability.

Priority

CRITICAL — blocks all automated E2E agent orchestration

Labels

macp, openclaw-integration, automation, P0

## Summary Build an OpenClaw extension that makes MACP the primary agent execution runtime in OC, as a near drop-in replacement for ACP. ## Requirements ### 1. OC MACP Extension (`openclaw/extensions/macp/`) - Implement `IAgentProvider` interface: `listSessions | streamSession | sendMessage | terminate | getSessionTree` - When OC calls `sessions_spawn(runtime: "macp")`, route to this extension - Extension calls `macp_dispatcher.dispatch_task()` → Pi runner → model → result - Returns a session handle OC can poll/stream - Config entry: `agents.providers.macp` with `dispatch: pi`, `model: zai/glm-5` ### 2. Completion Signaling (push, not poll) - Pi runner calls `openclaw system event --text "MACP_COMPLETE: <task_id> <result_path>"` on finish - OC main session receives system event, resolves the pending `sessions_spawn` promise - This closes the gap where OC must poll for task completion - Reference: existing Forge board dispatch → system event flow (PRs #779-780) ### 3. MACP as ACP near drop-in - `sessions_spawn` accepts `runtime: "macp"` alongside existing `runtime: "acp"` - Same session lifecycle events as ACP (started, streaming, completed, error) - Graceful fallback to ACP if MACP unavailable - Config flag: `agents.defaultRuntime: "macp" | "acp"` ### 4. Pi Runner as persistent service - Pi runner needs to run as a background service on the host (not spawned per-task) - Expose HTTP endpoint for task dispatch: `POST /dispatch` - Return task ID immediately; push completion event when done - Manage worker pool (max concurrent per AGENTS.md limits) ## Architecture ``` OC sessions_spawn(runtime: macp) → OC MACP extension → macp_dispatcher.dispatch_task() → Pi runner service (HTTP POST /dispatch) → model (GLM-5/Codex/Claude) → task executes → result written to .mosaic/orchestrator/results/ → POST back to OC: openclaw system event MACP_COMPLETE → OC resolves session handle ``` ## Reference - MACP dispatcher: `~/src/mosaic-mono-v1/tools/macp/dispatcher/macp_dispatcher.py` - Pi runner: `~/src/mosaic-mono-v1/tools/macp/dispatcher/pi_runner.ts` - OC ACP extension (reference impl): openclaw source - MACP discovery: `~/src/mosaic-mono-v1/docs/discovery/MACP-discovery-map.md` - Completed MACP PRs: #777-794 ## Why this matters Without this, every automated task requires manual shell script orchestration, worktree management, and polling. With this, `sessions_spawn(runtime: "macp", task: "...")` handles everything — execution, tracking, completion signaling — and Jarvis gets real autonomous capability. ## Priority CRITICAL — blocks all automated E2E agent orchestration ## Labels macp, openclaw-integration, automation, P0
jason.woltje commented 2026-03-30 12:52:49 +00:00
Author
Owner
Copy Link

Validation findings (2026-03-30)

Plugin compiled and registered. Blocked on acpx dispatch integration:

What works:

  • Plugin compiled to dist/index.js ✅
  • registerAcpRuntimeBackend called on plugin init ✅
  • macp added to acp.allowedAgents ✅

Blocker:

  • sessions_spawn(runtime:acp, agentId:macp) → acpx exited with code 1
  • acpx runs as a subprocess and does not see runtime backends registered via plugin SDK
  • The registerAcpRuntimeBackend hook is in OC core, not in acpx

Fix needed:

  • Either: acpx needs to query OC for registered runtime backends before dispatch
  • Or: sessions_spawn needs a direct path that bypasses acpx for MACP runtime
  • The OC plugin SDK docs / acpx architecture should clarify how custom runtime backends are invoked

Assigning back to Forge for fix.

## Validation findings (2026-03-30) Plugin compiled and registered. Blocked on acpx dispatch integration: **What works:** - Plugin compiled to `dist/index.js` ✅ - `registerAcpRuntimeBackend` called on plugin init ✅ - `macp` added to `acp.allowedAgents` ✅ **Blocker:** - `sessions_spawn(runtime:acp, agentId:macp)` → `acpx exited with code 1` - acpx runs as a subprocess and does not see runtime backends registered via plugin SDK - The `registerAcpRuntimeBackend` hook is in OC core, not in acpx **Fix needed:** - Either: acpx needs to query OC for registered runtime backends before dispatch - Or: sessions_spawn needs a direct path that bypasses acpx for MACP runtime - The OC plugin SDK docs / acpx architecture should clarify how custom runtime backends are invoked Assigning back to Forge for fix.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jason.woltje
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mosaicstack/stack#328
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?