Build Nemo Claw adapter to list OpenHuman on their skills/integrations page

[Al629176]

Summary

Build an integration adapter so OpenHuman can be listed on the Nemo Claw skills/integrations page (nemoclawai.io/integrations). Nemo Claw is NVIDIA's open-source security stack for AI agents — it wraps agents in enterprise-grade sandboxing, kernel-level isolation, privacy routing, and audit logging. Getting listed gives OpenHuman visibility with enterprise and NVIDIA hardware users running local AI stacks.

Problem

OpenHuman is not currently listed on Nemo Claw's integrations/skills directory. Nemo Claw is an open-source (Apache 2.0) platform and accepts third-party integrations either via direct contribution or their partner program. We have been provided an adapter guide from the Nemo Claw team that defines the technical contract for integration.

Solution (optional)

Scope: new adapter module, following the provided Nemo Claw adapter guide (share with the implementing developer before starting).

At a high level, the adapter will need to:

• Expose OpenHuman's agent capabilities in the format Nemo Claw expects for skills registration (tool definitions, capability manifest, or agent card — per the adapter guide spec)
• Handle the Nemo Claw runtime contract: sandboxed execution via OpenShell, network policy compliance (default-deny, operator-approved outbound), and audit log hooks
• Support Nemo Claw's privacy router — correctly declare which operations require cloud model calls vs. can run on local Nemotron models, so the router can make the right local/cloud decision
• Wire any required authentication or operator-approval flow for the Nemo Claw environment
• Submit the integration to the Nemo Claw GitHub for listing, or go through their partner program track (nemoclawai.io/integrations → "Partner With Us")

Related platforms: The adapter should be designed generically enough to extend to similar NVIDIA / NIM-ecosystem platforms where OpenHuman could also be listed.

Acceptance criteria

• Adapter builds — Nemo Claw adapter compiles and passes unit tests; follows the spec in the provided adapter guide exactly.
• Skills listing — OpenHuman appears on the Nemo Claw integrations/skills page after submission.
• Sandboxed execution — Adapter runs correctly within Nemo Claw's OpenShell kernel sandbox; no policy violations on standard OpenHuman flows.
• Privacy router compliance — Local-safe operations declared correctly; cloud calls route through the privacy router as expected.
• Audit log hooks — Agent actions emit audit log events in the format Nemo Claw expects.
• No regression — Existing OpenHuman agent flows unaffected when running outside the Nemo Claw environment.
• Diff coverage ≥ 80% — Adapter PR meets the changed-lines coverage gate.

Related

• Nemo Claw platform: https://nemoclawai.io
• Nemo Claw integrations page: https://nemoclawai.io/integrations
• Nemo Claw GitHub (Apache 2.0): https://github.com/NVIDIA/NemoClaw
• Adapter guide: (share document with implementing developer)

[oxoxDev]

@Al629176 @senamakel — did the recon on this. Summary before we commit engineering:

Feasibility: viable, but the surface is openhuman-core, not the desktop app. The Tauri GUI doesn't map to NemoClaw's model, but our headless core does: it already ships as a Docker image (JSON-RPC on :7788, /health, read-only + cap_drop ALL), and already speaks OpenAI-compatible inference via the local_ai provider (LM_STUDIO_BASE_URL, OPENHUMAN_MODEL). That lines up with NemoClaw's gateway-kind agent + managed-inference contract.

A new agent in NemoClaw = drop agents/openhuman/ (manifest.yaml + policy-additions.yaml + generate-config.ts + start.sh + Dockerfile) + host wiring + docs, PR'd to NVIDIA/NemoClaw. Their defs.ts auto-loads agents/*/manifest.yaml.

Three constraints I found in their Discussions that shape the design:

1. Inference router must be 100% in-path (their #5464) — so core must route all LLM traffic through inference.local and its hosted backend inference path must be disabled in-sandbox.
2. The audit/execution-receipt format has no published schema (their #5677 is an open question) — need to confirm what the "audit log hooks" AC actually expects, or whether OpenShell captures it at the sandbox layer.
3. Onboarding probes a gateway and a dashboard; core has the gateway but no in-container dashboard (that's the desktop app) — manifest needs to declare gateway-without-dashboard.

Process: NemoClaw onboards new integrations via a Feature Proposal discussion first, not a cold PR (precedent: their #1779 + poll #1782). So step 1 is a proposal on their repo, not code here.

Two asks before I start:

• The adapter guide referenced in this issue — needed for the exact contract.
• A product call on egress posture: local-only Nemotron (no tinyhumans backend) vs authenticated + declared egress. This decides the network policy.

Will draft the NemoClaw proposal once those land.