NVIDIA NeMo Fabric

NeMo Fabric gives applications, evaluation systems, and rollout platforms a consistent interface for running agent harnesses and custom agents.

• Compose runs: Configure models, tools, skills, MCP servers, subagents, and runtime settings consistently.
• Validate before execution: Detect unsupported configurations before starting a runtime.
• Switch harnesses: Reuse the consumer integration while adapters handle harness-specific behavior.
• Compare outcomes: Collect normalized results, errors, artifacts, lifecycle events, and telemetry references.

Supported Agent Harnesses

NeMo Fabric includes adapters for the following harnesses and execution targets. Select a harness name for its adapter documentation:

Agent Harness	Tool Policy	MCP	Skills	Telemetry
Claude Code	✅	✅	✅	✅
Cline	✅	✅	✅	—
Codex	—	✅	✅	✅
Factory Droid	✅	✅	✅	—
Hermes Agent	✅	✅	✅	✅
Kilo Code	✅	✅	✅	—
AWS Kiro	—	✅	—	—
AWS Strands	—	✅	—	—
LangChain Deep Agents	✅	✅	✅	✅
mini-SWE-agent	—	—	—	✅
NOOA	—	✅	✅	✅
OpenClaw	✅	✅	✅	—
OpenHands	✅	✅	✅	—
OpenCode	—	✅	✅	—
Pi	✅	—	✅	✅
Qwen Code	✅	✅	✅	—
Remote Agent	—	—	—	✅

✅ Supported · — Not supported. Support may come through normalized configuration, native harness behavior, or a specific target. Refer to each adapter guide or the complete compatibility matrix for details and limitations.

Ecosystem

NeMo Fabric brings supported agent harnesses into the frameworks teams use to benchmark and improve agents:

• Harbor ships FabricAgent upstream. Harbor 0.25.0 includes FabricAgent, bringing NeMo Fabric-backed harnesses directly into Harbor's benchmarking workflows. Its fabric extra requires NeMo Fabric 0.5.x; for NeMo Fabric 0.6, use the separate Harbor bridge with Harbor 0.24.
• NeMo Gym supports NeMo Fabric-backed agents. NVIDIA NeMo Gym integrates NeMo Fabric for evaluation and training rollouts.

The ecosystem also includes shipped workflows in NVIDIA NeMo Helix, an active integration with NVIDIA NemoClaw, and emerging rollout integrations such as NVIDIA Polar. Explore the NeMo Fabric ecosystem.

Extensibility

NeMo Fabric separates consumers from execution targets through a stable, versioned contract. This makes it extensible in two directions:

• Integrate a consumer: Applications, evaluation systems, and rollout platforms use the Python SDK and typed FabricConfig to run different harnesses without implementing each harness integration. Start with the consumer integration overview or consumer integration skills.
• Shared Python contracts: The SDK and adapter contract consume the standard-library shared contract package for software evidence and validation.
• Add an execution target: Adapters translate the NeMo Fabric contract into the native behavior of a harness, framework, custom agent, or remote service. Start with the adapter contract and adapter examples.

Documentation

• Quickstart: Run a first agent through the Python SDK.
• Invocation system stats: Select per-invocation metric groups, sampled peaks, and cgroup conditions; disable collection independently of sampling.
• Selected software evidence: Inspect versions in optional RunResult.execution and control collection before initialization.
• Conversation telemetry: Use RunRequest.relay_session_root to group Deep Agents and mini-SWE-agent turns under one NeMo Relay session.
• Installation: Install the runtime, adapters, harness dependencies, and telemetry components, and choose a deployment scenario.
• Adapter catalog: Inspect bundled adapter metadata on a host without installing harness SDKs.
• Host admission: Validate requested capabilities and reject host/task descriptor drift before execution.
• NeMo Fabric runtime server: Manage runtimes and check server responsiveness inside one sandbox through fabric-agent-ctl and one private local socket. Unconfirmed cleanup retains sandbox ownership and blocks replacement servers.
• Health checks: Use Fabric.check() for OpenShell runtime-server checks, agent runtime checks, and prepared or attached OpenClaw Gateway service checks. Refer to the adapter support table for supported levels and native evidence. OpenShell server and runtime requests map to fabric-agent-ctl check; service checks use the local SDK.
• Documentation overview: Understand the execution model and choose an interface.
• Adapter reference: Compare adapter configuration, runtime, and observability support.
• Contribution guide: Build, test, and contribute to the project.

Roadmap

Planned areas of development include:

• Refine runtime resource measurements: Improve CPU, memory, elapsed-time, and available GPU measurements through broader benchmark validation.
• Support long-running, artifact-heavy workloads: Make OpenShell timeouts and response/artifact limits configurable, including unlimited task duration, with clear limit errors and guidance for retrieving large screenshots.
• Expose task progress and recoverable results: Provide task state, step progress, plans, pending requests, sandbox task listings, and paginated events, with final results retrievable after invocation ends or the caller disconnects.
• Standardize model usage accounting: Report input, cached, output, and reasoning tokens consistently, distinguish complete, partial, and unknown usage, and attribute delegated work to the correct invocation.
• Capture execution provenance: Record NeMo Fabric and adapter versions, requested models, sanitized MCP configuration, and execution environment, with explicit sources and unknowns.