feat(driver): define community-contributed Harness packages

[Yevanchen]

Area

Agent Driver / Runtime

Problem

Mosoo normalizes supported Harnesses behind one managed Run lifecycle, and #546 proposes making Harness selection explicit. However, adding a new Harness still depends on the Mosoo core release cycle:

• each integration needs a Driver backend or ACP launch configuration, Runtime Catalog entry, capability declaration, image pin, and release-gate coverage;
• ACP is the right shared path for compatible Harnesses, but some Harnesses and downstream forks expose custom protocols or capabilities;
• a Builder cannot bring an exact Harness version and compare it against another Harness while keeping the Environment, provider, Skills, MCP connections, resources, and task fixed;
• community contributors cannot add a compatible Harness through a bounded package and conformance PR without understanding or changing the control plane.

The user outcome is not “more built-in Agents.” It is a stable Mosoo API above a replaceable Harness layer, so new Harnesses such as Pi, Kimi Code, DeepSeek variants, dsh, or OpenCode forks can be evaluated within hours instead of waiting for a platform release.

Proposal

Define a versioned Harness Package contribution contract around the existing Agent Driver protocol. A Docker/OCI image may be the distribution unit, but the image alone is not the compatibility contract.

The smallest useful package should declare:

1. a stable package ID and version, exact Harness version, immutable image digest, and entrypoint;
2. supported Driver protocol versions and a validated boot/config schema;
3. capabilities and known gaps for streaming, tool activity, approvals, cancellation, attachments, usage, and resume;
4. compatible provider/model configuration and required Environment capabilities;
5. resume compatibility boundaries so one Harness or version cannot consume another's native session reference;
6. provenance plus the fixtures needed to pass a shared Driver conformance suite.

The contribution flow should be:

1. implement ACP launch configuration when ACP is sufficient; otherwise implement the existing Driver protocol;
2. run one documented conformance command locally;
3. submit the package manifest, pinned artifact, and fixtures without changing API/Runtime domain modules;
4. let CI verify lifecycle behavior and catalog metadata before admission;
5. freeze the admitted package ID, version, and image digest on every Run.

Hosted Mosoo should admit only reviewed packages. Self-hosted operators may opt into private packages under an explicit trust policy. Arbitrary unreviewed images must not silently become executable on the shared hosted platform.

Skills, MCP connections, provider credentials, files, and Environment setup remain Mosoo-owned inputs. A Harness Package must not create a second plugin or secret-management model.

Acceptance criteria

• A fixture Harness can be contributed through a manifest, pinned artifact, and conformance fixtures without changing API/Runtime domain code.
• The same public Run lifecycle starts, streams, approves, cancels, and reads results from both a built-in and contributed Harness.
• A fixed task can run with the same Environment revision, provider/model, Skills, MCP connections, and resources while changing only the Harness Package.
• Every Run records the exact package ID/version, Harness version, Driver protocol version, and immutable artifact digest.
• Unsupported capabilities fail readiness before Sandbox allocation with an actionable reason.
• Native resume references are scoped to a compatible package/version boundary.
• The conformance suite covers startup, text/tool events, approval, cancellation, terminal success/failure, cleanup, and declared degradation.
• Hosted and self-hosted trust policies are explicit; an unreviewed package cannot execute on hosted Mosoo.
• Existing OpenAI Runtime, Claude Agent SDK, OpenCode, and ACP-backed behavior remain unchanged.

Alternatives considered

• Continue official one-off integrations: lowest trust risk, but preserves the release lag and repeated catalog/backend work.
• Require ACP for every Harness: reuse this whenever possible, but it cannot represent every highly customized Harness or fork.
• Accept an arbitrary Dockerfile/image as the API: fast to prototype, but provides no lifecycle contract, capability negotiation, reproducibility, or hosted trust boundary.
• Build a full Harness marketplace now: unnecessary. Start with package compatibility, contribution, pinning, and conformance; discovery, ratings, billing, and automatic ranking can wait for demonstrated demand.

Compatibility and migration

This is additive. Built-in Harness identities and existing Sessions keep their current behavior. Package upgrades create new immutable versions and do not mutate running or resumable work. No marketplace UI or automatic Harness routing is required.

Related

• feat(platform): pivot Mosoo to an API-first managed Agent runtime #546 — environment-first Harness API and explicit Harness selection
• feat(runtime): add Pi through ACP #486 — Pi through the shared ACP backend
• feat(plugins): import Agent Plugins 1.0 packages #509 — portable Agent Plugin import for Skills and MCP; intentionally not a runtime protocol

Contribution

I can provide product feedback.

Checklist

• I searched existing issues before opening this request.
• I described the problem before the proposed solution.
• I kept this request focused on one improvement.